A Constitution You Can Run: Building Governable Agents for Real Work

A simple test for any "agentic" system is this: could you defend its output in a meeting where money, compliance, or real operational risk is on the line? Most of the current wave can't—not because models are weak, but because the systems around them are built on a quiet assumption: that fluent output is close enough to correct decisions. In a demo, that assumption is harmless. In production, it becomes expensive. Hope is not a strategy you can sell to an enterprise. Hope that a model will not hallucinate something important. Hope that retrieval will pull the right document. Hope that confident language correlates with correct judgment. Hope that today's answer will be the same tomorrow if the inputs are the same. Enterprise software earns trust the boring way: reproducibility and traceability. Same inputs, same outputs—plus an audit trail that lets teams explain decisions after the fact, correct them without guesswork, and prove what was true at the time a recommendation was made. That is the idea behind a constitution you can run. Not a values manifesto, and not a motivational slogan about being helpful. A runnable constitution is a set of enforceable constraints, evidence requirements, evaluation gates, and runtime controls that shape behavior when the world is messy and the inputs are incomplete. This post is about how to build those controls. The argument is straightforward: if you want autonomy, you have to earn it. Governance is how you earn it.

This Is Not Hypothetical. In 2026, Governance Has Teeth.

The regulatory and market environment has fundamentally shifted. The EU AI Act is being phased in through 2026, with fines reaching up to €35 million or 7% of global revenue for non-compliance with governance requirements for high-risk AI systems. In the United States, the FTC has issued enforcement actions against companies for algorithmic bias, inadequate AI transparency, and failures to monitor automated decision-making systems. Enterprise buyers are responding accordingly. Governance is no longer a "nice to have" checkbox on procurement forms. It is a design requirement. Organizations that treated it as optional are now scrambling to retrofit controls onto systems that were never built to be auditable. The ones that built governance as infrastructure from the start are scaling.

The market is stratifying along a simple line: systems you can defend versus systems you cannot.

When Agents Stop Assisting and Start Deciding

A lot of the excitement around agentic AI comes from watching a model do what used to take a person: navigate tools, fill forms, draft emails, perform research, take actions. It feels like leverage. But there is a sharp boundary that many products blur: the difference between assisting and deciding. Assistance is tolerant of error. If a draft is wrong, you fix it. If a summary misses nuance, you refine it. The cost of a mistake is mostly time. Decisions are not tolerant in the same way. The output becomes a recommendation that changes behavior: people allocate budget, commit to timelines, pick a vendor, file an application, or claim compliance. The cost of a mistake is not a typo; it is a wrong action that often cannot be undone cheaply. That is why enterprise buyers eventually ask the same questions, regardless of domain:

Why did we recommend this?
Where does that claim come from?
Which rule or source would change the outcome?
Would we make the same call tomorrow with the same inputs?

If your system cannot answer those questions without hand-waving, it is not "agentic." It is fragile.

A Stress Test: Why Funding Matching Breaks Naive Agent Designs

Some problem classes force the issue quickly. Funding matching is one of them. From a distance, it looks like similarity search with a clean UI: a project goes in, a program goes in, a score comes out. Add a plausible explanation and it looks like an assistant. In practice, it behaves like a decision workflow with hard edges. A funding document can read like a perfect fit and still fail on criteria that do not negotiate. Region eligibility matters. Company size matters. Some programs require cooperation partners. TRL boundaries quietly exclude projects that look "innovative enough" in prose. Timing windows invalidate plans that are otherwise solid. Stacking caps change the economics. Budget structure rules can make a nice-looking proposal ineligible. This is why real advisory work in this domain rarely looks like summarization. It is closer to triage and judgment: what is clearly admissible, what is borderline, what needs escalation, and what cannot be assessed yet because key inputs are missing. Many "agentic" demos fall apart here for a predictable reason. They optimize for fluent output and for the appearance of certainty. They smooth over gaps because hesitation looks bad in a slide. In enterprise settings, hesitation is normal. The failure mode is not uncertainty; the failure mode is hiding it. A governable approach therefore starts with goals that sound boring because they are precise. Preserve recall early by casting a wide net so plausible candidates are not missed, then narrow the funnel with hard checks that reject options deterministically when eligibility or caps fail. When the system recommends something, it should do so with evidence—citations, rule references, and the path that led to the conclusion—rather than with a persuasive story. And when information is missing, the system should surface it directly and drive the workflow to request it, instead of improvising. Once you take those constraints seriously, the system stops resembling a single "agent call" and starts resembling controlled work: propose, check, reconcile, explain, and record.

The Core Insight: Semantics Can Propose, But They Cannot Decide

Semantic methods are excellent at discovery and ranking. That is exactly where they belong: early in the funnel, when the system is exploring a space and trying not to miss candidates. Eligibility and compliance belong later, when the system is narrowing down decisions under constraints. In that phase, semantic similarity is not a safe authority, no matter how plausible it sounds.

