Agentic Systems: Ownership Boundaries

Many business processes are repetitive enough to automate and variable enough to resist conventional workflow software. A dental office may receive the same intake details through a form, an email, a phone transcript, or a scanned document, each with different names and missing fields. LLMs can absorb that variation while business-owned workflows preserve the rules and records that keep the process reliable.

Traditional automation works best when inputs follow predictable formats and decisions can be encoded as explicit rules. A small business then faces an awkward choice: standardize its work around the software, pay for custom automation, or rely on employees to interpret inputs and handle exceptions by hand.

Much of this exception handling is repetitive white-collar work: reading documents, extracting facts, routing requests, reconciling records, and following up on missing details.

LLMs make more of this variable work accessible to automation. They can interpret unstructured input and return structured output . An agent can also choose tools or substeps at runtime when the right path depends on what it discovers.

Updating a calendar, issuing a payment, deciding a claim, or changing a customer record still requires strict controls. The useful shift is to concentrate structure at the boundaries that protect the business while allowing flexible input and model-directed work inside them.

Autonomy Spectrum asked how much authority to give the model. Abstraction Layers asked which parts of the surrounding system to build and which to reuse. This post asks where model-directed work should end and business control should begin.

Move structure to the boundaries

LLMs and agents relax two different constraints.

An LLM can absorb variation in the input. It can read a free-form email, identify the patient and requested appointment, recognize missing information, and produce predictable fields for the application.

An agent can absorb variations in the steps needed to complete the task. Within a bounded step, it can inspect the intake record, ask for missing information, query availability through an allowed list of tools , and produce a recommendation. Multiple runs toward the same goal may take different paths.

A fixed workflow that calls a model for extraction or classification remains LLM-assisted automation. The step becomes agentic when the model chooses its next action within the supplied goal, tools, and limits.

Business effects still require an exact contract. The application validates the recommendation against current state and policy, requests approval when required, and sends a structured command to the calendar or system of record.

An invariant is a condition that must remain true, such as never double-booking an appointment, never charging a card twice, or always requiring approval above a refund limit.

This gives us our third principle:

Principle #3: Business-owned orchestration

Let the model handle variation. Keep business invariants in deterministic code.

The business process owns the agent call. It defines the agent’s scope, validates the result, and decides which business effect happens next.

The business can preserve more of the way customers and employees already communicate. It still formalizes the points where a mistake would change business state or create an external commitment.

Four ownership boundaries

The previous post described infrastructure layers along a request path: channel, agent runtime, model SDK, gateway, and model provider. This post maps responsibility instead. A request may cross the following boundaries in that order, while the boundaries answer separate ownership questions.

The diagram uses containment to show control. Model inference runs inside an agent step. The agent step runs inside a durable process. The process operates on behalf of the domain application that owns the business outcome.

An agentic business system commonly has four boundaries:

These boundaries do not require four products or services. A small application may contain all four in one deployment. A larger system may separate them. Some platforms combine process orchestration and the agent harness, and a framework may span several boundaries.

1. Domain application

The domain application owns business meaning.

For a dental office, this includes patients, appointments, intake records, reminder policy, calendar writes, messages, and the office-facing dashboard. For a customer-support product, it might include customers, tickets, service-level policies, escalations, and support-agent approvals.

It remains the source of truth for business state. An agent transcript provides useful execution context. The patient record, insurance claim, or customer account remains the authoritative record.

Channels enter at this boundary. An email, Slack message, webhook , or UI action begins as an external signal. The domain application verifies identity, checks permissions, prevents duplicate admission, and associates the signal with a business entity.

An LLM may help translate that signal into a proposed command such as triage_intake or review_claim. The domain application validates the command and its arguments before admitting it. This keeps flexible input outside the source of truth until the application accepts it.

The domain UI should also lead with business concepts. An operator wants to see appointments that need attention or claims waiting for review. Raw tool calls and model messages can remain available for diagnosis without becoming the primary product interface.

2. Process orchestration

Process orchestration makes the business commitment durable.

It knows the sequence of work, which steps completed, which steps can be retried, and which external effects already happened. It can accept work from an event, run scheduled jobs, recover after a crash, and expose progress to an operations dashboard.

An orchestration engine built on Flue is an example: a durable queue, persistent schedules, memoized steps, retry policies, cancellation, recovery, logs, events, and host-facing APIs, independent of dental, support, or insurance terminology.

The workflow definition can still contain domain logic. The reusable engine executes that definition without owning its meaning.

For example, a new-patient intake process might be:

