OpenEXAAgentic infrastructure Request access
Platform Lifecycles Proof Trust Research Company Request access
Trust & governance

Autonomous agents. Accountable by construction.

Autonomy is a dial, not a leap. Agents propose; the Execution Council approves or rejects against your policy; scoped permissions bound what any agent can touch; custody never moves; and every transition is written to a ledger you can replay.

01The governance modelSix commitments
  1. T-01

    Every proposal passes the Council

    No agent executes its own idea. Proposals go to the Execution Council, which checks policy, limits and conflicts and returns approve or reject — automatically, or by handing the decision to a human.

    Propose → Council → approve / reject
  2. T-02

    Custody never moves

    Assets stay in your brokerage account. Agents act through scoped API permissions — they can operate within your limits; they can never withdraw. Permissions are revocable per agent, instantly.

    Broker-held · scoped · revocable
  3. T-03

    The ledger is the truth

    Append-only, hash-chained records preserve every proposal, Council decision, submission, fill and reconciliation — including the rejects. Nothing is edited after the fact; every record points at the one before it.

    Append-only · hash-chained · replayable
  4. T-04

    Autonomy per lifecycle, per mandate

    Fully automatic, auto-with-approval and manual modes support different mandates and oversight levels — switchable at any time, without redeploying an agent.

    Automatic · with approval · manual
  5. T-05

    Deterministic below the agents

    Limits live in the execution layer, not in the model that proposed the action. Whatever an agent believes, the state machine enforces caps, gates and idempotency before anything exists as an order.

    Enforced in code · not in a prompt
  6. T-06

    Resilient by default

    The emergency halt is database-backed and available in every mode. Counterparty and API disruptions are met with retries, exponential backoff and circuit breakers. Compliance framing — Reg D 506(c), accredited investors — is built into onboarding.

    Halt · retry · backoff · circuit-break
02Control planeWhat you set. What agents obey.

Limits are not suggestions.

Every constraint below is enforced in the deterministic execution layer — before an action exists — not in the agent that proposed it. Change any of them at any time; the swarm obeys on the next proposal.

K-01Scope

Instruments & venues

Whitelisted instruments and routing venues per lifecycle. Anything else is rejected at validation.

K-02Size

Position & notional caps

Per-instrument and per-pool position limits, notional caps per action and per session.

K-03Time

Market-hours gates

Actions only inside defined windows; no after-hours surprises from an agent that never sleeps.

K-04Approval

Who signs

The Council alone, a delegate, or you — and change it whenever the mandate changes.

K-05Visibility

Positions, NAV, fills, decisions

Operators and investors see positions, NAV, strategy-level performance and every Council decision in real time.

K-06Stop

Emergency halt

One action, any operator, every mode. Halts new proposals and works open actions down safely.

03The ledgerAppend-only · hash-chained

Not a black box. A book of record.

Every transition is traceable to the agent that proposed it and the decision that allowed it. Any state — proposed, rejected, approved, submitted, partially filled, filled, reconciled — can be replayed with the inputs that produced it, by an operator, an auditor or a regulator.

lifecycle 01 · IBIT · createchain ✓
#4f1a · 09:31:03.902 · PROPOSED · agent=strategy:s-0412 · create 2,600 · prev 8c1d
#4f1b · 09:31:03.951 · REJECTED · council · notional cap exceeded · prev 4f1a
#4f20 · 09:31:04.071 · PROPOSED · agent=strategy:s-0412 · create 2,000 · prev 4f1b
#4f21 · 09:31:04.118 · VALIDATED · schema ✓ policy ✓ caps ✓ hours ✓ · prev 4f20
#4f22 · 09:31:04.203 · APPROVED · council · mode=auto-with-approval · by=operator:bs · prev 4f21
#4f23 · 09:31:04.377 · SUBMITTED · agent=exec:e-0088 · venue=dark · idem=7a…e2 · prev 4f22
#4f24 · 09:31:05.910 · PARTIAL · 1,400 / 2,000 · prev 4f23
#4f25 · 09:31:06.442 · FILLED · 2,000 / 2,000 · prev 4f24
#4f26 · 16:05:12.006 · RECONCILED · agent=recon:r-0031 · internal ≡ broker · Δ 0 · prev 4f25
Illustrative log excerpt · rejects are recorded tooEvery record references its predecessor's hash
04Plain languageWhat the agents do — and do not do
What the agents do
  • Run selected lifecycles end to end — signal, decision, execution, settlement, reconciliation — under risk limits and Council governance.
  • Give operators and investors real-time visibility into positions, NAV, strategy-level performance and every decision.
  • Act through API permissions you grant and can revoke, with your broker as custodian throughout.
  • Write every transition, including rejects, to an append-only, hash-chained ledger you can inspect.
What the agents do not do
  • They do not custody funds. Ever.
  • They do not promise guaranteed returns. Performance is market-dependent and capital is at risk.
  • They do not hide decisions inside a model. The execution layer is deterministic and every action is attributable to an agent and a Council decision.
  • They do not act outside the mode you set — and they stop, in every mode, when any operator says halt.
Access

Bring your compliance team.

We will walk through the Council, the permissions, the control plane and the ledger with the people whose job is to say no.

Request access Inside the stack