Intent-Driven AI Delegates

Accountability in Agentic AI Systems

In a billing system I worked on, a stakeholder reused a fee rate for a different purpose without documenting the change or informing anyone who relied on it. As a result, two teams ended up with two different meanings for the same attribute. The accounting team spotted the issue through their monthly reconciliation process and I traced the root cause by examining the configuration tables.

An AI agent operating without human oversight would automatically apply the business rule to the data and produce incorrect revenue figures. The result would be incorrect revenue assumptions and a delayed, costly manual reconciliation.

These AI-based systems are usually called autonomous agents, a label that implies the system originates its own intent and bears its own responsibility. Neither holds up under examination: intent requires an originator who can be held to it, and responsibility requires the capacity for commitment, which is a social act that systems cannot perform.

I think a better framing for this kind of system is AI Delegate.

Using "delegate" suggests that authority is delegated, while responsibility stays human. The purpose of this essay is to give architects, AI designers, and governance professionals a framework for designing AI-based systems that are transparent and auditable. It builds on the earlier essays On Meaning and Semantics in Enterprise Systems and Authority, Meaning, and the Limits of Automation.

Those essays made the earlier parts of the argument: organizational meaning is established in use and shared practice, and accountability for commitments cannot be delegated to the system itself. This essay starts from that point and asks what kind of architecture follows from it.

AI Delegates

Delegated intent. The system does not generate its own purposes; it receives intent from humans and acts within the scope of that intent. This sounds straightforward; however, most systems that claim to act on behalf of users are actually executing logic that encodes intent implicitly, buried in code where nobody can inspect or revise it without a development cycle.

Human-defined authority. The boundaries of what the system may do are set by humans, and they can always be narrowed or revoked. A system that can extend its own authority, or that cannot be constrained after deployment, is not a delegate.

Conceptual schemas. The discipline, borrowed from DietzJan Dietz is a Dutch computer scientist whose Enterprise Ontology theory models organizations in terms of essential commitments and transactions rather than implementation details. His DEMO methodology identifies what an organization essentially does, independent of how it is currently implemented.'s Enterprise Ontology and DEMO, Design and Engineering Methodology for OrganisationsA methodology developed by Jan Dietz for modeling an organization in terms of its essential transactions, actor roles, and commitments, independent of its current software, process, or reporting structure., is to model only what is essential to the organization's commitments; a schema defined that way stays stable and auditable as the domain evolves. Without that grounding, a system may produce correct-looking results while operating on a meaning that nobody ever agreed on. This kind of failure is difficult to detect and correct. For a fuller explanation of DEMO in this series, see Organizational Analysis Should Precede AI System Design.

When an AI Delegate's behavior is explicitly governed by modeled goals, situations, and constraints, I call it an Intent-Driven AI Delegate. This is a more specific term for systems where intent is not just implicit in code but explicitly represented, inspectable, and testable independently of implementation.

AI Delegate Capabilities

Rejecting autonomy does not mean reducing the system to a simple rule executor.

AI Delegates can still:

• Interpret ambiguous input and propose structured responses
• Query conceptual schemas and detect inconsistencies
• Execute complex workflows within defined boundaries
• Incorporate feedback and adjust behavior over time, within predefined constraints
• Coordinate with other systems and other delegates

The difference is that these capabilities operate within boundaries that humans define and remain responsible for.

The Three-Layer Architecture

To make AI Delegates work in practice, we need an architecture that separates concerns cleanly. I think three layers are enough, and each has a distinct responsibility.

Hybrid Agents

AI agents are increasingly hybrid systems combining neural and symbolic reasoning. A common current example is an LLM making tool calls via MCP serversServers that expose tools or data to an AI system through the Model Context Protocol, so the system can call external capabilities in a structured way., though this pattern does not always include explicit symbolic governance. The governed delegate pattern requires a more deliberate division: neural reasoning, typically an LLM, handles natural language interpretation, ambiguity, and candidate intent mapping, and the symbolic reasoning handles governance: validating against the conceptual schema, checking who is authorized to invoke an action, and enforcing constraints deterministically.

Both neural and symbolic reasoning are required for a properly governed delegate. The neural component handles what is ambiguous and the symbolic component handles what must be deterministic.

The Flow

1. Conceptual Schema provides the vocabulary and constraints
2. Intent specifies what should happen and why
3. Agent determines how to fulfill the intent
4. Feedback from outcomes may lead to schema or intent evolution, but only through human governance

This separation makes failures easier to diagnose and fix. When something goes wrong, you can determine whether the issue is semantic, intentional, or operational, and whether the fix belongs in the schema, the intent, or the agent. Each correction targets a specific layer without cascading changes across the system.

This three-layer architecture has been implemented in a simple working demo. I used Object-Role ModelingA conceptual modeling language that represents a domain as object types connected by fact types and roles, with explicit constraints. Used here to define the conceptual schema layer independently of any database or implementation technology. for the conceptual schema and added an explicit intent registry. The delegate accepts natural language requests, interprets the request, performs symbolic validation, and generates an audit trail.

Intent as a First-Class Concept

Most systems treat intent implicitly. Business logic encodes intent in code, but the intent itself is not visible or inspectable. When requirements change, you rewrite code rather than updating a versioned, modeled intent. The Intent-Driven approach models intent directly, rather than leaving it buried in code.

