2026-08-09 · Frameworks

Choosing an AI agent framework when a supervisor will read the transcript

The comparison articles all measure the same things. Orchestration expressiveness. State persistence and checkpointing. Multi-agent handoff ergonomics. Developer experience and download counts. LangGraph gets credit for explicit control over state transitions, CrewAI for a fast role-based abstraction, the OpenAI Agents SDK for a small surface with built-in tracing, and the recommended pattern is often to combine them.

All of that is real and none of it decides a deployment in a bank, an insurer, or a hospital. Those decisions turn on a different set of questions, and they get asked by people who will never read the orchestration code.

Disclosure. We build one of the options discussed here. The recommendation at the end includes the cases where you should not use it, because a framework comparison that concludes "use ours" for every scenario is worth nothing.

Four questions that actually decide it #

Where are the rules enforced, and can a non-engineer read them? If the answer is "in the system prompt", the rules are not independently enforced and cannot be reviewed by the people accountable for them. Why that matters.
What stops a bad change from shipping? A release process that relies on someone reading a diff and running the agent by hand is not a control. There has to be a gate that fails the build.
What can you show eighteen months later? Not logs. A record where tampering is detectable and where each conversation resolves to the exact version of the configuration that produced it. What that contains.
Where does the data run, and could you leave? Under DORA's third-party regime this is a register entry and an exit-strategy question, not a preference. The consequences.

Notice that none of the four is about agent quality. Quality is table stakes and every serious option clears it. These are the questions that determine whether the thing can go to production at all.

Orchestration frameworks #

LangGraph gives the most explicit control over state transitions, with checkpointing and rollback, which is genuinely why enterprise teams picked it up through early 2026. Its graph model makes execution deterministic and inspectable, and that is a real asset in a regulated setting. What it does not give you is a policy layer with independent enforcement, an eval gating system, or a tamper-evident audit store. Those remain yours to build, and the graph being auditable is not the same as the deployment being audited.

CrewAI optimises for speed of assembly with role-based agents, and it is excellent for that. The abstraction deliberately trades fine-grained control for simplicity, with limited control over agent-to-agent communication. For a regulated deployment where you need to reason precisely about what happens between two steps, that trade goes the wrong way.

The OpenAI Agents SDK has a small, clean surface, parallel input validation that halts on failure, and tracing through the provider's observability platform. The guardrail primitives are the closest of the three to what this article is about. The catch for a bank is in the last clause: the tracing path and the default deployment shape assume a provider relationship, which is exactly the dependency the third-party regime asks you to minimise.

Pydantic AI deserves a mention for treating validation as a first-class concern, which removes an entire class of failure at the tool boundary. It is a strong foundation and a small part of the total requirement.

Guardrail libraries and conversation control #

NeMo Guardrails and Guardrails AI both do independent, declarative rule enforcement, which is the first question answered properly. Bolting one onto an orchestration framework is a legitimate architecture and plenty of teams run it.

Parlant is the most interesting adjacent option, because it is built around compliance-minded conversation control rather than around orchestration. If your problem is purely "keep the conversation inside defined behaviour", it is worth a look. It does not bring an eval and regression system, a feedback loop, or a banking-specific scorecard.

The pattern to notice: each of these solves one of the four questions well. The integration between them, and the evidence that the integration works, is where the effort goes.

Hosted agent platforms #

Hosted platforms answer questions one and two well, often better than anything you would build, with policy consoles and release workflows that are genuinely mature. They answer question three partially, with audit features that are usually adequate. Question four is where they struggle, and not because of any deficiency in the product: customer conversations are in the vendor's infrastructure, the agent definition is in the vendor's format, the audit trail is subject to the vendor's retention, and the exit strategy depends on an export endpoint working when you need it.

If your institution is comfortable with that as an ICT third-party arrangement, and some are, a hosted platform is a reasonable and fast choice. The point is to make that a decision with its diligence attached, rather than something discovered at the first resilience review.

The glue-code estimate #

Teams that pick a generic framework and plan to add the rest usually underestimate the remainder. In our experience the list is:

A policy layer with pre and post rules, judge-backed refusals with a strictness setting, and hard blocks that cannot be configured off.
A deterministic rule engine for windows and contact caps, with a ledger keyed on a customer reference so counts work across channels.
An eval harness with cohorts, worst-cohort gating, a judge from a different model family, and a handoff grader that inspects whether escalation actually happened.
A hash-chained audit store with config hashes, a verification command, and a production-grade backend.
A handover path with resume, wired into wherever your humans already work.
A feedback loop that promotes production failures into regression cohorts.
Channel adapters, with session identity namespaced so ids from different channels cannot collide.
Redaction before provider calls that does not corrupt the audit record.

Each item is a few weeks including the tests that make it trustworthy. It is a year of platform work before the first agent does anything a customer notices, and it is the same year at every institution, which is the observation the project started from.

How to choose #

Use a generic orchestration framework when the agent is internal, the data is not sensitive, no supervisor will ever ask about it, or the workflow is genuinely complex in shape and orchestration expressiveness is the binding constraint. Most agent projects are here, and reaching for a compliance-oriented platform would be over-engineering.

Use a hosted platform when speed matters more than the third-party position, and your risk function has explicitly accepted that position.

Use something built for this when the agent talks to customers about money, health, or access to a service; when a rule breaking would produce a complaint or a fine; when the record has to survive years and a change of team; or when your risk function has already told you the data cannot leave. That is the case Zolva is built for: agents as YAML plus Markdown, your APIs as typed tools, guardrails as config on a middleware bus, CI-gated evals, a hash-chained audit, human handover with resume, and synthetics, installed inside your own perimeter with pip install zolva and Apache-2.0 licensed so your security team can read every line.

The honest summary: if none of the four questions applies to your project, do not pay the cost of answering them. If two or more do, they will be answered eventually, and the expensive path is answering them after the first deployment rather than before.

Start with the quickstart, the use cases, or the playbooks if you want working code first.

← All posts