A delegation contract across the lifecycle boundary

Take the same mid-sized dealer from the teardown and rebuild the deployment rather than cancel it, because cancelling it is not on the table. The break queue is still ageing, the governance forum is still asking about the tail, and the business case for an agent that works the queue is still good. What changes is what the agent is permitted to be.

The ops-side agent keeps everything that made it useful. It reads the reconciliation platform, the trade record, the custodian file, the confirmation store, the static data. Reading is not the problem and never was: nothing about provenance is damaged by a process that can see two records. It keeps three write verbs — resolve a break, annotate a break, escalate a break — and those three verbs are its entire write set, permanently, with no escalation path that adds a fourth.

When it finds a break that traces to a booking error, which the teardown's analysis says is most of them, it does not fix the booking. It emits an object: a request that names the trade, states the defect it believes exists, points at the evidence it believes establishes that, names itself as the asserter, expires in a defined window and is good for exactly one use. The request lands with the capture-side principal, which holds the amend verb and has held it all along. That principal reads the request, looks at the capture-side evidence — the ticket, the desk's stated intent, the order record — and decides. It may amend. It may reject the request with a reason. It may do neither and let the request expire, which is itself a recorded outcome rather than a silence.

The break still clears in hours rather than days, because the slow part was never the typing. The slow part was a human working out which of two records was wrong, and the agent has done that work and shown it. What has not happened is the thing the teardown is about: at no point did one process hold the ability to write the record and to certify the comparison. The request crossed the boundary. The authority did not.

The dealer, the queue, the agents and every workflow detail above are a constructed illustration, assembled from ordinary post-trade architecture and public rule text. They describe no institution, no incident, no product and no engagement, and nothing in this piece is drawn from client work. Where a figure or a code listing appears below, it is written to be read and reasoned about rather than deployed.

What this design is answering

The companion teardown, The middle office exists to be the separation, argues that the lifecycle's segregation is not a predicate over permission holders but a property of where records come from, and that this is why fixing the permission review does not restore it. I am going to take that as established rather than restate it. The consequence I need from it is narrow and it constrains everything below: any design whose enforcement point is a review — a toxic-pair matrix, a connector register, a deployment approval — inherits the failure, because the firm in the teardown saw the composition, discussed it, and approved it with full information and a good business case. A control that is defeated by a reasonable person exercising judgement is not a control. It is a preference with a meeting attached.

So the enforcement point has to be earlier than judgement, and the evidence has to be later than the run. Earlier than judgement means the partition lives where capability is assembled, so that a spanning grant is not something a reviewer declines but something the broker cannot mint. Later than the run means the evidence is attached to the record rather than to a trace, because the record is what survives to an examination and the trace is what gets sampled away at retention time.

First move: partition write verbs, not agents and not tools

Almost every agent governance register I have read enumerates tools. A tool is a marketing artefact — a connector, an integration, a named product surface — and it is the wrong unit for this problem in two directions at once. One tool routinely carries verbs from two lifecycle stages, so partitioning tools under-constrains. And two tools routinely carry the same verb by different routes, so partitioning tools also over-constrains, forbidding a harmless duplication while permitting the harmful span.

The unit that works is the write verb, defined as an operation that causes a durable change to a record the firm relies on. Book a trade. Amend a trade. Allocate. Cancel-correct. Affirm. Raise a discrepancy. Resolve a break. Post a journal entry. Close a period. These are the things that show up in a blotter, a ledger or an exception file, which is to say they are the things an examiner can sample. Partition those.

The partition is four disjoint sets, and disjointness is the whole property. Order entry and capture holds book, amend, allocate and cancel-correct. Confirmation holds affirm, match against the counterparty record and raise discrepancy. Reconciliation holds resolve, annotate and escalate. Books and records holds post, adjust and close. No verb appears in two sets, and no principal's grant may draw from two sets. The reason to state it as disjointness rather than as a list of forbidden pairs is that a forbidden-pair list is a blacklist, and blacklists are complete only until somebody invents a thirteenth verb.

