The default enterprise AI strategy goes something like this: hire an agent to be a software engineer. Give it the codebase. Let it fix bugs, review PRs, write changelogs. Give it a role. Expect it to fill the seat. This is the trap.
The problem is not that role-based agents cannot do these things in a demo. The problem is what is hidden behind the demo: the staggering amount of context engineering required to make any of it work in production. Every codebase has legacy corners. Every team has a specific design system, a specific PR convention, a specific changelog format. The agent does not know any of this on day one, and teaching it is not a configuration step. It is an ongoing software engineering effort that scales with the breadth of what you ask the agent to do.
When you start with a role, you are starting with the hardest possible version of the problem.
There is another way. Instead of starting at the top with a role and figuring out the context, start at the bottom. Pick one specific, repeatable workflow. Make the agent do that one thing well. Then add the next. This is not a new idea — it maps directly to the microkernel versus monolithic kernel debate from decades ago. The history of infrastructure suggests composability wins over time, even when the monolith looks more impressive in the short term.
A workflow-based agent starts with a specific chore. Writing a changelog every week. Enriching new leads in a CRM. Running a deterministic guardrail check on every deployment. The context engineering is scoped and manageable. Over time, you compose these workflow agents into something that resembles a role — but built up from a foundation that actually works. I've argued elsewhere that most enterprise agent value comes from triggered workflows, not from anyone typing into a chat box. Start there.
Related Essays
What Workflow-First Looks Like in Practice
A customer success team, five fragmented systems, and a workflow agent that ships in a week. How small scoped wins compose into something that looks like a role.
The Primitives Are the Same Across Roles
Sandbox, tools, prompts, governance — the primitives are universal. Engineering agents and GTM agents share the same engine. Only the body changes.
Agents Are About to Break Out of Engineering
Non-engineering agents are easier to build but harder to contextualize. The organizational knowledge layer — not the execution layer — is the real unsolved problem.
Key takeaways
- Role-based agents fail because context engineering scales with the breadth of the job.
- Workflow-based agents scope context to a single task and compound over time.
- Composability beats the monolith — every infrastructure wave proves it again.
FAQ
Why do role-based agents fail in production?
They require unbounded context engineering. Every legacy corner, every design system convention, every team-specific norm has to be taught. The burden scales with role breadth, so the agent never reaches a stable, trustworthy baseline.
What does a workflow-first approach actually look like?
Pick one repeatable chore — writing a changelog, enriching a lead, running a guardrail check. Make the agent do that one thing well. Add the next. Compose them later into something role-shaped that actually works.