Workflow managers

A workflow's rules move normal work with no model involved: pass goes here, fail goes there, three failures go to a person. A manager is the agent asked when those rules have nothing to say — and when nothing is happening at all. It does not work a column. It reads what happened and chooses one step from a fixed list, and CodeBook carries the step out.

Who manages a workflow

Every workflow shows it on the board itself, in a bar above the columns: Manager Harper · Delivery Manager, what it was last asked about and what it did, and Manager settings — or No manager on this workflow with Choose a manager when nobody does. Use the button to change the manager, switch it off, set how many times it may step in, and read what it decided.

Change the manager's model and agent settings

1. Open Manager settings from the bar above the workflow.
2. Find Agent settings · [agent name]. If you changed the manager selection, save it first.
3. Under Model, choose Set a policy for this worker if it has no policy yet.
4. Choose Fixed, Fallback chain or Automatic, select the model or models, then Save model policy.

This is the same installed-agent policy available in Marketplace → Your agents. It applies to manager conversations and automatic interventions. The manager follows its agent policy, then the factory policy, then the organization's default model. The station used to store its conversation does not supply a station policy. See model routing for fallback rules.

New runs use the saved policy. An active conversation run retains its selected model chain until it ends or is resumed. An unavailable pinned model produces a clear error rather than silently switching providers.

The panel also opens Permissions, Edit agent and instructions, and Agent Studio, with the manager's installed agent selected. Instructions, permissions and model policy belong to that installed agent and affect its other roles too. Station routes, triggers and gates remain workflow controls.

Studio releases now govern manager conversations and workflow, specialist and factory supervision. Save a baseline, evaluate a candidate, then use Production rollout to choose its share. Replies and decisions retain their chosen instruction version; conversation Retry and Continue keep it after rollback. New replies follow the current release. See Agent studio.

Studio shows manager execution counts separately from station quality. Use Review quality under a finished reply or model-made decision to record a human judgment, and use the manager/supervisor starter datasets to evaluate saved instruction versions. Quality reviews and role cases explain the permissions, denominators and limits. Completion alone is not a quality judgment. These settings do not grant human approval or merge powers.

Manager conversations also receive approved scoped memory for their installed agent and workflow. Pending, rejected, archived and out-of-scope notes are excluded. Memory is refreshed before each model step. If a note changes while the request is being prepared, the reply stops resumably; Retry rebuilds it from current notes.

Open Model input history beneath a reply to inspect the fitted input hash, model, step, fallback revisions and approved-memory inclusion records. These private records describe the logical request prepared for Bookbag SSO. They do not copy prompt or memory bodies, replay earlier content, or prove that the provider completed a call. The same history is available in station-agent conversations. Deleting a conversation removes its records.

Default managers

A workflow made from a template is managed from the start. Each template names the manager that fits its kind of work, installs it into the workspace, and switches it on, answering to whoever made the workflow. The template picker shows which one before you choose.

Manager	Role	Templates it manages by default
Harper	Delivery Manager	Software delivery, Parallel review delivery, MVP build & launch
Devon	Lead Developer	API delivery, Secure delivery, Platform migration, Tech debt paydown, Data & analytics delivery, Robotics simulation
Tessa	QA Lead	Bug response, Accessibility audit
Owen	Product Owner	The Product templates, Feedback to roadmap
Rhea	Release Manager	Commerce release, Product launch
Blake	Operations Manager	Start a business, Run a business
Carmen	Sales Manager	Sales
Mila	Marketing Manager	Marketing
Elena	Customer Success Manager	Customers
Felix	Finance Controller	Finance
Paige	People Manager	People
Morgan	Factory Supervisor	Incident response; the generalist, and the factory-level supervisor

Any agent in the workspace can be chosen instead. The picker lists installed workspace agents. Use Add a manager from the marketplace to install another, then return and select it. A workflow that existed before managers were on by default is left as it was: its header says Choose a manager.

Talk to the manager

The manager is the one agent that sees the whole workflow — so it is the one to tell what you want. Talk to … on the manager bar above the columns opens a conversation with it.

Say it in your own words:

• "I need user stories for the CSV export."
• "Build me this: …"
• "Where does everything stand?"
• "What is stuck, and what are you doing about it?"

What it does with that:

1. Looks first. Every station and who works it, what is on each, what is running, what waits for a person, the open pull requests.
2. Delegates. It gives a station the work as a card whose description is a brief that stands on its own, and starts that station's agent — even when the station does not start by itself. Asked for stories, it gives the analyst the job; it does not write them. The workflow's own routes carry the card on from there.
3. Keeps things moving. It can start or move a card that already exists, and ask an agent a question on a card.
4. Tells you what it set in motion and what to expect next.

It never merges, deploys, changes a setting or dismisses a prerequisite, and it is not offered the tools that write stories or code. Those stay with the stations and with you.

Every request becomes a card

Nothing you ask the manager for lives only in a conversation.

• It looks first. Before filing, the manager searches the factory for a card that already covers what you asked. When open work already looks like your request, nothing new is filed: it shows you that card and continues it. It files a second card only when the work really is different.
• The card remembers who asked. A card the manager filed shows where the request was made — in CodeBook, in Slack, or through a connected tool — and who made it.
• You are told where you asked. When a card the manager filed needs a person, and when it is done, the manager says so in the same conversation — and in the Slack thread, for a request made there. You do not have to ask again or go and look.

Steering work that is under way

Tell the manager when something changes, and it acts on the card:

You say	The manager
"Also make sure existing email login still works."	Adds it to the card's description, dated. The description is never replaced.
"Stop, that is the wrong approach."	Stops the run on the card and posts why.
"Try that again."	Starts the station's agent on the card again.
"You need to ask finance about that."	Puts the card in front of a person, with exactly what it needs from them.
"That belongs in the marketing workflow."	Files it in the factory's other workflow.