Reads are unrestricted, deliberately, and that is not a concession. The ops-side agent should read the capture record, the custodian file and the confirmation store, because the quality of its assertion depends on seeing all three. Nothing about provenance is damaged by a reader. The property the lifecycle protects is that the two records being compared were produced by parties with no shared writing path — production, not observation. A design that restricted reads in the name of segregation would be paying a real cost for no gain, and it would also be the design most firms would abandon within a quarter for being useless.

Enforcement sits in the broker that mints the grant, not in the review that approves the deployment. When a principal asks for a capability grant, the broker takes a requested verb set and a stage, and either returns a grant naming exactly one stage or fails. There is no code path that returns a grant spanning two stages, which means there is no configuration in which the illustration from the teardown can be assembled — not because someone declined it, but because the object does not exist. This is the difference between a control and a convention, and it is the only reason the design survives the efficiency review it will meet in eighteen months.

There is a real cost here and it should be named before the objections section rather than in it. The partition means an agent that could have resolved a break in one action now resolves it in two, across a boundary, with a decision in between. If the second half of that never gets decided, the break does not clear and the queue ages exactly as before, with an extra queue added. The design does not survive on strictness; it survives only if the request path is good enough that the capture side actually works it. That is an engineering obligation the design creates, and I will price it later.

Second move: a delegation contract that carries a request and not a capability

The word delegation is doing precise work here and it is worth separating from its usual sense. In most agent architectures, delegation means handing over the ability to act — an agent passes a token, a session or a tool handle to another agent, and the receiver can now do what the sender could do. That is the pattern the general-form pieces in this practice argue against, and in the lifecycle case it is not merely weak, it is exactly the failure being designed away. So this contract delegates in the opposite direction: it moves the assertion and leaves the authority where it was.

The object has seven properties, and each of them is load-bearing against a specific way this goes wrong in production.

1. It is typed, not free text. The request names a record, a defect class and an assertion. Free text makes the request unreviewable at volume and unqueryable afterwards, and it is the format that turns into a rubber stamp fastest, because a reviewer cannot triage what they cannot sort.
2. It names the asserting principal, and that name is the agent, not its operator. Stamping a human's identifier on a machine-generated assertion writes down a decision that did not happen — the same error the banking teardown identifies in span-stamping. The person accountable for the agent is a separate, separately recorded fact.
3. It carries an evidence reference, not an evidence summary. A pointer to the custodian line, the confirmation, the settlement message. A summary is the agent's own output and cannot be the basis on which its own request is judged; a pointer is checkable by the receiver against a record the sender could not write.
4. It expires. An amendment request whose factual basis is a custodian file from nine days ago is asserting something about a world that has moved. Expiry is not tidiness; it is the mechanism that keeps the request queue from becoming a backlog of stale assertions that get approved in a batch when someone finally clears it.
5. It is single-use. One request authorises consideration of one amendment to one record. A reusable request is a capability wearing a request's clothing.
6. It confers nothing. Approval of the request does not grant the asserter a capture verb for any period, under any escalation, for any reason. This is the sentence that the design lives or dies by, and it is the sentence that will be attacked first in an incident, when someone senior asks why the agent that knows what is wrong cannot just fix it.
7. It has a recorded terminal state, including expiry. Amended, rejected with reason, or expired unactioned. A request that vanishes is a queue that lies about itself, and the expired-unactioned count is the single most useful health metric this design produces.

Third move: dual control that is two judgements rather than one judgement twice

Every firm already has four-eyes approval on value-moving actions, and the teardown's objection section explains precisely how it decays: route a machine-rate stream of individually correct items at a human approver and by month four the approval is a batch click. That decay is not a discipline problem and no amount of training fixes it. It is what happens when the second pair of eyes is looking at the same evidence as the first pair, because then the second judgement adds no information and the approver correctly learns that.

The fix is to define the gate by evidence class, not by headcount. The acting judgement is made on inside evidence: the capture record, the order ticket, the desk's stated intent. The concurring judgement is made on outside evidence: the counterparty confirmation, the custodian statement, the settlement message. Those are two different questions — is this our error, and does the outside world agree — and neither answer can be derived from the other party's evidence. That is what makes the second judgement worth making, and it is why the second judgement does not decay into a click: it is not re-checking, it is checking something else.

Which means the gate has an enforceable predicate, not a policy. The reference implementation refuses a concurrence whose evidence class matches the actor's. Two inside-evidence approvals are not dual control at any headcount, and the system says so rather than counting to two. That single refusal is what stops the gate degrading quietly, because degradation in practice looks like a second approver drifting onto the same screen as the first.

The gate applies to value-moving actions only, and the scoping is doctrine rather than convenience. An action is value-moving if it changes a position, a cash movement, a customer balance or a reported figure. Annotating a break is not value-moving. Escalating is not. Amending a settlement date on an unsettled trade is, because it changes what will move. Scoping the gate this way keeps the volume through it low enough that the concurring judgement stays a judgement; a gate on everything is a gate on nothing, and that is the failure mode of most control designs of this shape.

One honest limitation on this move. Dual control across evidence classes is a strong construction and it is not a proof of correctness: both records can be wrong together, most obviously when a custodian and a firm are both fed by a defective upstream feed. The gate does not claim to catch that, and no gate of this shape can. What it does is remove the specific failure the lifecycle boundary exists to prevent — one party's record being adjusted into agreement with itself — and that is a smaller claim than the one a vendor would make for it.

Fourth move: the record an examiner samples, not the architecture they are shown

This is the move most designs of this kind skip, and skipping it is why they fail their first examination despite being correct. A books-and-records examination does not ask to see how the system works. It picks records and asks questions about them. If the answer to those questions requires assembling three systems' logs and a walkthrough with an architect, the firm has an architecture and not an evidence layer, and the difference will be discovered at the worst possible moment.

So every write carries a stamp, written at the moment of the write, with seven fields: the record and its stage; the writing principal; the capability grant identifier under which the write executed; the delegation contract identifier, where the write answered a cross-boundary request; the concurring principal, where the action was value-moving; the timestamp; and the identifier of the independently produced record the write was compared against. Nothing in that list is reconstructed afterwards, which is the property that matters — reconstruction is what the teardown argues cannot be relied on, and a design that reconstructs its own evidence has conceded the argument it was built to answer.

The walk an examiner performs against those stamps is four steps and terminates. Read the writing principal off the record. Resolve its capability grant and read the single stage the grant names. Confirm the stage on the grant equals the stage on the record — a mismatch is not an exception to investigate, it is a state the broker cannot produce, so a mismatch found in the wild means the broker was bypassed, which is a much more useful finding than a policy breach. Then walk both sides of the comparison the record participated in and confirm that no principal appears on both.

That fourth step is the one that answers the question the whole design exists for, and it answers it without replaying anything, without an interview and without a paragraph in a control narrative asserting that separation is maintained. Could one principal have written both sides of this comparison? The stamps answer it directly, as a query, over records the firm already retains.

/** The four stages of the trade lifecycle, in order. The order matters only for reporting;
 *  the disjointness is what the design rests on. */
export type LifecycleStage =
  | "order-entry"
  | "confirmation"
  | "reconciliation"
  | "books-and-records";

/** A write verb: an operation causing a durable change to a record the firm relies on.
 *  Reads are deliberately absent from this type — they are unrestricted by design. */
export type WriteVerb =
  | "book-trade" | "amend-trade" | "allocate" | "cancel-correct"
  | "affirm" | "match-counterparty" | "raise-discrepancy"
  | "resolve-break" | "annotate-break" | "escalate-break"
  | "post-journal" | "adjust-ledger" | "close-period";

/** The partition. Exhaustive over WriteVerb and disjoint by construction: adding a verb to
 *  two stages is a type error at the VERB_STAGE map below, not a policy breach later. */
export const VERB_STAGE: Readonly<Record<WriteVerb, LifecycleStage>> = {
  "book-trade": "order-entry",
  "amend-trade": "order-entry",
  "allocate": "order-entry",
  "cancel-correct": "order-entry",
  "affirm": "confirmation",
  "match-counterparty": "confirmation",
  "raise-discrepancy": "confirmation",
  "resolve-break": "reconciliation",
  "annotate-break": "reconciliation",
  "escalate-break": "reconciliation",
  "post-journal": "books-and-records",
  "adjust-ledger": "books-and-records",
  "close-period": "books-and-records",
};

/** A grant names exactly one stage. There is no variant that names two, which is why no
 *  composition in this system can span a boundary. */
export interface CapabilityGrant {
  readonly grantId: string;
  readonly principal: string;
  readonly stage: LifecycleStage;
  readonly verbs: readonly WriteVerb[];
  readonly issuedAtIso: string;
  readonly expiresAtIso: string;
  /** The named person accountable for this principal. Not an authoriser of any given write. */
  readonly accountableOwner: string;
}

export type MintResult =
  | { readonly ok: true; readonly grant: CapabilityGrant }
  | { readonly ok: false; readonly refusal: string };

/**
 * The broker. Its only interesting property is the refusal: a verb set drawn from two
 * stages does not produce a narrower grant, a warning or an escalation path. It produces
 * nothing, and the caller has to decide which stage it actually wanted.
 */
export function mintGrant(input: {
  readonly principal: string;
  readonly verbs: readonly WriteVerb[];
  readonly accountableOwner: string;
  readonly issuedAtIso: string;
  readonly expiresAtIso: string;
}): MintResult {
  if (input.verbs.length === 0) {
    return { ok: false, refusal: "A grant with no write verbs is a read role; do not mint one." };
  }
  const stages = new Set(input.verbs.map((verb) => VERB_STAGE[verb]));
  if (stages.size > 1) {
    return {
      ok: false,
      refusal:
        "Requested verbs span " + String(stages.size) + " lifecycle stages (" +
        Array.from(stages).join(", ") +
        "). Split the principal, or route the cross-boundary work as a delegation contract.",
    };
  }
  const [stage] = Array.from(stages);
  return {
    ok: true,
    grant: {
      grantId: "grant-" + input.principal + "-" + input.issuedAtIso,
      principal: input.principal,
      stage,
      verbs: input.verbs,
      issuedAtIso: input.issuedAtIso,
      expiresAtIso: input.expiresAtIso,
      accountableOwner: input.accountableOwner,
    },
  };
}

What the design is answerable to

The instruments in this sector are older and more specific than the AI governance conversation assumes, and the useful reading of them is not what they forbid — none of them forbids anything here — but what they oblige a firm to be able to show.

*FINRA Rule 3110 obliges a supervisory system and written supervisory procedures reasonably designed to achieve compliance. The operative words for this design are written and reasonably designed*. A partition that exists as an engineering convention satisfies neither: it is not written, and it is not designed for anything, because nobody stated what it was for. The same partition expressed as a documented allocation of write verbs to stages, with the broker refusal as its enforcement and the stamp as its evidence, is a written procedure with a mechanism behind it — which is a materially different artefact to hand a supervisor. FINRA restated the technology neutrality of these obligations for generative AI in Regulatory Notice 24-09 of 27 June 2024: the rulebook applies to the activity, whatever performs it. That notice does not create an agent obligation, and I am not going to pretend it does. It removes the argument that one is awaited.

*FINRA's material of 27 January 2026 on AI agents is observational, and its value here is evidential rather than normative. Emerging Trend in GenAI: Observations on AI Agents*, with its companion note on agent types, describes what member firms are doing and what supervisory questions the practice raises. It is not a rule, it imposes nothing, and any consultant quoting it as a requirement is overselling. What it establishes is that the front-line regulator is looking at agentic deployment as agentic deployment — which matters mainly for sequencing. A firm that builds the partition now is building before the question is asked; a firm that waits is building after, into an estate already in production, which is the expensive direction.

*The books-and-records rules are the reason the fourth move exists.* The evidentiary weight of a blotter or a ledger does not come from its retention policy. It comes from the fact that its parts were produced by participants who could not individually bend them, and the rules' alteration-resistance requirements protect that after the fact rather than creating it. A firm whose agent estate can write both sides of a comparison has not breached those rules — every required record exists — and that is exactly why the provenance stamp is worth building without being told to. It makes the property the rules assume into a property the firm can demonstrate.

*In India, SEBI Regulation 16C, notified on 10 February 2025, closes the procurement escape.* A regulated entity using AI tools, in-house or bought, is solely responsible for the outputs and the consequences of relying on them. That allocation is sharper than anything in the US instruments, and it lands directly on this design: a firm buying a break-resolution agent from a vendor owns every amendment it causes, so the question of which principal wrote which record is the firm's evidence problem regardless of who built the software. An Indian broker that cannot answer the fourth step of the examination walk cannot point at its vendor while failing to answer it.

*The April 2026 interagency deferral changes the sequencing for bank-affiliated dealers and nothing else.* The revised interagency model risk management guidance of 17 April 2026 — Fed SR 26-2 and OCC Bulletin 2026-13 — places generative and agentic AI outside its scope in footnote 3 and disclaims enforceable standards, while the same footnote returns the determination of appropriate governance and controls for uncovered systems to the banking organisation, and the enforcement basis for unsafe or unsound practices is preserved in the note attached to the non-enforceability sentence. That is a deferral with the obligation intact and the specification withdrawn, not an exemption. The banking pair in this practice reads it in full and I will not re-argue it. The consequence for a dealer is only this: the model risk framework has stepped back from agents while the securities supervision rules never did.

*And for the Gulf, the honest statement is an absence.* I have not been able to verify a securities-specific AI instrument from a GCC market authority that speaks to agent capability, supervision or record provenance, and I am stating that as a verified absence rather than citing something adjacent and hoping. What follows from the absence is not that the question is dormant there — the region's largest institutions are deploying at national-champion scale — but that a firm building in that lane is building against its own stated architecture and a supervisor's general powers, which makes the written procedure and the per-record stamp more valuable rather than less.

The objections, at full strength

Four responses are worth taking seriously, and three of them are from people who have run this function.

"You have moved the bottleneck, not removed it, and the queue you created will rot." This is the strongest objection and it is substantially right. The design converts one action into a request and a decision, and if the decision side is under-resourced the aged-break problem reappears as an aged-request problem with worse optics. My answer is not that this will not happen; it is that the design instruments it. The expired-unactioned count is a first-class outcome, visible weekly, and it measures exactly the failure the objection predicts. A firm whose expiry rate is climbing has a resourcing decision to make with a number in front of it, which is strictly better than the same firm discovering the same fact when the forum asks about the tail again. What I cannot tell you is what a healthy expiry rate looks like, because nobody has run this at scale and published it.

"The capture-side decider is also an agent, so you have two agents and no human anywhere." Correct, and deliberate. The design does not claim a human in the loop; it claims that the two sides cannot be the same principal and cannot see the same evidence. A human decider is available as a configuration and it is the right one for high-value or low-volume flows, but making it mandatory reintroduces the decay curve the teardown priced: a person clicking through four hundred plausible items a day is a stamina measurement. What the design does insist on is that both principals have a named accountable owner, and that the two owners are not the same person — which is where the human accountability actually attaches, at the grant rather than at the item.

"An operator will just log into both systems and do it by hand, and your partition will have achieved nothing except a workaround." This is the objection I find hardest, because it is true and the design does not prevent it. A human with entitlements on both sides can always do what the partition forbids to machines. Three things reduce it and none eliminates it. The stamp records the principal, so the manual route is visible as a manual route rather than blending into agent volume. The partition applies to the human entitlement model too, if the firm chooses — the same broker logic runs against people, and most firms' toxic-pair matrices already say something similar. And the operator route does not scale: the failure this design is about is a machine-rate failure, and a human doing it by hand is the pre-agent risk the firm already manages. But a reader who says the workaround is the real answer has identified a limit, not a misunderstanding.

"This is over-engineering for a break queue, and the throughput cost will kill it." Sometimes. If a firm's break population is small, its instruments simple and its custodian relationships few, the partition is ceremony and a well-run recommendation queue with a human applying corrections gets the same property at a fraction of the cost — and I would tell a firm in that position to do exactly that. The design earns its cost where volume makes human application impossible and where the same estate will grow more agents next year, because that is where the convention degrades and only the constructed refusal holds. The honest framing is that this is a design for the estate a firm is about to have, not the one it has, and any consultant who tells a small dealer otherwise is selling.

