Agent Execution Boundary

A small reference implementation of an AI agent proposing a purchase order while a deterministic runtime decides whether that proposal may become an external effect.

The model proposes business data. It does not choose:

• principal identity
• delegation
• policy
• approval
• execution state
• ERP authority

The model-controlled PurchaseProposal has exactly this shape:

{
  "supplier_id": "SUP-42",
  "amount_minor": 1250000,
  "currency": "EUR"
}

Unknown or missing fields fail closed. The supplier identifier is bounded, the amount is a positive signed 64-bit integer (not a boolean), and the currency must be EUR. No model API is required to run the examples.

Concept	Question
Intent	What exact action is requested?
Permit	Why may this exact action happen?
Execution	What do we know happened?

An EffectReceipt is the authoritative downstream terminal evidence used to update Execution knowledge.

One logical effect has:

• one stable logical identity
• one immutable content identity
• one frozen authorization binding
• one frozen effect-boundary precondition
• one terminal downstream decision

Physical delivery may repeat. Meaning may not. This is not an exactly-once transport guarantee.

Quick start

Use Python 3.12 or newer, preferably in a virtual environment. From the repository root:

python -m pip install -e .
python -m unittest discover -s tests

boundary demo happy
boundary demo approval-replay
boundary demo stale-state
boundary demo lost-response

For an uninstalled checkout:

PYTHONPATH=src python -m boundary.cli demo happy
PYTHONPATH=src python -m unittest discover -s tests

The module form accepts all four scenario names. Each demo uses fresh temporary databases and a fixed trusted Intent UUID for repeatable output; the temporary files are removed on exit.

Four demos

• happy: a valid under-limit proposal becomes a Permit, a durable UNRESOLVED Execution, an ERP APPLIED receipt, and KNOWN_APPLIED.
• approval-replay: an over-limit action requires approval bound to the exact Intent and trusted subject. Policy changes before admission is rerun; the runtime reloads delegation and active policy, and the new Permit binds the new policy revision while retaining the same approval.
• stale-state: ELIGIBLE@1 -> BLOCKED@2 -> ELIGIBLE@3. The original Permit still expects revision 1, so the ERP records terminal NOT_APPLIED without creating a PO. The same current boolean cannot revive an old precondition.
• lost-response: the real ERP transaction commits a PO and receipt, then the CLI simulates response loss. Runtime knowledge remains UNRESOLVED; reconciliation observes the receipt without redelivery. One PO remains.

Excerpt from lost-response:

Fence        UNRESOLVED
After loss   UNRESOLVED
ERP receipt  APPLIED / PO-1
Final state  KNOWN_APPLIED
External ref PO-1
PO count     1

Why two SQLite databases?

The runtime store and ERP are deliberately separate transaction domains. Illustrative persistent locations would be .runtime/runtime.db and .erp/erp.db; these are not CLI defaults. The demos actually create runtime.sqlite and erp.sqlite inside one temporary directory.

Separating the files prevents one ACID transaction from hiding the uncertainty between runtime authorization and downstream commit. It does not establish production deployment or process isolation. Both components run locally.

Important semantics

• Logical identity differs from content identity. Two identical purchases can have different intent_id values and the same intent_digest. The trusted subject is stored separately from business content.
• Policy time differs from policy content. Activating A -> B -> A creates R1 -> R2 -> R3. Equal content digests do not resurrect R1 authority.
• Supplier revisions matter. Eligibility changes increment a revision; returning to ELIGIBLE does not restore a previously authorized revision.
• Historical bytes define historical identity. Stored schema, canonical bytes, and their digest define persisted identity. Loading verifies stored bytes directly, without rebuilding old identity with today's serializer. Authorization, approval targets, and delivery use that persisted Intent digest.
• Execution is epistemic. Its only states are UNRESOLVED, KNOWN_APPLIED, and KNOWN_NOT_APPLIED; they describe available evidence.
• Infrastructure failure is not NOT_APPLIED. Without terminal evidence, an unresolved execution stays uncertain, even if the ERP may have committed.
• Recovery preserves meaning. Observe first; if evidence is absent, redelivery requires current authority for the exact pinned Permit. Intent, authorization reference, and eligibility precondition remain unchanged.

See ARCHITECTURE.md for transaction ordering and trust assumptions.

Repository shape

src/boundary/
    domain.py    immutable vocabulary, validation, canonical identity
    kernel.py    pure admission and evidence semantics
    runtime.py   ordering of irreversible operations
    store.py     runtime durability and local transaction boundaries
    mock_erp.py  authoritative downstream effect and terminal receipts
    cli.py       deterministic public demos

There are no runtime dependencies beyond the Python standard library. Packaging uses setuptools; tests use unittest.

Tests

The suite includes executable cases for policy ABA and revoked-delegation replacement, persisted historical serializer independence, transaction rollback, durable uncertainty before effecting I/O, stale supplier preconditions, lost responses after ERP commit, duplicate physical delivery, concurrent recovery, revocation races, and terminal knowledge monotonicity.

GitHub Actions runs the complete suite on Python 3.12.

Scope and non-claims

This is an executable reference, not an agent framework, LLM SDK example, workflow engine, ERP product, production IAM system, or distributed transaction system. These are explicit scope boundaries, not hidden guarantees:

• authentic provenance of human intention
• prompt injection producing a policy-valid but unwanted proposal
• semantic duplicate suppression before Intent creation
• aggregate spending limits or split-transaction policy
• atomic revocation across runtime and ERP
• malicious or compromised trusted runtime, authoritative ERP, or runtime DB attacker
• independent backup rollback of one transaction domain
• multi-effect workflows or effects beyond authoritative PO creation
• production HA, throughput, multi-region operation, or distributed consensus
• resource-exhaustion controls or rate limits
• actual process or network sandboxing

The runtime and ERP are trusted. Digests are integrity references, not credentials or signatures. Model-controlled code must not possess direct effect authority in a real deployment; this repository does not enforce that isolation.

License

MIT. Copyright (c) 2026 Mark Pavliucenko.