As we continue the series Learning AI by using AI, I'm exploring what human organizations and AI teams have in common, and how they respond differently to the same problems.
Working in a large organization, I know how slow and painful a process designed for every situation can become.
Part of my job is applying common sense: matching what needs to be done to the real needs and implications of the situation. I connect the people or resources needed directly, realign priorities and, when necessary, accept the risk.
In my personal agentic AI project, I started with a simple question: could a group of agents, each with a role, deliver software without me coordinating every handoff?
The first design looked like a small organization: Architect, Developer, QA and Coordinator, each in its own box. It looked tidy, which should have been the first warning.
The roles were easy to name. I spent most of the project working out what happened between them.
What did the next agent need to know? Who could decide that the work was good enough? And when someone rejected it, where did it go?
I couldn't rely on my agents to exercise that kind of organizational judgment. In the workflow I built, a next step had to be defined before it could run.
I had to describe what should happen after a handoff, a rejection or an interruption. The combinations produced many possible states, each needing a route forward or a reason to stop for me.
The next person needs enough to continue
Think about receiving a piece of work for review. You need to know what you're being asked to decide, which version you're looking at and what supports the conclusion.
If you send it back, someone needs the reasons and a clear way to try again. A rejection is another handoff.
I built the agent workflow around written records: tasks, decisions, evidence and run history. After a pause or a failure, a fresh agent could pick up those records and continue.
Permission needed separate attention. An architecture review found that a specification written by an agent could become a source of authority for that same agent.
I separated the working material from the record that defined scope, tools, budget and approval. An agent could propose doing more; permission to do it had to come through that separate record.
It's a familiar distinction in an organization too. Receiving a request doesn't automatically give you the authority to carry it out.
A rejection left the work stuck
Designing the graph means deciding where judgment is useful and where a rule must hold every time. An LLM can suggest a different route or assess a situation, and its answers can vary. Permissions, required approvals and spending limits need checks in code.
Company context helps the agent interpret the situation. The graph also needs to define what evidence allows work to move, when to retry and when the decision comes back to me.
The simulation passed the safety rules I'd written for the workflow. The first live content run then stalled on 2 draft rejections.
Each rejection left the workflow in a state with no permitted next action. It had recorded the decision and had no way to resume the work.
I'd tested the process I'd described. Live work exposed a situation that description hadn't covered.
The correction was to give the stuck state a defined exit. Someone also has to own the revision and know what would make another attempt acceptable.
A colleague might ask around and find a way forward. My workflow needed that route written into it, with a clear point at which the decision came back to me.
Those connections became the operating model. A graph is a way to describe them: who takes part, how work moves between them and what must be true before it can move again.
The gap was visible because the work stopped. In a human team, the person quietly sorting it out can make the same gap much harder to see.
Judgment needs company context
Giving an agent that kind of decision to make requires the context of the organization. It needs to know what matters now, what has changed and what people have already agreed.
People pick up some of that context at the coffee machine or in a conversation across the aisle. A decision made there can change what should happen next, even when the written process stays the same.
Building that knowledge base, and keeping it current as decisions change, is work the organization has to do.
If a priority changes, a risk is accepted or someone agrees a different route, that needs to reach the record. Otherwise, the agent is working from a picture of the organization that people have already moved beyond.
The community's work on shared context provides places to keep and share that record.
OpenClaw's shared sessions have an assignable owner and separate rights to view, suggest or contribute. Responsibility can change while the working context remains in place.
Paperclip documents how agents resume the same task context across runs, with approval gates and a history of configuration changes that can be rolled back.
Follow the work, and the decisions around it
Choose a result that matters in your organization and follow it across the teams involved. Look at what happens when evidence is missing, a reviewer disagrees or the work pauses halfway through.
Then talk to the person who gets it moving again. Who needed to be connected, which priorities changed and who accepted the risk?
Check whether those decisions reached the shared record. The next person or agent needs to know what was decided and why.