The Intent Meta-Model

At a conceptual level, an intent model may include:

Example: Age Eligibility

Consider a simple case: determining whether someone is old enough to access a service.

Conceptual Schema (excerpt):

Intent Specification:

What is not present yet is a rule such as "≥ 18," an algorithm, or a calendar assumption. Those are operational details that come later and can be changed, tested, and redeployed without changing the intent.

Separation of Intent from Schema

If the legal age threshold changes or jurisdiction varies, the intent remains valid; only the operationalization changes. That separation is what keeps change manageable: when a rule changes, you update the rule, not the purpose it serves.

It also enables multiple intents to share the same schema. "CalculateBenefitsEligibility" and "DetectEmploymentFraud" might both reference Employment and StartDate, but for different purposes. The semantics stay stable while the practical scenario changes, which is cleaner than duplicating definitions or embedding purpose directly into the schema.

Language Models as Intent Interpreters

Language models fit into this architecture as interpreters, not authorities.

What Language Models Do Well

Language models are good at interpreting ambiguous natural language, determining intent, and mapping it to known conceptual elements.

What Language Models Cannot Do

What language models cannot do is govern or enforce constraints. They do not verify that a requester has authority to invoke an action and they cannot reliably detect when they are outside their competence. A language model can propose that a request maps to a particular intent but it cannot confirm that the schema supports that intent, that the data exists, or that the requester has the right to ask.

In an Intent-Driven architecture, language models may propose intent mappings but may not make schema changes and must surface ambiguity rather than default to their best interpretation. Their outputs still pass through symbolic validation before anything consequential happens.

This matters because ambiguity detection, authority checking, and constraint enforcement are not probabilistic operations. A language model may help interpret a request; however, without symbolic grounding it will not reliably refuse actions that exceed delegated authority.

Human Accountability

One principle runs through everything here: responsibility and accountability must stay human.

On the semiotic ladderA framework developed by Ronald Stamper and adopted by Jan Dietz that describes how meaning builds in layers, from physical signals at the bottom through syntax, semantics, and pragmatics, up to social commitments at the top., this principle belongs to the social level: norms, roles, and shared commitments. The three-layer architecture addresses the semantic and pragmatic levels. Human accountability addresses the point at which meaning is embedded in an organization with clear lines of responsibility.

This is the same boundary argued in Authority, Meaning, and the Limits of Automation. The point here is not to restate that argument in full, but to show how a system can be designed so that execution is delegated while accountability remains attached to the human role on whose behalf the system acts.

Authority May Be Delegated

An AI Delegate may have authority to query customer records within a defined situation but it does not have authority to redefine what "customer" means or grant itself access beyond that situation. Authority in this framework is always derived from human decision, conditional on the situation, and revocable; it is never possessed by the system itself.

Responsibility Stays Human

AI can execute decisions but cannot accept blame or be held to account. Responsibility requires commitment, which is a social act that only people can take on.

Dietz's distinction between forma, informa, and performaDietz's three categories of human activity: forma covers documental acts such as storing and transmitting; informa covers informational acts such as computing and reasoning; performa covers ontological acts such as making commitments and decisions. Only performa involves genuine social responsibility. clarifies why. Forma and informa cover implementation and information handling; performa covers commitments and social acts. AI Delegates operate at the forma and informa levels, which is why responsibility cannot be delegated along with the task.

To further clarify, these constraints are explicit system constraints. An AI Agent could potentially manufacture its own functional intent and take action without being granted the explicit authority by a human.

The Human Accountability Test

This test does not prevent AI from acting but it ensures that when AI acts, someone is answerable.

Conclusion: From Autonomy to Delegation

The difference between "autonomous agent" and "AI delegate" is not just a matter of terminology; it helps us to think about how AI agents fit within a larger system where reliability and transparency are required.

"Autonomous agent" points toward a system that originates its own intent and bears its own responsibility. Neither of those holds up in practice, and when something goes wrong the accountability gap is the first thing an auditor will find.

Regulators, customers, and governance teams will look for traceability, responsibility, and auditability, and a delegate architecture is one way to make those requirements explicit.

The architecture described here has been implemented in a working prototype. The financial product eligibility demo shows the pattern in practice: an LLM interprets a natural language request, a jurisdiction-aware conceptual schema routes the decision, and a delegate produces an audit trail for the outcome. The indeterminate case, where required fields are missing and the system surfaces the gap rather than guessing, makes the governance layer easiest to see.

Returning to my original example, if a rule had been specified that two revenue calculations must match under some specific condition, then it would be caught by an AI Delegate. AI could also be used for anomaly detection and alerting those who are responsible. The billing example was caught by a human doing a monthly reconciliation. The point of an Intent-Driven AI Delegate is to make those constraints explicit, testable, and auditable before the mismatch turns into an operational problem.

G. Sawatzky writes about semantic grounding, AI governance, and accountable automation in enterprise systems. For the earlier essays in this series, see On Meaning and Semantics in Enterprise Systems and Authority, Meaning, and the Limits of Automation.

Terms marked with a dotted underline include hover definitions for readers unfamiliar with the companion article.