The repository now contains a credible bounded agentic reference slice for an unauthorized transaction requiring card block, dispute creation, and replacement. The implementation adds typed planning, explicit graph control, deterministic tool governance, two-actor scoped approval, idempotent side-effect recovery, failure/replan/escalation behavior, structured audit evidence, 100-scenario evaluation, a 200-run concurrent reliability experiment, planner canary/fallback controls, operator/customer UX, security analysis, CI, and reviewer documentation.
The legacy multi-agent support graph is preserved as banking_support; the new graph is registered
as flagship_support.
- Backend: 40 tests, Ruff, focused mypy, and
pip-auditpass. - Admin: lint, one component test, production build, and production dependency audit pass.
- Customer: Prettier, two contract tests, production build, and production dependency audit pass.
- Evaluation: 100 scenarios; all hard gates pass; zero unauthorized calls; zero duplicate side effects; 100% supported completion, high-risk escalation recall, approval compliance, and loop termination.
- Reliability: 200 concurrent deterministic runs; 100% completion/termination, zero unauthorized calls, zero duplicate effects, 24.74 runs/s, and 1.37-second p95 locally.
- Container: Compose config and LangGraph API image build pass.
- Demo: all five steps complete after one deterministic timeout/replan; three side effects occur exactly once; complete audit artifact is written.
- AI release: the prompt policy has a versioned SHA-256 fingerprint, thread-stable canary selection, and immediate deterministic fallback with audit metadata.
- Architected a bounded LangGraph planner-executor platform for high-risk banking support, combining typed plans, deterministic authentication/authorization gates, scoped dual approvals, and one-capability-at-a-time tool execution.
- Designed a versioned tool governance layer with Pydantic contracts, least-privilege permissions, risk/approval metadata, timeout/retry policies, and durable idempotency that prevents duplicate financial side effects across retries and process restarts.
- Built a 100-scenario adversarial evaluation harness covering prompt injection, approval abuse, partial failures, response loss, restart recovery, and loop budgets; achieved 100% supported-task completion and escalation recall with zero unauthorized calls or duplicate effects in deterministic CI runs.
- Delivered customer and operations approval experiences, structured audit/latency/token/cost telemetry, dependency and secret scanning, Docker validation, threat modeling, ADRs, and production-readiness controls.
Why not let the model call tools directly? Banking actions require controls that are stable, testable, and attributable. The model proposes a schema-valid plan. Code independently validates tool identity, permission, risk, customer scope, approval, arguments, retry policy, and budgets.
How is the loop bounded? Every selection cycle checks agent steps, elapsed time, token/cost budgets, per-step tool attempts, and plan revisions. Each terminal branch records an explicit reason.
How do approvals stay meaningful? The interrupt contains plan ID/revision, actor role, expiry, eligible step IDs, permissions, exact arguments, and expected result. A decision is rejected if its plan, role, scope, or expiry is wrong. Execution rechecks coverage.
How are duplicate financial actions prevented? A stable operation key and request hash are persisted before execution. Completed operations return the prior result. External success is recorded before a simulated response-loss failure, so retry recovers rather than invokes again.
What happens during partial failure? Safe retry categories replan the same idempotent step within hard budgets. Permanent, invalid, policy, or exhausted failures escalate with completed steps and recovery context intact.
What is real versus simulated? Control flow, contracts, persistence semantics, tests, evaluation, UI builds, and container build are real and locally verified. Identity, RBAC, banking providers, regulated data, hosted observability, and deployment operations are simulated or pending.
- Introduce real customer/workforce identity and server-side RBAC with maker-checker controls.
- Integrate one provider sandbox behind the registry and migrate the ledger to managed Postgres with reconciliation.
- Run live-model evaluation with redacted traces, multilingual/adversarial slices, token/cost budgets, and human review.
- Deploy to a non-production environment and complete public-route, accessibility, load, failure, security, and disaster-recovery acceptance.
The identity/authorization and provider-consistency implementation choices are documented in the security hardening portfolio and remain intentionally unselected.