Z User
136379c666
- 18 agent specs across Software, Support, Marketing, Cross-cutting (orchestrator + 7 software + 5 support + 3 cross-cutting + leads-finder) - 8 reusable skills (handoff, pr-review, dokploy-deploy, campaign-structure, content-calendar, ticket-triage, license-lifecycle, invoice-draft) - 3 JSON schemas: handoff, deliverable, approval - Policies: autonomy levels, tool risk classification, compliance (DSGVO/GoBD/UWG) - routing.toml: model tiers T1/T2/T3 + provider config (PII gating) - Rust workspace (5 crates, all compile + 16 tests pass): - aos-mcp: tool registry + risk tagging - aos-policy: autonomy levels, budget enforcement, approval requests - aos-license: ed25519 license issue/verify (real crypto + CLI binary) - aos-ledger: integer-cents money math, gapless numbering, VAT, audit chain - aos-sync: frontmatter validator (18/18 specs pass), CLI binary - CLAUDE.md entry point with architecture overview + roadmap
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# Autonomy Levels & Approval Gates
|
||
|
||
Every agent spec declares an `autonomy` level (L0–L2). L3 (full autonomy)
|
||
is **not used** initially — the cost of an autonomous mistake is higher than
|
||
the cost of a human click.
|
||
|
||
## Levels
|
||
|
||
| Level | Meaning | Examples |
|
||
|-------|---------|----------|
|
||
| **L0** | Read/analyze only. Produces a report/draft, changes no state. | Audits, research, reports, estimates |
|
||
| **L1** | Drafts inside the system; a human approves before anything leaves. | Client emails, social posts, invoices, ad campaigns, outreach |
|
||
| **L2** | Acts alone within caps and reversible scope. Internal-only side effects. | Ticket triage, internal task creation, low-risk support replies, internal notes |
|
||
|
||
## Hard rules — always human-approved regardless of level
|
||
|
||
These are enforced by the `aos-policy` Rust crate (not the prompt). An agent
|
||
attempting one pauses the task and emits an `ApprovalRequest`
|
||
(see `schemas/approval.json`).
|
||
|
||
- **Spending money** (ads, API fees, paid tools)
|
||
- **Publishing publicly** (website go-live, social post, blog article)
|
||
- **Sending invoices**
|
||
- **First client/prospect contact** (email, message, call)
|
||
- **Sending outreach** (cold B2B — UWG §7, draft-only by default)
|
||
- **Revoking licenses**
|
||
- **Deleting data / instances / DNS records**
|
||
- **Production deploys**
|
||
- **DB migrations on live data**
|
||
- **Anything filed with authorities** (UStVA, EÜR, ELSTER)
|
||
- **Contract changes** (new, amended, terminated)
|
||
- **Budget changes** (raising a campaign cap, approving extra spend)
|
||
|
||
## How approvals surface
|
||
|
||
- An `ApprovalRequest` lands in the AOS approval inbox.
|
||
- A notification goes to the human approver (phone/Slack/email — channel TBD,
|
||
see open questions).
|
||
- The approver sees: action, risk, rationale, diff summary, estimated cost,
|
||
the originating task + agent, and the full structured payload.
|
||
- Approving resumes the task; rejecting fails it with a reason logged.
|
||
|
||
## Budget enforcement
|
||
|
||
Each agent spec declares `budget.max_eur_per_task` and `budget.max_tokens`.
|
||
The policy crate tracks cumulative spend per task_id and hard-stops when the
|
||
cap is reached — no agent can spend past its declared ceiling, even with
|
||
approval, without an explicit budget-increase approval.
|