Fire the Traffic Cop
How intent-based routing makes managers obsolete as dispatchers, and essential as capability builders
Deep Dive #2 in “The Agentic Enterprise” Series
Stop assigning work. Let work find the capability it needs.
This is not an abstract aspiration. It is a design principle with forty years of engineering precedent behind it. The question is not whether intent-based routing is possible. The question is why we persist with the alternative when the alternative performs so poorly.
The Manager as Bottleneck
Watch how work moves through a traditional organisation. A customer submits a complaint. It hits a shared inbox. Someone triages it. If it is complicated (product defect, billing dispute, and process failure simultaneously), it escalates. Escalation means a manager review, a meeting that takes three days to schedule, twenty minutes of context-setting, and a response nine days after the original complaint.
Every step is a management decision: who handles this, what priority, which teams. The manager is not adding value by answering these questions. The manager is adding latency. The answers could be derived from the nature of the complaint itself if the organisation had the systems to do so.
The root cause: work is push-based. Work gets pushed onto people by whoever has authority to assign it. Remove the manager from the loop and work has no way to move. The organisation has no pull mechanism.
The Pull Principle
Toyota solved this in manufacturing. The kanban card, a signal travelling upstream to authorise production only when a downstream stage consumed something, made the customer’s actual consumption the trigger for all upstream activity. No forecast, no manager’s judgment. David Anderson extended this to knowledge work: make queues visible, apply work-in-progress limits, and performance improves immediately. Not because the work changed, but because the system dynamics became manageable.
Software engineering took the same insight further with message-driven architecture. Services publish events to a shared bus. Other services subscribe to events they can handle. No central dispatcher. The routing is emergent, arising from what events are published and what capabilities are declared. Apache Kafka operationalises this at scale: events flow to topics, consumers process what they can handle, the system routes itself.
The organisational parallel is direct. A work item is an event. It carries its full context: what it is, what it needs, what “done” looks like. A skill registry declares what each capability can handle. The routing is automatic: match requirements to available capabilities.
Intent, Not Tasks
The shift from task assignment to intent routing requires a different way of defining work.
A task definition: “Review the vendor contract for the Acme Software engagement.” It specifies action, subject, assignee. What it omits: what the review should assess, what a satisfactory outcome looks like, what constraints apply, what to do if the contract fails on multiple dimensions.
An intent definition: “We need a vendor contract with Acme Software for a twelve-month engagement with maximum liability of EUR 500k, GDPR compliance, and thirty-day termination. Ready to sign by end of month.” It specifies outcome, constraints, and timeline. Not who does it or how.
The intent definition is far more useful. A cell with the right capabilities can take it and execute without a manager clarifying what “done” means. The routing becomes straightforward: which cell handles vendor contracts for software engagements with these parameters? Route to them.
This requires discipline — capturing the “why” and the “what” rigorously before work begins. Defining done criteria in observable, verifiable terms. Encoding context into the work item rather than assuming someone will brief it verbally. Hard, yes. But it is the necessary foundation for any autonomous routing, whether the agents are AI or human.
What Managers Do Instead
The objection is always: “But who is in charge?” The assumption is that without a manager assigning work, nothing gets done. Self-organising teams consistently outperform assigned teams on complex tasks, but the assumption persists.
The manager’s value is not in routing decisions. Routing decisions are coordination overhead. The value is in capability building: ensuring the right skills exist in the team, developing people, removing systemic obstacles, building cross-team relationships. A manager who spends most of their time deciding who does what today has no time to invest in making the team better tomorrow. The assignment overhead crowds out the development work.
Remove the routing decisions and the manager’s time opens for what actually creates long-term value. Coaching. Capability building. Systems improvement. Strategic learning. Not making managers redundant, making them valuable in a different, better way.
How Agentic Cells Implement This
In an agentic enterprise, intent-based routing is not a philosophy. it is the operating system.
Each cell declares its capabilities in a machine-readable skill registry: what work types it handles, what inputs it requires, what outputs it guarantees, what capacity it has right now. When a work item enters the system “customer complaint, compliance review, vendor contract” it carries structured intent: outcome needed, constraints, context, deadline. The routing layer matches intent to capability automatically.
Here is what changes practically. A customer complaint arrives as a structured event. The system evaluates its dimensions — product defect, billing dispute, regulatory implication — and routes it to the cell (or cells) with matching capabilities. If the complaint requires capabilities from multiple cells, the system composes a workflow across them. No manager triages. No meeting gets scheduled. The complaint starts moving toward resolution in seconds, not days.
AI agents participate as capability providers in this same system. An agent that can assess contract compliance against GDPR requirements registers that capability. When a vendor contract with a GDPR constraint enters the system, the agent pulls it. The routing logic does not care whether the handler is human or AI. It cares about capability match and outcome delivery.
The cells themselves operate on pull. Team members, human and AI, pull the next appropriate item when they have capacity. Work-in-progress limits prevent overloading. The constraint becomes visible and managed rather than hidden in someone’s inbox.
This is where traditional organisations stumble when adopting AI. They bolt AI agents onto push-based systems and wonder why the results disappoint. The AI cannot navigate push systems any better than humans can. It still needs a manager to assign work, clarify context, and define “done.” Give AI clean intent, explicit capabilities, and real-time feedback through a pull system, and it performs.
The organisations that will capture the most value from AI are the ones already operating on pull principles. Not because pull is fashionable, but because pull is the prerequisite for AI to participate meaningfully in work. AI needs the same things that performance requires: visible work, explicit intent, declared capabilities, and closed feedback loops.
Start by making work visible. Define intent before you define tasks. Declare capabilities explicitly. Implement pull. Measure lead time, queue sizes, and rework rate. These are the signals that tell you whether the system is performing.
Next in the series Deep Dive #3: The Amnesia Tax — Why your organisation forgets everything it learns, and the compound interest you are leaving on the table