Skip to content

Instantly share code, notes, and snippets.

@zmanian

zmanian/agentic-policy-first-roadmap.md

Created June 23, 2026 17:53
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save zmanian/8dac665825f04123daf8193803456686 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save zmanian/8dac665825f04123daf8193803456686 to your computer and use it in GitHub Desktop.
Download ZIP
Agentic policy-first roadmap: observe and recommend before execution
Raw
agentic-policy-first-roadmap.md

Agentic policy-first roadmap: observe and recommend before execution

Status: roadmap / planning. No implementation. V1 remains exactly as launched — Aave-only, human-approved, click-based. Everything below the V1 boundary is future, gated work tracked as separate issues/cards; nothing here enables autonomous or live agent execution.

1. Summary

The product direction after V1 is observe and recommend first; execute later, and only under explicit policy guardrails.

  • The agent's first job is to see (idle assets, positions, risk) and recommend — never to move funds on its own.
  • Every deployment still routes through the proven, human-approved preview path (the existing IntentPreviewModal flow). The human reviews and approves; the agent does not.
  • Live agent execution is future, gated work. It is out of V1 and requires a policy layer, runtime/app-key integration, a walletRequest review, and a capped live-smoke proof before it can be considered — see workstream D.

2. Why now

  • The market is moving toward agentic finance; Coinbase/Robinhood-style agentic trading directions validate the category.
  • This product should differentiate as a non-custodial agentic treasury/yield operator, not a retail trading bot: the value is safe, explainable, policy-bounded treasury operation, with the human retaining approval and a non-custodial trust model.
  • Recommendation + monitoring is shippable and monetizable before any autonomous execution, and it builds the policy/audit foundation that gated execution will require.

3. V1 boundary (do not regress)

V1, as launched, is the safe floor every future workstream must preserve:

  • Aave-only, human-approved, click-based execution.
  • Withdraw is redeem-to-intermediary only.
  • No return-to-wallet / outOperation bridge-back in V1 (fenced in UI + API; board decision A, PR #86).
  • No live Aomi runtime / walletRequest / execute-from-card in V1 (the asset-first core landed as inert foundation, PR #84).
  • Settlement is not overclaimed: Aurora SUCCESS is diagnostic, not proof; on-chain balance/presence evidence is authoritative (PR #81; runbooks).

4. Workstream A — Policy layer spec

A declarative, auditable policy that bounds what an agent may ever propose or (later) execute. Spec only in this workstream; no enforcement code yet.

Required policy fields:

  • max amount per action and per window.
  • allowed assets (V1: USDC).
  • allowed venues (V1: Aave v3).
  • allowed actions (e.g. supply, redeem-to-intermediary).
  • blocked actions (e.g. return-to-wallet/bridge-back unless separately approved).
  • no bridge-back unless explicitly approved by a separate decision.
  • human approval required — the default and, for V1-adjacent work, the only mode.
  • emergency stop / disconnect switch — a single control that halts all agent activity.
  • audit log / policy explanation — every recommendation/decision records which policy allowed/blocked it and why.

5. Workstream B — Agent recommendation → human-approved preview

The agent observes and recommends; the human still approves through the existing preview path. No autonomous execution.

  • Agent can observe idle USDC (read-only, via the existing portfolio/MCP read path).
  • Agent can recommend an Aave supply action sized within policy.
  • Agent can explain risk/reasoning for the recommendation.
  • Agent opens the existing preview path (IntentPreviewModal via the already-shipped cardToModalProps contract) — it does not build a new execution path.
  • The user reviews and approves; the agent never signs, submits, or executes.
  • Reuses the asset-first foundation already merged (PR #84) — wiring it into the page surface is the new work, behind the human-approval boundary.

6. Workstream C — Treasury monitoring / report loop

A read-only monitoring/report product that is shippable and monetizable before any execution autonomy.

  • daily/weekly idle-asset report (what's uninvested and where).
  • active positions across supported venues.
  • pending settlement warnings (reuses the #81 presence-evidence signals).
  • risk notes (venue/asset/contextual).
  • suggested next actions (recommendations, not executions).
  • monetization: treasury-monitoring subscription / concierge beta (relates to the existing Post-V1 "Product fee / treasury / legal model" card).

7. Workstream D — Future gated policy-based execution

Policy-bounded agent execution is not part of current V1 and is explicitly gated. It may be considered only after all of:

  • the policy layer (workstream A) exists and is enforced + audited;
  • Aomi app-key / runtime integration is in place and reviewed;
  • a walletRequest / wallet-hand-off review is completed (real @aomi-labs runtime, pendingWalletRequests/resolveWalletRequest/ simulateBatchTransactions);
  • a capped live-smoke proof passes with strict limits;
  • auditability (every action traceable to an approving policy) is in place.

Until then: explicit no-go. This requires its own decision card and Gate-0 review; it must never ship implicitly. Relates to existing Post-V1 cards "Full Aomi/chat money-agent proof loop" (zgve7R8) and "Guarded chat-to-click-flow handoff prototype" (zgve7RI).

8. Safety principles

  • No secrets / no private keys in code, docs, or logs.
  • No hidden or implicit live execution — execution is always explicit, gated, and human-approved (until workstream D is separately approved).
  • No overclaiming settlement — on-chain evidence is authoritative.
  • No unsupported return-to-wallet / bridge-back path.
  • A clear, always-visible human approval boundary; the agent recommends, the human decides.
  • Emergency stop available at every stage that touches the money path.

9. Proposed tracking issues

  1. SPEC: Agent policy layer guardrails — acceptance: a reviewed policy spec enumerating the workstream-A fields, with explicit defaults (human-approval required; no bridge-back; emergency stop) and an audit/explanation model. No enforcement code.
  2. FEATURE: Agent recommendation to human-approved preview — acceptance: the agent can surface an in-policy Aave supply recommendation that opens the existing preview/approval path; no autonomous execution; reuses #84 foundation + the IntentPreviewModal contract.
  3. FEATURE: Treasury monitoring and report loop — acceptance: a read-only periodic report of idle assets, active positions, pending-settlement warnings, risk notes, and suggested next actions; no execution.
  4. DECISION: When can agent execute under policy? — acceptance: a recorded decision enumerating the workstream-D prerequisites and an explicit no-go until all are met.

Related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment