The boundary is the decision

Architecture diagrams often place “legacy” at one side and “agent platform” at the other, then draw a line labelled API, event bus or RPA. The line looks like plumbing. For conventional data transfer that simplification may be tolerable. For an agent that forms plans and initiates effects, the line is where four questions become concrete.

Observation asks what the agent can know. Does the interface expose current state, historical state, change time, source identity, version and replication lag? A value without an “as of” time may be true yet unusable. A database row may show that a code changed without revealing the business event that justified it. A screen may omit fields that exist in the underlying record.

Control asks what the agent can cause. Is the operation a query, a proposal, a command or an unconstrained sequence of clicks? Can the boundary enforce identity, permissions, allowed values, preconditions, limits and separation of duties? An HTTP endpoint is not automatically a strong control surface. A poorly designed endpoint can accept arbitrary patches, while a human queue can impose careful authority and review.

Verification asks how the outcome becomes knowable. A response can confirm receipt, validation, commitment or final business effect. These are different claims. An action that returns 200 may still launch asynchronous work. A message acknowledged by a broker may still fail in the consumer. A desktop screen may acknowledge input before a later batch reverses it.

Recovery asks what happens after partial failure. Can the caller safely retry with the same intent? Is there an operation identifier? Can the workflow query status, compensate a completed step, quarantine an uncertain case or hand it to a named reviewer with the evidence needed to decide?¹³

The OpenAPI Specification provides a language-agnostic description for HTTP APIs, while HTTP itself defines method semantics including safe and idempotent operations.¹² Those standards help describe a boundary. They do not guarantee that its domain semantics, authorisation or postconditions are adequate. The architecture must add those claims explicitly.

This expression is a design test, not a numerical law. “Observable state” grows when provenance, freshness and version are exposed. “Constrained effect” grows when the operation is typed and mechanically authorised. “Correlatable receipt” grows when request, acceptance, commitment and outcome share an identifier. “Recoverable uncertainty” grows when retries, readback, compensation and escalation are designed before failure.

Transport, authority and outcome are different layers

A frequent design error is to let the transport name answer questions that belong to another layer. “It is an API” describes an interface style. It does not tell us whether the caller may perform the operation. “It came from the event bus” describes delivery. It does not tell us whether the message is true, current or authorised to trigger a consequential effect. “The trace completed” shows correlated execution. It does not prove that the customer’s world changed as intended.

Separate four records for every consequential operation. The intent record says who asked for what, for which subject, under which purpose and constraints. The evidence record says what source facts were available, their effective times and their limitations. The action record says which boundary received the command, the operation identifier, policy result and immediate response. The outcome record says which independent observation established the postcondition, or why the result remains unknown.

These records may live in one event-sourced workflow, but their claims should not collapse. A trace identifier can connect them across components. The W3C Trace Context standard defines how request context can propagate through distributed services.¹⁴ Correlation is valuable because it lets an operator reconstruct a path. Yet a perfectly correlated trace can end in the wrong account state. Operating evidence requires both the path and the result.

The same separation prevents a connector from becoming an accidental authority system. A tool catalogue can expose an operation to the model. A service account can authenticate the runtime. Neither fact establishes that this user, for this purpose, may perform this effect now. The command boundary should receive a decision receipt from an authority check, or perform the check itself against a dependable entitlement source. Connectivity expands reach; authorisation narrows permitted effect.

Use counterfactuals before scoring patterns

Before comparing products, run two small counterfactuals. The observation counterfactual asks: if the same business fact arrived through another surface, would the agent’s justified belief change? Replace a screen value with a versioned API response. Replace a current query with a replica that is ten minutes behind. Replace a database row with a domain event carrying the reason for change. If the answer changes, the missing provenance or time is part of the integration requirement.

The effect counterfactual asks: if the same command returned no response, what could the workflow prove? A strong boundary may expose status by operation identifier, permit a safe retry or support independent readback. A weak boundary may leave only screenshots and logs from the caller itself. If the architecture cannot distinguish “not attempted”, “accepted”, “committed” and “effective”, its happy-path latency is secondary.

These tests reveal why pattern fitness is governed by its weakest essential property. Excellent observation cannot compensate for uncontrolled writes. Strict command validation cannot compensate for an unobservable final effect when the action is irreversible. Fast recovery cannot make an unauthorised command legitimate. For a given operation, think of sufficiency as a gate: every required claim must cross its threshold.

This also changes how teams document legacy constraints. “No API” is an implementation fact. The architectural requirement might be narrower: “No machine-verifiable command for field X”, “No effective-time readback until the nightly cycle”, or “The available event records a row change but not the business reason”. Precise gaps invite precise bridges. Vague legacy labels invite oversized integration programmes.

A final test is to name the claim that would appear in a customer notice, audit record or incident review. “The agent clicked Save” is a trajectory claim. “The source accepted the request” is a boundary claim. “The preference became effective before the next statement cycle” is a business-outcome claim. Work backwards from the strongest claim the process must support. The selected integration path should generate that evidence without asking the model to infer hidden source behaviour. This backwards design often removes impressive but irrelevant capabilities and exposes one missing query, receipt or escalation state that actually determines safety.

One fact, three observation surfaces

Consider a single question: “What is the customer’s available credit?” Hold the underlying account constant and vary only the integration surface.

The API returns GBP 10,000, a customer identifier, a limit version, an effective timestamp and the rule that calculated the available amount. A read replica returns the same value and source key, plus a replication position showing that it trails the system of record by 42 seconds. The desktop screen displays “10,000” beside a green bar. It does not reveal the currency, the calculation time, the version or whether pending authorisations have been included.

All three surfaces can yield the same visible number. Only two expose enough evidence to tell us what the number means. The API is suitable for a current point query if its latency and availability are adequate. The replica may be better for high-volume analysis where a known lag is acceptable. The screen is useful to a human who understands its surrounding workflow, but a vision system sees a compressed presentation whose omitted context may be decisive.

Observability is not the amount of data returned; it is the ability to interpret a claim within its source, time, version and business semantics. This is why a screenshot can be information-rich yet evidence-poor, and why a database replica can be technically exact yet semantically incomplete.

flowchart LR
  A["The green tick that proved nothing"] --> B["The boundary is the decision"]
  B --> C["One fact, three observation<br/>surfaces"]
  C --> D["Six patterns, six different<br/>promises"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#7B4CD8,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Six patterns, six different promises

The six patterns are frequently treated as alternative pipes. Their more useful interpretation is as six different contracts with the source estate.

1. API: a query or command contract

An API is strongest when it names a domain operation, validates its input, checks the caller’s authority, records a caller-supplied operation identifier and exposes status or readback. It can provide both observation and action without exposing the source’s internal schema. OpenAPI can make the HTTP surface machine-readable, but the decisive quality lies in operation semantics rather than documentation format.¹

A generic endpoint such as PATCH /customer may be easy to call and hard to govern. A narrower command such as requestStatementDeliveryChange can require a reason, permitted target state, expected record version and operation identifier. The best agent API is often smaller than the API a human application would request.

2. Event: an occurrence contract

An event says that something happened or that a source observed a change. CloudEvents standardises a common event envelope, while AsyncAPI describes message-driven APIs across protocols.³⁴ Neither specification turns an observation into authority. “CustomerAddressChanged” can wake a workflow, invalidate cached context or trigger a review. It does not authorise another system to change its own address record.

Events are valuable when many consumers need the same occurrence, when temporal order matters, or when a long-running workflow should react without polling. They require explicit handling for duplicates, reordering, schema evolution, retention and replay. A broker acknowledgement proves message handling at one boundary, not final business effect.

3. Replica or CDC: an observation plane

Logical replication and change data capture externalise source changes for downstream consumers. PostgreSQL logical replication, for example, begins with a snapshot and then continually applies subsequent changes; CDC systems commonly read database transaction logs.⁵⁶ This pattern can protect a fragile source from analytical query load, preserve change history and support high-volume retrieval.

Its limits are equally important. Replication lag makes the view temporally qualified. A table update is not automatically a domain event. Deleted or overwritten meaning may be absent. Most importantly, a replica is an evidence surface, not a back door for writes. Writing to the copy either has no source effect or creates an unsafe second authority.

4. Sidecar or adapter: a translation boundary

A sidecar describes where supporting software runs, commonly beside an application process. An anti-corruption layer describes what semantic responsibility a boundary performs: translating between systems that do not share the same concepts.⁷⁸ The two can coincide, but they are not synonyms.

A local sidecar may terminate an old protocol, add tracing or synchronise data without changing the source application. A central adapter may map a modern “payment status” into several legacy flags and reason codes. The risk is semantic laundering: translation can make a weak source look clean while silently discarding exceptions. Every mapping therefore needs explicit loss, default and conflict rules.

5. RPA or GUI surface: an interface bridge

RPA operates the presentation surface intended for a person. It is useful when no machine interface exists, source modification is infeasible and the task is stable enough to automate. It can buy time during migration. It can also expose a broad ambient authority: whatever the service account can click, the automation may be able to click.

Recent GUI-agent benchmarks continue to report robustness gaps under non-default initial states and to compare API, GUI and hybrid agents using programmatic final-state verification.⁹¹⁰ The engineering conclusion is bounded rather than dismissive. Use stable selectors where available, constrain allowed screens and fields, capture before-and-after evidence, and verify the effect outside the same visual channel whenever consequence matters.

6. Human queue: an accountable decision boundary

A human queue is not the absence of integration. It is a deliberate contract that packages intent, evidence, unresolved questions and proposed action for a person with defined authority. NIST’s AI risk guidance stresses that human roles and responsibilities should be differentiated, including cases where a system defers a decision to an expert.¹¹

A good queue has a typed case schema, owner, service expectation, permissible dispositions, evidence links and a decision receipt. A poor queue is an email inbox with screenshots and no status model. Human review adds value only when the architecture makes the unresolved judgement visible and gives the reviewer the power and evidence to resolve it.

Writes reveal the real architecture

Read integration can often tolerate a qualified answer: “This replica was current 42 seconds ago.” Write integration must answer a harder question: “Did this specific authorised intent produce the intended state exactly once?”

Suppose an agent sends a command to close an account. The source commits the change, but the response is lost. The caller sees a timeout. At that moment the outcome is neither success nor failure. It is unknown. A blind retry may attempt a second closure, duplicate a fee, repeat a notification or collide with a changed state. Treating every timeout as failure manufactures side effects.

HTTP defines idempotency at the method level, and robust service contracts often add a caller-supplied request identifier so repeated requests can be recognised as the same intent.²¹² Idempotency is necessary for many retries, but it is not the complete answer. The workflow also needs a way to query the operation or the resulting business state. Otherwise it knows that duplicates were suppressed without knowing whether the first attempt completed.

A defensible write path therefore separates four receipts:

1. Request receipt: the boundary received the caller’s operation identifier and payload.
2. Acceptance receipt: syntax, identity, authority and preconditions passed.
3. Commit receipt: the source recorded the state transition or durable work item.
4. Effect receipt: an independent observation confirms the intended business postcondition.

One response may carry several receipts, but the claims should remain distinguishable. A queue acknowledgement is commonly a request receipt. A green tick may be an acceptance receipt. A database commit may still precede downstream effect. The agent should never strengthen the claim beyond the evidence returned.

Thought experiment: the identical timeout

Run the same close-account operation through two boundaries. In both cases the request times out after five seconds. Boundary A requires an operation identifier and exposes GET /operations/{id}. Boundary B is a GUI click followed by a spinner. Hold the model, customer, network failure and source application constant.

Through Boundary A, the workflow queries the operation. It learns that the command committed and that final closure is awaiting an overnight control. It pauses without retrying. Through Boundary B, the workflow cannot tell whether the click failed before submission, committed successfully or committed and then encountered a rendering failure. Its safest action is to stop, preserve the evidence and escalate.

The difference is not API speed. It is outcome observability after communication uncertainty. This single property often separates an automatable write from a proposal-only workflow.

Compose a path instead of choosing a winner

A procurement question asks which integration technology to standardise. An operation-level question asks which combination preserves the evidence, authority and recovery needed for this effect. The second question produces better architecture.

Minimal worked example: update a contact preference

A legacy customer system exposes a documented command API for changing marketing contact preference. The command accepts an operation identifier, the expected current record version and one of three allowed values. A separate query returns the effective preference and version.

The correct design is intentionally plain. The agent drafts the change and its reason. A deterministic policy checks customer identity, consent evidence and caller authority. The API performs the change. The workflow reads the preference back and stores the effect receipt. There is no event bus, replica, sidecar, screen automation or human review unless another requirement justifies it.

This example matters because architecture discussions often reward visible complexity. Here, adding more patterns increases failure modes without strengthening the claim. The simple API is the serious baseline against which every extra component must earn its cost.

Production-shaped worked scenario: a payment exception

A fictional bank has a payment exception process spread across a transaction monitor, a mainframe payments system, a sanctions service and a case-management desktop. The goal is to prepare and, where permitted, release low-risk false positives while preserving human authority for ambiguous or irreversible decisions.

An event from the transaction monitor wakes the workflow and identifies the payment, rule and detection time. It does not authorise release. A governed replica supplies payment history and account state with source identifiers and a visible lag. An API queries current sanctions results. A semantic adapter converts mainframe reason codes into the workflow’s typed evidence model, preserving the original codes and marking mappings that lose meaning.

The agent assembles competing explanations and proposes a disposition. A deterministic authority kernel compares the proposal with policy, user mandate, value threshold and evidence completeness. For a narrow class of low-value false positives, a typed release command is available. It accepts an operation identifier and expected payment version. The workflow then queries the payment state and stores an effect receipt.

One remaining mainframe field is accessible only through a desktop screen. The RPA step is limited to reading that field and capturing its screen context; it cannot press Release. If the field conflicts with the replica, if the API times out without recoverable status, or if the payment crosses the threshold, the case enters a human queue. The reviewer receives the original event, source facts, mapping warnings, model proposal, policy result and unresolved question. The queue returns a typed disposition rather than free text alone.

No single integration pattern owns the workflow. The composition follows the certainty gradient of each subtask. Events supply temporal triggers, replicas supply scalable evidence, adapters preserve semantics, APIs carry bounded effects, RPA fills a narrow observational gap and humans retain authority where machine-verifiable closure is absent.

The integration selector

The selector below turns the argument into an executable decision aid. It does not choose a product. It ranks pattern roles for one operation using the facts architects often leave implicit: read versus write, available surfaces, freshness, semantic mismatch, consequence, reversibility, human judgement and postcondition visibility.

Its scoring is deliberately inspectable. Some rules are hard constraints. Events and replicas cannot be the primary write path. A high-consequence, irreversible GUI write without independent postcondition evidence is stopped rather than given a low confidence score. Other rules are preferences. High-volume historical reads favour a replica; semantic mismatch favours an adapter; a well-owned idempotent command with readback favours an API.

stateDiagram-v2
  [*] --> Claim
  state "Transport, authority and<br/>outcome are different layers" as Claim
  state "Use counterfactuals before<br/>scoring patterns" as Test
  state "Figure 1. The integration<br/>atlas by control and<br/>observability" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Failure boundary and negative control

No selector can manufacture semantics that the source does not expose. If a field has several undocumented meanings, an adapter can preserve the ambiguity but cannot truthfully resolve it. If a desktop action has an irreversible effect and no independent readback, better screen recognition cannot prove the outcome. If identity is shared, a connector cannot reconstruct who held authority. If a replica omits deletions or arrives without a reliable position, it cannot support historical claims that depend on those facts.

There is also a serious negative control against the article’s preferred sophistication. Imagine a well-owned legacy service with a documented, low-latency API. The operation is deterministic and reversible. It accepts an operation identifier, enforces expected version, returns stable error semantics and exposes the resulting state. Traffic is modest, no historical replay is needed and the concepts align with the calling domain.

In that case, a direct API integration is sufficient. Adding an event bus, CDC platform, sidecar, screen automation or mandatory human review would add operational surface without improving the decision. The preferred architecture must be allowed to collapse to one good boundary. Otherwise the atlas becomes a justification machine for complexity.

The negative control also clarifies the original contribution. The claim is not that legacy systems require a six-pattern fabric. The claim is that pattern choice should be earned by operation-specific gaps in observation, control, verification or recovery. When those gaps are absent, the extra pattern should disappear.

Design the exit while building the bridge

Tactical integration becomes permanent when nobody records what would make it unnecessary. Every bridge should therefore carry an exit trigger. Retire an RPA write when a typed command and postcondition become available. Retire a polling replica when a source event and current query meet the freshness need. Remove an adapter mapping when the domains converge, but retain the old mapping for replay of historical evidence. Reduce human review only after failure injection shows that the machine path detects the cases reviewers were resolving.

Migration should move one operation at a time. A useful sequence is: observe the old path, create an independent read model, place a semantic boundary, introduce a shadow command, verify both outcomes, shift a bounded cohort, retain rollback, then withdraw old authority. The goal is not a dramatic cutover. It is a growing set of operations whose evidence-and-effect contracts are stronger than the interfaces they replace.

Compact glossary

Observation contract

The source, time, version, meaning and limitations attached to a fact supplied to the agent.

Command contract

The typed intent, identity, authority, preconditions, permitted effects and error semantics of a state change.

Effect receipt

Evidence from readback or another authoritative observation that the intended business postcondition now holds.

Unknown outcome

A state in which the caller lacks evidence to classify an attempted action as completed or not completed.

Semantic adapter

A boundary that translates concepts and exposes defaults, loss and conflicts instead of copying fields blindly.

Human queue

A governed workflow state that assigns unresolved judgement to a named role and returns a typed disposition.