1. Load the verified intake signal and patient record.
2. Ask an agent to extract the request, gather allowed context, and recommend a triage result.
3. Validate the structured recommendation against current availability and office policy.
4. Route uncertain or policy-sensitive cases to staff for approval.
5. Create the appointment with an idempotency key.
6. Write the calendar event and send the confirmation message.

The agent handles one variable, judgment-heavy step. Deterministic workflow code owns the state transitions, approval rule, and business effects.

This distinction becomes important when something fails. If the process crashes after creating the appointment, it resumes without running completed steps again. Domain-owned idempotency keys protect effects such as sending a message or charging a card from accidental repetition.

3. Agent harness

The agent harness runs the model-directed loop. Here, harness means the model-directed part of the broader agent runtime introduced in the previous post.

Flue is an example here too. It manages the agent’s instructions, tools, context, sessions, and interactions with the model. Within a triage step, the model may inspect supplied intake information, use allowed tools, and produce a structured recommendation.

The harness controls the agent’s local operating environment: which context it receives, which tools it can request, how many turns it may take, and when it must stop or escalate. Domain-owned code validates every tool request that reads sensitive data or changes business state.

The harness can preserve an interrupted agent session. Process orchestration preserves the larger business process around that session.

These are different guarantees:

• Agent-session durability remembers the conversation and tool activity.
• Process durability remembers the business commitment, completed effects, and next required action.

A process may call no agents, one agent, or several specialized agents. The harness remains a capability used by the process. It does not become the source of business truth or the owner of the wider commitment.

4. Model inference

Model inference contains the model SDK, AI gateway, and provider described in the previous post.

The agent harness uses this boundary to send messages, stream output, call models, and collect usage. Gateway policy may select providers or apply fallbacks. The domain application and process orchestration depend on their own contracts instead of provider-specific response formats.

This is usually the most generic part of the system. It knows how to run inference for a model request. Business concepts such as appointments, claims, and escalations stay outside this boundary.

Choose where to spend flexibility

Agents add the most value where variation makes a decision tree expensive to maintain. Keep a step deterministic when the inputs and desired action are already known.

Before delegating a step, define six things:

1. Goal: What outcome should the step produce?
2. Context: Which business records may the agent inspect?
3. Capabilities: Which tools may it request, with which permissions?
4. Limits: How much time, cost, and how many turns may it use?
5. Exit contract: Which structured result, uncertainty signal, or escalation must it return?
6. Effect policy: Which results can proceed automatically, and which require validation or human approval?

This checklist turns agent flexibility into a scoped engineering decision. It also exposes processes that need better domain rules before automation can safely proceed.

State across the boundaries

A production system may have several related forms of state:

• Domain state: patients, appointments, claims, tickets, and effects.
• Process state: workflow runs, steps, schedules, retries, and recovery checkpoints.
• Agent state: messages, context, tool calls, and model outputs.

Keeping them separate makes ownership clearer. It also creates a need for correlation IDs, idempotency keys, and reconciliation between stores.

A workflow run ID can connect a business record to its process execution. An agent run ID can connect a judgment-heavy step to the model interaction that produced it. Neither ID should replace the business entity’s identity.

Monitoring also has two audiences. Technical observability shows queues, retries, tool failures, and model calls. Business monitoring shows unresolved intake, overdue claims, failed reminders, and cases waiting for approval. Both can use the same underlying events while presenting different meanings.

Putting the boundaries together

Consider the complete dental-intake flow:

1. The domain application verifies and records an intake webhook.
2. Process orchestration durably accepts the intake process.
3. The process calls the agent harness with a bounded triage goal, allowed context, and read-only tools.
4. The harness calls model inference and returns a structured recommendation with an uncertainty signal.
5. The domain application validates the recommendation against current state and policy.
6. The process requests staff approval when the case crosses a configured threshold.
7. Deterministic steps create the appointment, update the calendar, and send a message with idempotency protection.
8. The domain dashboard shows the patient, process status, approval history, and appointment outcome.

Each boundary has a clear responsibility. The model absorbs variability and supplies judgment. The business application retains policy and truth. The workflow host keeps the commitment alive through failures.

Conclusion

Autonomy decided what the model could do. Abstraction decided how much machinery the application had to own. Ownership boundaries decide where flexible model-directed work ends and business control begins.

Move structure to the boundaries: own the business truth, make the process durable, give the agent bounded decisions, and rent the inference machinery.

That still leaves one question open: once a system like this is running, how does it get better and cheaper over time? That’s next.

This is the third of four posts on building agentic systems. Read the others: Autonomy Spectrum, Abstraction Layers, and Learning Loop.