Limitations and maturity
The five projects are runnable reference architectures for learning. They are not products, not audited and not certified. They are written to be understood, and each documents its own gaps. This appendix collects the gaps that matter most when you read the book, as of the pinned revisions.
Maturity at a glance
| Project | What is implemented and tested | Notable gaps (documented upstream) |
|---|---|---|
| I · template | gateway with OIDC/PKCE and sessions; segmented networks; MCP capability boundary; guardrails; four evaluation suites; tracing; opt-in signed approvals with point-of-mutation verification | the agent runtime holds the MCP service key and the symmetric approval-signing secret, so a runtime compromise can mint approvals (documented trust model); no per-user data authorisation, secrets management, migrations or trace-store access control; nonce conflicts and audit rollback not covered by automated tests; several checks run only against a live cluster. → Limitations |
| II · Sophos | single-agent graph; SQLite checkpoints with sync durability; run records and lazy recovery of interrupted runs; resume; SSE with reconnection | no approvals, guardrails, OpenTelemetry, evaluation or cancellation; no exactly-once side effects; no multi-agent orchestration; several runtime behaviours shown by labs, not unit tests |
| III · ETF Research | spec-driven, versioned rules engine (extensively unit-tested); advisory-only model enforced in code; mandatory signed approvals with recomputation under lock | the same runtime-held signing secret as Part I; dated data snapshot, no live data, no brokerage or trading; investor profile parsed but not validated; append-only trigger untested; boot-time fund refresh without a history row; past decisions not fully reproducible. → Limitations |
| IV · Arktos | four public-only tools (pinned by tests); HMAC API-key lookup; HKDF key separation; versioned AES-256-GCM; SQLCipher; standard derivations with test vectors | no signing, broadcasting or balances; plain HTTP (TLS expected from deployment); no master-key rotation or HSM/KMS; admin key operations not logged; the operator can decrypt phrases |
| V · Tauros | actors, ownership, destinations, immutable revisions, state machine, idempotency, exact-payload approval, locks and unique indexes, application-level event record, eight-tool MCP surface | audit not database-enforced; no four-eyes rule; no payments, issuing or reconciliation; concurrency tests do not exercise real lock contention; some decisions available only via REST or console |
How to read claims in this book
- Implemented means the pinned code does it.
- Tested means a named test in the pinned repository checks it. Where a behaviour is only observed in a lab run, the lesson says so.
- Documented limitation means the project itself states the gap.
- Challenge, future design or roadmap means it does not exist yet.
The book's editors did not run the projects' test suites or application stacks to produce this edition. Claims were checked by reading the pinned code and tests. If you find a statement in the book that the code contradicts, please report it (see Corrections and contributions).
What this book does not claim
- That any project is secure, production-ready or compliant with any law, regulation or standard.
- That any project gives financial advice, executes trades or moves money.
- That checkpointing, approvals or audit trails provide guarantees beyond what their chapters state.
- That the projects are integrated with one another. See What is integrated, and what is only designed.