What it costs, with the unmeasured parts marked unmeasured

Three costs are structural and one is a number I do not have.

• Latency, structurally. A cross-boundary resolution is now bounded below by the decision interval on the capture side, which is a scheduling property rather than a compute property. Within-lane resolutions — annotate, escalate, and every break that is genuinely the street's error — are unaffected.
• A second queue, permanently. The request queue is a real operational object with an owner, a service level and a health metric. Firms that treat it as a side effect of the partition rather than as a queue they run will get the rot the first objection predicts.
• Storage and query cost on the stamp. Seven fields on every write, retained for the books-and-records period, plus the index that makes the fourth examination step a query rather than a job. This is small in absolute terms and it is not zero, and it is the line item most likely to be cut by someone who does not know what it is for.
• Throughput, unmeasured. I do not know what fraction of aged breaks resolve within-lane versus across the boundary at a real firm, so I cannot tell you what share of the queue takes the slower path. That is the single most decision-relevant number for anyone pricing this design, nobody publishes it, and I have not measured it. A firm can measure it in an afternoon against its own history, and should, before building anything.

If you had a week

The build order is chosen so that the first two days produce a finding whether or not the rest gets built, which is the property that gets this funded.

1. Days one and two: enumerate write verbs, not tools. For every agent and integration touching post-trade, list the operations that cause a durable change to a relied-upon record, and map each to a lifecycle stage. Anything whose verbs land in two stages is the teardown's illustration wearing your configuration. This is the finding, and it exists before a single line is written.
2. Day three: the broker refusal. Implement the partition map and the minting refusal, and run it in report-only mode against the existing estate. Report-only matters: the first run tells you how many current principals would fail to be minted, which is the migration estimate.
3. Day four: the stamp. Add the seven fields on the write path for one stage — reconciliation is the cheapest, because its writes are already structured — and index the two that the examination walk queries.
4. Day five: the contract on one defect class. Pick the highest-volume booking defect and route it as a request instead of an edit, end to end, with the terminal states recorded. One class, one flow, real volume.
5. What to leave out this week: the dual-control gate, every other defect class, the human-decider configuration, and anything to do with corrective-of-a-corrective. Building those before the stamp exists produces a system with a control and no evidence, which is the worse half.

What would falsify this design

Three findings would oblige me to withdraw or substantially rewrite the argument, and I would want to hear about all three.

A reconciliation platform that derives writer provenance natively. If a shipping product refuses to treat a match as evidence when both sides' latest write traces to a common principal — or even surfaces shared authorship as a first-class exception — then the property repairs itself at the point of comparison and most of this construction is unnecessary. The teardown searched vendor documentation and did not find one, which is not proof of absence. If it exists, the correct advice is to buy it, and this piece becomes a description of what that product does internally.

Evidence that the request path decays as badly as the four-eyes gate does. My claim that the concurring judgement survives because it rests on different evidence is a claim about human behaviour, and I have no measurement of it. If a firm ran the design for a year and found that capture-side deciders approve requests at the same rate and with the same attention as batch-clicking approvers, then the evidence-class distinction is doing no work and the design is ceremony with extra latency. This is the most testable of the three, and the one I would most want to be wrong about, because being wrong about it would be informative.

A supervisory finding that treats the written narrative as sufficient. If examinations in practice accept a documented statement that segregation is maintained, without sampling to per-record provenance, then the fourth move is expensive and unnecessary and the design reduces to the partition alone. I have no basis for asserting how examinations go, and I am not going to invent one. What I can point at is that the rules' evidentiary weight rests on independent production, and that this sector has historically responded to attribution problems by requiring identifiers to be carried rather than reconstructed.

And one limit stated plainly, because it cuts against how an argument like this gets used commercially. Nothing here shows that a firm should not put agents on the break queue, nothing here describes an incident, and I know of no published case in which an agent's spanning capability caused a loss at a securities firm. The claim is about what a firm can demonstrate when a record is sampled — which is narrower than a prediction, and is the only claim the evidence supports.