A robust pipeline keeps responsibilities separate.

Semantic retrieval proposes candidates and semantic fit estimates thematic alignment. A deterministic engine checks rules, caps, violations, and hard constraints. A merge layer combines the signals with explicit weighting and, crucially, flags contradictions.

That contradiction flag is not a minor feature. It is the system refusing to compress uncertainty into a single number.

When semantic fit is high but eligibility fails, the output should state the conflict plainly. When eligibility is fine but semantic fit is weak, the system should treat it as a prompt to request better context. Disagreement is information, and governed systems make it visible. This is also where the "constitution" idea becomes practical. In enterprise, objectives collide constantly: be helpful versus don't fabricate; move fast versus don't violate caps; reduce workload versus don't mislead. A runnable constitution is what prevents the system from choosing the convenient objective at the moment it matters.

Two Conversations About Agentic AI—And Why Both Matter

Agentic AI is currently split into two conversations, and understanding both is necessary to build systems that work in production. The first conversation is model-facing. Frontier labs are trying to define how models should behave: values, boundaries, refusal logic, and the internal reasoning that helps resolve conflicts between objectives. Anthropic's constitution work for Claude, most recently updated in January 2026, is the clearest public artifact of this direction. Rather than just giving models behavioral rules to follow, the constitution provides explicit principles and reasons for those principles. The goal is to help models generalize better when faced with novel situations and to resolve conflicts between competing objectives—like being helpful while staying truthful, or being comprehensive while respecting boundaries. This matters because it addresses a real problem: models trained purely on behavioral examples struggle when they encounter edge cases their training didn't anticipate. A constitution that explains why certain behaviors matter helps the model reason through those cases more reliably. The second conversation is product-facing. It starts where demos end: integrating AI into workflows that require justification, reproducibility, and operational safety. Here, the hard part is rarely "getting an agent to act." The hard part is making its actions reviewable and correctable inside real processes, without turning the organization into a liability machine. This is where neuro-symbolic architectures become practically relevant. Otera's ATA (Agentic Task Automation) framework, published in October 2025, demonstrates a clear split: in an offline phase, LLMs translate messy, informal language into structured, formal representations. For example, a request like "find digitalization funding for mid-sized Austrian manufacturers" gets translated into explicit criteria: company size ranges, industry codes, geographic constraints, funding types. Then, in an online phase, a deterministic engine executes decisions based on those structured representations. The system can verify compliance, replay decisions, and prove exactly what logic was applied. The power of this approach is that the translation step preserves the flexibility of language models, while the execution step provides the reproducibility and auditability that enterprise systems require. You get both competitive performance and perfect determinism. Both conversations matter. Model-level constitutions help ensure models have coherent internal reasoning. Architectural patterns like ATA help ensure that reasoning can be made verifiable and stable at runtime. But for enterprise systems, the reminder is blunt: a values document can improve behavior; it cannot enforce constraints.

Why Model Constitutions Matter—and Where They Stop

Anthropic's constitution work is meaningful progress because it gives models reasons to prioritize certain behaviors over others, which can reduce failure modes and improve consistency. When a model understands why it should avoid certain patterns, it can generalize those principles to new situations more effectively than if it had only memorized behavioral examples. But enterprise governance does not come from values alone. Values describe intent; controls shape outcomes.

Values are not controls.

Controls are the mechanisms that change system behavior when it would otherwise do the wrong thing. In practice, that means the system reacts differently when sources are missing, when rules fail, when required fields are absent, or when different parts of the pipeline disagree. It means the model can propose, but it cannot silently "decide" in places where a decision needs to be defensible. A model can be trained to be helpful. A system still needs to prevent helpfulness from turning into confident fabrication.

What Governed Systems Actually Look Like

In practice, governed systems converge on a familiar shape. They start with structure. You need a curated, versioned catalog that can be referenced, because source material changes over time and you need to know which version the system used. You need an intake model that captures key fields beyond a blob of prose, because otherwise the workflow will repeatedly hit the same gaps and the system will be forced to guess. They separate proposing from deciding. Retrieval and semantic scoring expand the search space and estimate thematic fit. Deterministic logic enforces constraints: eligibility, caps, exclusions, stacking interactions, and any other rules that must be stable across runs. They keep weights and conflicts visible. A merge layer that combines signals should not pretend that a single score is truth. If different parts of the system disagree, that disagreement should be a surfaced signal: either a reason to reject an option, or a reason to request more input. They record the path. A decision is only governable if it can be replayed. Session history—inputs, intermediate outputs, final results—lets teams debug, audit, and improve. Audit events capture the runtime context that explains why a particular run behaved the way it did. This is not just good practice; it is increasingly a regulatory requirement, with enterprise AI governance frameworks now mandating detailed audit trails covering data lineage, model lineage, and decision lineage. Even the interface becomes part of governance. A results view that shows progression through search, deterministic checks, semantic scoring, merge, and summary teaches users how to interpret the output and, just as importantly, where the output should not be over-trusted.

