This is part three of Agentic Operating System For Your Business. Part one asked whether the Chief Agentic Officer Briefing could become a real agentic business. Part two followed the podcast until it met a very human publishing gate. This instalment is about what happens when the agents find a problem.
I have reached an interesting stage in building the Chief Agentic Officer business.
The agents are doing useful work. They can see when something has failed. They can tell me about it. They can discuss it with me.
But I do not want a company where every exception becomes another message for Tony.
That does not scale.
So the problem I am working on now is not simply how to make agents do more.
It is how to make the work visible, bounded, discussable, assignable, and resolvable without turning me back into the engineer for every system.
My answer is something I am calling a work packet.
The agents will get things wrong
We had a couple of issues with the podcast. A route was blocked, the agents reached a point they did not understand, and they did not quite know what to do next.
That is not evidence that the whole idea has failed.
It is training.
If you brought an intern into your company, you would not say, "Do everything possible to make this happen," then disappear.
Come on. Everything?
Everything to a human already means "everything reasonable within the boundaries of this company, this role, the law, our values, the budget, and the authority I have given you." We carry all of that context silently.
An agentic system does not necessarily carry it silently. The models are now capable enough to be ingenious about completing a goal. That makes the boundaries more important, not less.
If I tell an agent to do everything, I should not be surprised when it explores routes I had in my head as obviously out of bounds.
So I hold each worker inside tight guardrails. It has a defined role, tools, limits, data surface, budget, escalation route, and stop-lines. When we meet a new edge case, we decide what reasonable behaviour looks like and add that to the operating history.
That is how the system learns the business without being given the keys to everything.
A message is not the same as work
Orchistra makes the work visible. It is the room where agents can communicate, where I can see what is happening, and where issues can be raised.
But visibility creates its own problem.
You can end up with a stream of messages:
- this upload failed;
- that source could not be reached;
- this field was missing;
- the expected result did not arrive;
- a human decision is required.
That is useful information, but information is not yet managed work.
In a conventional company, the human reads the message, asks the team what happened, opens Jira, creates an issue, adds context, assigns it, attends a stand-up, answers questions, checks the fix, and closes the ticket.
I do not want to reproduce all of that around my agents.
I certainly do not want to force agents through a human issue-tracking interface simply because that is what we already know.
If I want a long issue list, an agent can generate one for me. But the list should be a view, not the operating system.
The work packet
A work packet is the durable object created when an informational message becomes something that needs to be resolved.
It gathers the problem, relevant evidence, operating context, known constraints, prior attempts, ownership, possible next actions, risk, approval status, and the definition of done.
The exact format will continue to evolve, but the practical shape is:
| Work packet field | Question it answers |
|---|---|
| Problem | What happened, and why does it require attention? |
| Evidence | What logs, outputs, messages, files, or observations support the diagnosis? |
| Context | Which goal, role, workflow, and business outcome does this belong to? |
| Triage | Can an agent probably resolve it, with what confidence, cost, and risk? |
| Boundaries | What may be read, changed, retried, proposed, or never touched? |
| Decision | Has a human approved, amended, rejected, deferred, or escalated the proposed route? |
| Owner | Which worker agent or human is accountable for the next move? |
| Success condition | What evidence will prove the work is complete? |
| Receipt | What happened, what changed, what was checked, and what remains? |
The packet is not just a ticket with a fashionable name.
Its job is to carry enough meaning that another agent can pick it up without making me reconstruct the entire situation.
Triage before it reaches me
I do not want the first thing I see to be a raw error.
Before a work packet comes to me, I want a bounded triage agent, often using a cheaper model, to have already looked around.
It should ask:
- Is this genuinely a problem, or only information?
- Has this happened before?
- Is there an approved recovery pattern?
- Can the available worker resolve it?
- What is the probability of success?
- What could be changed or damaged?
- Does the proposed action cross a human approval boundary?
Then I can see a short, prepared decision surface rather than a pile of operational noise.
This is where evals matter. Anthropic's guidance on agent evaluation makes the same useful point in a different form: agents operate over many turns, modify state, and adapt from intermediate results, so teams need automated checks, production monitoring, and periodic human calibration. The more capable the loop, the more important it is to know whether it did what was asked, did not break anything, and did the work well.
I want a conversation, not an approval reflex
When the packet reaches me, I do not want one of those interfaces that trains the human to click approve without thinking.
I want to talk to it.
Show me the problem. Explain the evidence. Tell me what you think the cause is. Tell me what you would change. Tell me what might go wrong. Let me ask questions in my own language, ideally by voice.
Then I can approve the route, amend it, reject it, or ask for more analysis.
That is still human-in-the-loop, but at the right level. I am making the judgement about the goal, boundary, and risk. I am not typing every engineering step.
OpenAI's practical guidance recommends human intervention when an agent exceeds failure thresholds or reaches high-risk, irreversible, or sensitive actions. LangGraph's human-review pattern similarly pauses durable state so a person can approve, edit, or reject an action before the system resumes.
That is close to the interaction I want, but the work packet gives it a business object I can scan and return to.
The management agent should not do the work
There is a deliberate separation in this design.
The management service can create the work packet, gather context, support the discussion, and record my decision.
It does not get broad execution power.
Once I say, "Yes, go ahead and fix that," the packet is updated with the approved route. A separate, bounded worker agent receives a nudge, picks up the packet, checks that the authority is current, and carries out only the approved work.
It then verifies the success condition and writes an auditable receipt.
If the fix fails, the packet does not disappear into a message stream. It comes back with the new evidence, the attempted route, the changed risk, and a clear question.
This separation matters. A system that can describe and route every problem should not automatically have the power to change every system it can see.
From engineer to product manager
This is the role change I am trying to create for myself.
I do not want to be the senior engineer in every stand-up, reconstructing context and assigning every fix.
I want to act more like the product manager and accountable owner:
- understand the outcome;
- see material problems;
- question the diagnosis;
- set the priority;
- approve the boundary;
- review the evidence;
- change the operating rule when we learn something.
Anthropic describes effective agents as systems that use tools and environmental feedback in a loop, while its evaluator-optimizer pattern separates generation from review. That separation is useful here too. The agent that finds a problem, the agent that assesses it, the human who authorises it, and the worker that changes the system do not all need to be the same powerful thing.
That is slower to design than one giant agent with every permission.
It is also much more likely to become a business I can understand.
Do not force agents to work like humans
The wider lesson is that we should not automatically reproduce human systems for agentic work.
Humans need dashboards, lists, forms, notification screens, stand-ups, and tickets partly because our memory and attention are limited. Agents can carry metadata, search histories, gather evidence, create a fresh view on demand, and hand structured meaning directly to another agent.
Humans still need visibility and control. But visibility does not have to mean staring at a backlog.
For me, the work packet is becoming the unit that connects the two worlds:
machine-readable enough for agents to act, and human-readable enough for me to judge.
That is today's work in building the Chief Agentic Officer business.
Will it solve the scaling problem?
I hope so.
More importantly, it gives me a way to find out without handing the whole company to one clever model and hoping for the best.
In this series
- Part one: Chief Agentic Officer Briefing: Creating An Agentic Business
- Part two: The Podcast Was Easy. Publishing It Wasn't.
- Part three: Making Agentic Work Visible
Sources and notes
Work packets are my current field implementation inside the Chief Agentic Officer and Orchistra work. I am not presenting the term as an established industry standard. The supporting research below informs the surrounding design: bounded tools and guardrails, evaluator loops, durable state, explicit human review, failure thresholds, and auditable outcomes.