For a long time, I thought "AI-native" meant building everything around AI. If it's AI-native, the agent should be the center of gravity, right?
That's what I assumed. And I was wrong.
To be fair, I never built KB Labs entirely around AI. The model was carefully embedded into the platform — it could work with it, not replace it. Commands had multiple output formats: human-readable and machine-readable. The AI was a participant, not the owner.
But then I started going deep on agents. And that's where things got messy.
When the agent does too much
I spent months trying to build the entire workflow around agents. The agent decomposes the task. Plans the work. Implements it. Runs checks. Triggers the feedback loop. Then loops again.
It sounds elegant on paper. In practice, the agent ends up doing a mountain of work that isn't really its job.
Decomposition? That's a process concern. Quality gates? That's an organizational concern. Feedback loops? Those are coordination mechanisms. None of these belong inside an agent's prompt. They belong in the system around it.
The enterprise problem
Here's another thing that broke for me: company processes.
Real companies have security reviews. Architecture checks. Compliance gates. Style guides. Approval flows. How do you feed all of that to an agent? How do you add a new check without rewriting the agent's instructions?
When everything lives inside the agent, every new requirement means touching the agent. That doesn't scale. It turns your "autonomous AI system" into a fragile monolith that breaks every time someone adds a checkbox.
How it actually works in real life
Step back and think about how engineering teams work without AI.
There's a process. A developer is one step in that process. They write code. Then a gate kicks in — QA finds a bug, creates a report, developer goes back and fixes it. The developer doesn't own the process. The process owns the flow. The developer is a participant.
That's the model that works. And it's exactly the model I moved to.
Process-first, agent-second
In KB Labs, the workflow now looks like this:
There's a defined process. The agent works inside one stage of it. At the end, there's a separate block — quality gates, automated checks, reviews — that produces a pool of findings. Those findings go back to the agent for fixes.
The agent doesn't decide what to check. The process does. The agent doesn't decide when it's done. The gates do.
On the output side, you get a predictable, verifiable result. One that was validated by automated and manual checks — not by the agent's own judgment about whether it did a good job.
Why this matters
Agent-centric design is seductive because it looks like progress. One prompt, one system, handles everything. But it's a trap:
- It doesn't scale. Every new requirement means rewriting agent behavior.
- It's not auditable. You can't point to where the check happened.
- It's fragile. The agent's context window is the single point of failure.
- It's not composable. You can't swap out one step without touching everything.
Process-centric design is boring. It's just stages, gates, and feedback loops. But boring is what works in production. Boring is what lets you add a security check without rewriting your AI pipeline. Boring is what gives you a result you can actually trust.
The agent is a powerful executor. But it's not a process manager. Stop asking it to be one.