Three Layers of Trust

After building governed systems across different domains, a practical pattern emerged. I now use it as a mental checklist for any enterprise AI product: Layer 1: Retrieval Trust
Did we look in the right places? This is about search strategy, corpus coverage, freshness, and source authority. Weak retrieval poisons everything downstream. If your system retrieves the wrong documents or misses critical sources, no amount of model quality or governance controls can save you. The questions to ask: Are we searching the right corpus? Is our index current? Do we have access to authoritative sources? Are we handling updates and versioning correctly? Layer 2: Decision Trust
Did we apply constraints correctly? This is deterministic and testable. It is where you encode eligibility rules, caps, and high-stakes boundaries. It is also where you invest in tests and versioning, instead of treating your core logic as "prompt magic." The questions to ask: Are our rules encoded correctly? Can we test them independently? Do we version rule changes? Can we prove which rules applied to which decision? Layer 3: Explanation Trust
Are we honest about why and how sure we are? Models can help here—summarization, framing, next steps—but only if they are grounded in the first two layers. Otherwise explanations become plausible storytelling, which is the most dangerous output format in enterprise settings. The questions to ask: Do explanations cite actual sources? Do we expose uncertainty explicitly? Can users trace claims back to evidence? Do we distinguish between what we know and what we infer? Most "agent" systems collapse all three into one LLM call because it is convenient. That convenience is exactly what makes the system impossible to govern. The three-layer separation is not just about architecture; it is about creating clear accountability boundaries where each layer can be evaluated, tested, and improved independently.

When Governance Overhead Isn't Worth It

To be clear: not every AI system needs this level of governance. The overhead is real, and applying it universally would be wasteful. Building deterministic rule engines, maintaining versioned catalogs, implementing contradiction detection, and creating audit trails all take time and engineering resources. For low-stakes applications—a chatbot that answers FAQs, a draft generator where humans review everything, an exploratory research tool—this infrastructure would slow you down without commensurate benefit. The governing principle is simple: governance should scale with consequences. If the system's output is purely advisory and a human reviews it before any action, lightweight controls might suffice. If mistakes cost only time and convenience, optimize for speed and iteration instead. But when the boundary shifts—when outputs drive decisions about money, compliance, access, or risk—the calculus changes. At that point, the cost of governance is not overhead; it is insurance against much larger costs downstream: failed audits, regulatory penalties, reputational damage, or operational failures that cascade. The organizations that struggle are usually the ones that started in the low-stakes zone and crossed into high-stakes territory without realizing their architecture no longer matched their risk profile. By the time they notice, retrofitting governance is expensive and slow. The lesson: design for the stakes you will face at scale, not the stakes you face in the pilot.

Evaluation as Governance, Not Reporting

Many teams treat evaluation as analytics: measure quality, show charts, and move on. Governance requires evaluation to act as a control loop. A useful evaluation harness does not merely score outputs; it changes system posture. When evidence is missing, confidence should drop and the output should be marked as needing verification. When deterministic checks and semantic fit disagree, the system should treat that disagreement as a trigger for review or for a request for additional information. When required fields are missing, the workflow should not quietly patch gaps with guesswork; it should surface them as inputs the process truly needs.

If you cannot replay a decision, you cannot debug it. If you cannot debug it, you cannot improve it.

That is how systems stagnate—and why the same failure modes keep returning. Evaluation becomes governance when its results affect runtime behavior, not only dashboards.

The New Bar: Governable Autonomy

The goal is not removing autonomy. The goal is making autonomy conditional. Governable autonomy means tiered action levels, where low-risk automation can proceed while high-risk decisions require evidence and review. It means uncertainty is stated with structure rather than buried under confident language. It means explanations are grounded in sources and constraints, and it means replayability—because accountability requires that decisions can be reproduced later. Funding matching is only one setting where these principles become obvious. The same pattern appears across enterprise workflows: anywhere a system must justify decisions under constraints. Anthropic's constitution work pushes models toward better conflict resolution. ATA-like architectures push systems toward verifiable execution. Both are useful, but neither substitutes for a runnable governance layer.

The Practical Takeaway

A constitution matters when it runs.

In 2026, enterprises are done with AI theater. They are done with pilots that demonstrate capability but cannot scale. They are done with governance frameworks that read well in slide decks but do not execute under pressure.

The question is no longer "Can AI do this?" It is "Can we defend how AI did this?"

Systems that answer that question will scale. Systems that cannot will stall—not because the technology failed, but because the organization could not trust it enough to rely on it. A system earns trust by making constraints enforceable, evidence visible, uncertainty explicit, and decisions replayable. Those are not philosophical commitments. They are engineering requirements.