There is a version of "agentic AI" that is mostly a wrapper: take a language model, give it some tools, let it call them in a loop, and call the result an agent. It demos well. It falls apart the moment it meets a workflow that actually matters — one that spans many steps, runs over minutes or hours, touches real systems, and cannot afford to be wrong.
At Althea, our agents operate in healthcare workflows where the tolerance for error is low and the work is genuinely multi-step: a single task might require gathering information, coordinating across systems, waiting on external responses, making decisions, and handing off to a human at exactly the right moment. Making that reliable is not a prompting problem. It is an orchestration problem, and orchestration is where the real engineering lives.
Autonomy is not a longer chain
The intuitive model of an agent is a chain: think, act, observe, repeat. For simple tasks this works. But a chain has a brutal property — its reliability is the product of the reliability of its steps. Ten steps that are each 95% reliable give you a workflow that succeeds barely more than half the time. In a high-stakes setting, that is not a system; it is a liability.
Reliability compounds in the wrong direction. The naive fix is "make the model better." The real fix is to design the system so that no single step's failure is fatal.
Real autonomy comes from the structure around the model: the ability to verify a step before committing to it, to recover when a step fails, to break work into pieces that can be checked independently, and to know when to stop and ask a human. None of that is in the model. All of it is in the orchestration layer.
The arithmetic is worth sitting with, because it's the whole argument in miniature. People reach for "make the model better" because it feels like the lever that matters. But going from 95% to 97% per step barely moves a ten-step workflow from coin-flip to merely-mediocre. Going from no verification to verify-and-retry on each step can take that same workflow from 60% to 99%, with the exact same model. The leverage is in the structure, not the step. Once you internalize that, you stop trying to pray the model into reliability and start engineering the system to tolerate an unreliable one.
What reliable orchestration actually requires
Building this layer well means borrowing hard-won lessons from distributed systems and applying them to a substrate — the language model — that is probabilistic rather than deterministic. A few things matter most:
- Decomposition. Break a workflow into steps small enough to verify. A step you can check is a step you can recover from; a monolithic "do the whole thing" call is one you can only succeed or fail at.
- Verification and grounding. Don't trust a step because it sounds confident. Check it against ground truth — a database, a tool result, a constraint — before acting on it. The most dangerous output is a plausible wrong one.
- State and memory. Long-running, asynchronous workflows can't hold everything in a context window. The system needs durable state: what's been done, what's pending, what's been verified, what's waiting on the outside world.
- Idempotency and recovery. Steps fail, calls time out, external systems hiccup. The orchestration has to retry safely, resume from where it stopped, and never double-act on something that has side effects in the real world.
- Human-in-the-loop by design. The question is not whether a human is involved but where. The system should escalate precisely when confidence is low or stakes are high, and the handoff should preserve full context.
Verification is the load-bearing wall
If I had to name the single most important of these, it's verification — because it's what breaks the compounding curse. An unverified step passes its errors silently downstream, where they grow. A verified step is a checkpoint: you confirm the result against something real before you let the workflow build on it. The model proposes; the system disposes.
What "ground truth" means is domain-specific, and getting it right is most of the work. Sometimes it's a database lookup that confirms a record actually exists before you act on it. Sometimes it's a tool whose output is authoritative where the model's is not. Sometimes it's a constraint that a valid result must satisfy — a date that has to be in the future, an identifier that has to match a known format, an amount that has to fall in a plausible range. The pattern underneath all of them is the same: never let a step that sounds right become a step the system treats as right without an independent check. In a setting where being wrong has consequences, confidence is not evidence.
Parallelism is the leverage — and the hazard
The workflows we run are not just sequential. Many steps are independent and can run concurrently; others depend on external responses that arrive asynchronously. Parallelizing across these is where you get real throughput — the difference between a system that handles one conversation at a time and one that handles a population.
But parallelism multiplies the failure surface. Concurrent steps can race, partial failures can leave a workflow in an inconsistent state, and asynchronous waits can strand work indefinitely if you don't design for it. The same systems-design principles that make large-scale distributed systems work — clear ownership of state, well-defined boundaries between steps, graceful degradation, observability into what every agent is doing — are exactly what make large-scale agent orchestration work. The fact that the steps are LLM calls instead of microservices doesn't change the fundamentals. It raises the stakes, because the steps are less predictable.
Asynchrony is the part everyone underestimates
The demos that go viral are synchronous: ask, watch the agent work, get an answer. Real workflows are not like that. A task waits on a callback that may arrive in seconds or in days. It depends on a human who is asleep, or a third-party system that is down for maintenance, or a response that never comes at all. The agent cannot sit in a loop holding its breath; the work has to be suspendable — parked durably, resumed when the world is ready, and never lost in the meantime.
This is where a lot of "agent frameworks" quietly fall over, because an in-memory loop with a context window is exactly the wrong abstraction for work that outlives a single process. You need the workflow's state to live somewhere durable, you need timeouts and escalations for the waits that never resolve, and you need every externally-visible action to be safe to retry, because at some point the process will crash mid-flight and come back. None of this is glamorous. All of it is the difference between a system that works in a demo and one that works on a Tuesday at 3 a.m. when something upstream has failed.
Side effects are the line between a demo and a deployment
There's a category difference between a step that reads and a step that acts, and it's the difference that makes orchestration genuinely hard rather than merely fiddly. A step that retrieves information can be retried freely; if it fails, you try again and nothing in the world is worse for it. A step that does something — sends a message, books something, updates a record, triggers a downstream process — cannot be retried casually, because the world remembers. Run it twice and you've acted twice.
This is why idempotency stops being a textbook concern and becomes a daily one. Every externally-visible action has to be designed so that "did this already happen?" is a question the system can answer before it acts, and so that a retry after a crash doesn't double-act. In practice that means actions carry keys the orchestration can check, the system records its intent durably before it acts and the outcome durably after, and recovery logic always asks the world what state it's actually in rather than assuming. It's unglamorous plumbing. It's also exactly what separates a system you can let touch real things from one you can only show in a controlled demo where nothing it does is permanent.
The deeper point is that the probabilistic nature of the model makes all of this more important, not less. With deterministic software you can at least reason about what a component will do. With a model in the loop, you have to assume any given step might do something unexpected — which means the safety has to live in the structure around it: in what actions are even reachable, in what gets verified before it commits, and in what is reversible if it turns out to be wrong.
Observability: you can't fix what you can't see
There's a final piece that doesn't fit neatly into the list above but quietly determines whether any of it survives contact with production: observability. When a workflow spans dozens of steps, runs across minutes or hours, fans out into parallel branches, and waits on external systems, "it failed" is not a useful statement. You need to be able to answer where it failed, why, what the state was at the time, and what the system believed when it made the decision that went wrong.
This is harder with agents than with ordinary software, because the steps are probabilistic. The same input can produce different behavior on different runs, so you can't always reproduce a failure by replaying it. That makes recording the actual trajectory — every decision, every tool result, every verification outcome, every point where confidence dropped — not a nice-to-have but the only way to learn from production at all. The systems that improve over time are the ones instrumented well enough that a human can look at a failed run and understand it. The ones that don't get instrumented stay mysterious, and a mysterious failure in a high-stakes setting is one you're doomed to repeat.
Observability is also what makes the human-in-the-loop handoff actually work. When the system escalates, the human inheriting the task needs full context — not "something went wrong," but the whole trajectory that led here, so they can step in informed rather than starting from scratch. A handoff that loses context is barely better than no handoff at all.
The orchestration layer is the product
What I keep coming back to is that the model is a component, and the orchestration is the system. The model gives you a capable, unreliable step. The orchestration is what turns a capable-but-unreliable step into a workflow you can actually deploy in a setting where being wrong has consequences.
This is also why I'm skeptical of the idea that better models alone will get us to dependable autonomy. Better models make each step better, and that helps. But the behavior of the whole system — whether it recovers, whether it stays consistent under load, whether it knows its own limits, whether it brings a human in at the right moment — is a property of the architecture, not the model. A 10% better model wrapped in a fragile loop is still a fragile system.
Healthcare is our proving ground precisely because it is unforgiving. But the underlying platform is not really about one vertical. It is a testbed for a more general question: how do you get AI systems to do real, multi-step work, continuously, reliably, over time — and adapt as they go? That is the question I think defines the next era of these systems. And the answer, over and over, turns out to live in the orchestration.