Articles
The Agent is Rarely the Problem
Gartner expects a large share of agentic AI projects to be abandoned within the next year. When that number gets quoted, the implied conclusion is usually that the technology is not ready yet.
That is not what we see. In most failed projects, the model did roughly what it was asked to do. The problem was what it was asked to do, and the process it was asked to do it inside.
Dr. Daniel Tiarks, Co-Founder and CTO of Cambrion, made this argument in a recent InformationWeek piece on why agentic projects collapse. The article had room for the headline version. This is the longer one, because the interesting part is not that process design decides the outcome. It is which design decisions decide it, and when you have to make them.
The wrong first process
The most common mistake happens before any engineering starts.
A team looks for a first use case and picks the impressive one. Something judgment-heavy, something that sounds like it needs intelligence, something that will look good in front of the steering committee. It demos beautifully. Everyone in the room nods.
Then it goes to production and meets the real workflow, which turns out to have undocumented exceptions, two people who disagree about who owns step four, and one colleague who simply knows how it actually works and has never written any of it down.
The agent does not fill those gaps. It has no way of knowing they exist. It will produce something confident and wrong, or something unpredictable, and it will do so at whatever volume you pointed it at.
The processes where agents actually pay off look different. High volume. Well bounded. And, critically, they have a right answer that someone can check. An invoice either has the correct line items or it does not. A test protocol either transcribes the measured value correctly or it does not. Nobody applauds during that demo. It is also the one that survives contact with production.
Six decisions that determine the outcome
None of these are model choices. All of them happen before the first prompt is written.
Start with one bounded process that has a clear right answer.
Bounded means you can describe the input space and the expected output without saying “it depends.” Clear right answer means correctness is verifiable, not a matter of taste. If you cannot tell whether the agent was right, you cannot tell whether it is working, which means you will find out from a customer complaint instead of from your own monitoring.
Wrap the model in deterministic validation, and keep a human gating the edge cases.
A language model is a probabilistic component. That is fine, as long as you do not treat its output as final. Around it belongs deterministic logic: schema constraints, cross-field checks, arithmetic that has to add up, lookups against systems that already hold the truth. Anything that fails those checks does not flow downstream. It goes to a person.
This is the part teams most often skip, because it is unglamorous plumbing rather than AI. It is also what turns a demo into something an operations team will actually let run.
Define the accuracy and throughput you need before you start.
Write down the number first. Not “high accuracy,” an actual threshold, tied to what the downstream process can absorb. Then measure against it continuously, on real documents, not on the twelve examples used during the pilot.
Teams that skip this end up in an argument about whether the system is good enough, with no shared definition of good enough. That argument has no ending.
Demand traceability.
Every extracted value should point back to where it came from in the source: which document, which page, which position. Not as a nice-to-have for debugging, but because in a regulated or audited environment, an output nobody can explain is an output nobody can defend.
This matters more than it used to. When a decision is contested months later, “the model said so” is not an answer. “Here is the field, here is the page it came from, here is the validation rule it passed, and here is who released it” is.
Treat the model as swappable infrastructure.
The frontier moves every few months. Binding an architecture to one provider’s model means inheriting that provider’s pricing, availability, roadmap, and jurisdiction. Keep the model behind an interface. Assume you will change it, because you will.
This is also a sovereignty question, not only an engineering one. Where the model runs, and under whose legal regime, is a design decision with the same weight as any other.
Redesign the process around where the agent is reliable.
The last one is the hardest, because it is organizational rather than technical. If a workflow only functions because experienced people know its workarounds, automating it faithfully just automates the workarounds. The work is to find the part of the process where a machine is genuinely reliable, put it there, and rebuild the surrounding steps around that boundary, including the point where a human takes over.
What this looks like in practice
The document workflows we work on are unglamorous by design. Commercial invoices in customs clearance. Handwritten test protocols in a lab. Technical datasheets feeding an engineering calculation. Patent documents that need to land in one searchable schema.
None of these are impressive use cases. All of them are high volume, bounded, and verifiable, which is exactly why they work. The teams running them care about the same three things every time: is it right, can I see why it said that, and what happens to the cases it is unsure about.
That is the whole conversation. It has almost nothing to do with which model is underneath.
The uncomfortable summary
If your process only works because someone knows the workarounds, an agent will not fix it. It will fail faster, and at scale.
The good news is that the reverse is also true. Process design is something you control, on your own timeline, with people who already understand the work. You do not have to wait for a better model. Most of the projects that succeeded did the boring part first.