What the manager will not do

It never approves anything — not a run waiting for approval, not a merge, not a review. An approval is your own act. The manager reads what agents write, so it is deliberately given no way to turn that text into an approval. Ask it to approve and it tells you where you do it.

Whose context

Each agent keeps its own context. An agent the manager gives work to sees its card and nothing of your conversation with the manager — which is why the manager's brief has to say everything.

Only the manager reads across: every card, thread and run in the factory, and the conversations you have had with the other agents. It reads only the conversations of the person it is talking with. One person's private conversation is never read out to someone else through the manager.

The manager can open a card from another workflow in the same factory, including its station, agent, recent runs and discussion. It can steer existing cards only in its own workflow. For an existing card elsewhere, continue with that workflow's manager. Cards in another factory are refused, even if you personally have access to both factories.

From Slack, or any other tool

You can talk to the manager where you already work. Open Factory settings → Workflow managers → Talk to the manager from Slack or another tool.

Slack

1. Create a Slack app in your workspace at api.slack.com/apps.
2. Give the bot the scopes app_mentions:read, chat:write and im:history, and install it. Add users:read as well if you want the manager to know who in a thread asked; without it everything works and the speaker is simply "Someone in Slack".
3. In CodeBook, connect Slack and paste the app's Bot User OAuth Token and Signing Secret. Both are stored encrypted.
4. In the Slack app's Event Subscriptions, set the Request URL to the address CodeBook shows, and subscribe to app_mention and message.im.
5. Invite the app to a channel.

Mention the app in a channel, or message it directly, and the manager answers in the thread. A thread is one conversation, so replies in the thread continue it.

Any other tool

Connect an API channel to get a token (shown once), then:

curl -X POST "https://app.codebook.work/kanban/api/manager/ask?channel=<id>" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"text": "Where does everything stand?", "thread": "ops"}'

The answer comes back as reply. Use the same thread to continue a conversation. Add "from": "Priya" to say who is asking.

The card's thread, in your Slack thread

When you ask for work in a Slack thread, that thread follows the work. Every comment on the card — the analyst's stories, the developer's pull request, QA's verdict, a question for a person — is posted into the thread, with who said it. What you write in the thread is written onto the card, with your name, so the agents read it there.

CodeBook stays the one history. The thread is a window onto the card, not a second conversation: nothing is carried across twice, and what you write in Slack is not echoed back to you.

What to know

• Every Slack delivery is verified with your app's signing secret.
• The manager acts with the access of the person who connected the channel, and each conversation also appears in that person's conversations with the manager in CodeBook.
• A Slack channel is not private, so a conversation that came in from outside is never given that person's private conversations with other agents.
• Switching a channel off, or removing it, stops it answering at once.

When a manager is asked

When a run ends and the rules do not cover it:

• A run ended blocked or failed, and the station has nowhere to send that.
• A run could not start, or stopped part-way.
• A handoff or a parallel fan-out was refused.
• The station reached its retry limit.

And when nothing ends — CodeBook checks every managed workflow about once a minute:

• A wait that is not ending. A card has been held for a prerequisite story for 20 minutes. The waiting card says which story it waits for and where that story is — including when it sits in a person's column and a person is the next step. When the story did not exist and an agent asked the story author for it, the request card files itself in Done once the author answers, and the waiting card is told which story was written.
• An idle card. A card sits at a station an agent works automatically, nothing is running, and its last run there ended blocked, failed or interrupted an hour ago or more.
• An unanswered question. A comment that asked a person, or everyone, is still the last word on its card after four hours, unread by everyone it was addressed to.

The same card and situation is raised again no sooner than a day later.

Finished, but not merged

A card resting in a Done station is not shipped while its pull request is open. The manager is asked about two more situations there:

• The pull request cannot be merged. It conflicts with the base branch, is behind it, has failing checks, or the host refused the merge. After ten minutes the manager is asked; the step that fits is sending the card back to the station that builds, saying what is wrong.
• The pull request is waiting. It is open and unmerged four hours after the card finished. The manager asks the person, naming the pull request.

A manager is never offered a merge. See Merging.

What a manager may do

One step, from this list, offered only when it would work:

• Send the card to another station of the workflow.
• Run the station again, with guidance written on the card first. Not offered when the station is out of retries, or when the card would only be held again.
• Ask a colleague in the card's discussion. The colleague answers in the thread and the work goes on from the answer.
• Start the story the card is waiting for, when that story has stopped with nothing running. Guidance is written on that story first.
• Use a handoff the station already declares to another workflow.
• Ask a person, saying exactly what they need to do. The card then goes where a person looks for work: if the workflow has a person's column (a Human review), the card is moved there with the reason as its last comment. If it has none, the person named for the workflow is notified — and when nobody is named, everyone in the factory is asked. A card that still has a run waiting, or that is already in a finished column, stays where it is. A card that gets stuck again while you have not yet answered is not asked about twice — but it is moved back to the person's column, so it is where you look.

What a manager never does

A manager cannot merge a pull request, dismiss a prerequisite, change a setting, or invent a destination. Those stay with a person; the manager asks for them by name. A budget stop skips the manager and goes straight to the person.

Bounds

• A manager steps in at most three times on one piece of work by default (1–10, set in the panel). After that the person is asked without calling a model.
• One manager acts on a piece of work at a time.
• While a person has been asked and has not answered I have dealt with this, the manager leaves the card alone.
• Every decision is in the Decision log in the panel, with the card, the situation and the reason.

Above the workflow's manager sit specialists per kind of failure and one supervisor for the whole factory: see Factory supervision.