1. Work
  2. AI agents and governed actions

Department AI agents with human approval gates

A family of chat-based department agents on shared, hardened foundations where the model does the routine work but every consequential action waits for an expiring, single-use human approval and every figure comes from code.

Problem

A business with several busy departments wanted AI help in all of them at once: engineering management, finance operations, and marketing and growth. Each had routine work that ate hours every week: chasing daily updates and stalled tasks, pulling finance data from separate systems to reconcile payments and chase overdue invoices, producing content, and handling every online purchase across several downstream tools. An AI agent could take much of this on, but letting a language model act directly on business systems is a real risk. It can take the wrong action, invent a figure, or change something nobody approved.

Goal

A family of chat-native department agents on shared, hardened foundations, in which the model does the routine work while every consequential action stays under explicit human control, every figure comes from code rather than from the model, and everything the agents propose, approve and do is recorded.

My role

I built the engineering-manager agent, the finance-operations assistant and the reusable chat gateway. I also set up the basic structure of two further department agents that were planned but not built.

Solution

Three main agents on one shared pattern, plus a common front door.

A reusable chat gateway gives every department agent the same secure plumbing: signed-request checks, duplicate-event protection, per-thread session memory, cost tracking and automatic recovery.

An engineering-manager agent runs a tool-using LLM loop in which every tool declares a risk tier and passes a three-tier approval gate. Approvals expire, cannot be replayed and execute exactly what was approved.

A finance-operations assistant has an expensive orchestrator model plan and delegate, while cheaper sub-agents fetch and analyse and deterministic modules produce every number. A declarative job pipeline refuses to build a report on stale or failed inputs.

A content and growth platform runs a multi-agent writing workflow on explicit state machines with an LLM judge, a purchase-event pipeline with per-step status, and a customer-data warehouse exposed to AI assistants through read-only MCP tools.

How it works

Shared chat gateway. The events endpoint verifies the platform's request signature, drops duplicate and bot-authored events, and acknowledges at once so the platform does not retry. Each mention is processed asynchronously against a per-thread session record (expiry, message count, cost), resuming that thread's previous agent session so context carries over. If resuming fails, it starts a fresh session and retries. Replies post in the thread with status reactions; the service runs as a non-root container on a serverless platform.

Engineering-manager agent. The model chooses from a registry of typed tools grouped by area. The approval gate classifies each call: read-only tools run at once; low-risk writes run and are logged for a daily digest; high-risk writes are not executed but become an approval request (planned steps, expected impact, reversibility, expiry) shown to the approving person as an interactive chat card. Approval is a single atomic database update that only succeeds while the request is still pending and unexpired, and the stored tool input then runs exactly as proposed, so nothing can be approved late, twice or altered after approval. Scheduled jobs collect daily updates, snapshot sprint metrics and run independent proactive checks in parallel that tolerate any single check failing, suppress repeats and push only critical findings. A companion worker takes tasks assigned to the agent, posts a plan, waits for approval, executes with a headless coding agent and reports back. Cloud functions listening to budget alerts cut billing on a project that overruns.

Finance-operations assistant. The orchestrator reaches billing, accounting, payment, help-desk, task and document systems through tool servers, with credentials injected at runtime. For a data-heavy request it writes a dispatch plan instead of doing the work; a post-tool hook detects the plan and fans it out: fetcher sub-agents on a small model pull data, then analyst and writer sub-agents with no tool access work only on what was fetched, in parallel where possible. Deterministic modules supply the finance logic the model must not improvise: receivables ageing, overdue escalation, bank-feed matching (exact, then rule-based, then fuzzy), payment-settlement reconciliation, supplier-bill audits and client-health scoring. A declarative pipeline runs scheduled jobs in tiers (collect, reconcile, report); each job carries a gate for freshness or a quality threshold, downstream jobs are blocked when an upstream gate fails or goes stale, a watchdog catches jobs that never ran, and the job's owner gets a chat alert. Every action is written to an audit log in object storage.

Content and growth platform. Each workflow type has its own explicit transition table, and any transition not in the table is rejected. Research agents gather context, a writer drafts, and an LLM judge scores the draft against a style rubric, sending low scores back with feedback; an optional human review approves or requests revisions before publishing. Persisted state makes runs resumable and auditable. The purchase webhook verifies the payment provider's signature and deduplicates events, then runs a fixed sequence of independent downstream steps, each catching its own errors and writing its status into a per-purchase record, so one failure never blocks the rest and staff can fix exactly the step that failed. Customer-data syncs pull incrementally with per-source watermarks and an overlap window for late data, and merge deduplicated rows into permanent tables without ever truncating them; a stateless MCP server exposes customer lookup, journey and attribution tools behind identity or token checks.

Planned agents. Two further department agents reached scaffold stage only; one sketches a specialist agent exposed as an internal service for authenticated internal callers, resuming the caller's expiring session or starting a fresh one. No capability is claimed for either.

Technical challenges

Letting an LLM act on real systems safely: per-tool risk tiers, approval requests that cannot be replayed or approved after expiry, and executing exactly the input a person approved.

Keeping figures honest: every financial number comes from deterministic code; the model explains, it does not calculate.

Cost and latency on large data pulls: the expensive model only plans, cheap models fetch, and tool-less models analyse.

Parallel sub-agents inside an agent runtime with no native fan-out, solved with a file-based dispatch contract and a post-tool hook.

Stopping reports built on stale data: freshness and threshold gates, dependency blocking, a watchdog and owner alerts.

Keeping a multi-agent content workflow deterministic and auditable with explicit, persisted transitions, while bounding judge-driven rewrite loops.

Long chains of third-party calls: independent steps, per-step status and idempotent webhook handling.

Meeting a chat platform's fast-acknowledgement rule while agent runs take much longer, and recovering from broken sessions automatically.

Proactive monitoring that stays useful rather than noisy: independent checks, deduplication and severity thresholds.

Capping cloud spend automatically rather than by review.

Capabilities

  • Chat access to department agents with per-thread memory
  • Sprint health monitoring and anomaly alerts
  • Daily update collection and daily digests
  • Staff account onboarding and offboarding behind approval
  • Task pickup with plan, approve, execute and report
  • Plain-language questions across finance systems
  • Receivables ageing, bank matching and settlement reconciliation
  • Supplier-bill audits
  • Gated, scheduled finance reports
  • Research-to-publish content workflows with LLM quality scoring and human review
  • Purchase fan-out with per-step audit status
  • Incremental customer-data warehouse with MCP tools
  • Budget kill switch
  • Full audit trail of proposals, approvals and actions

Technology

  • TypeScript and Node.js
  • Python with FastAPI and Flask
  • Hosted large language model API with tool use
  • AI coding agent in headless mode
  • Top-tier orchestrator model with smaller sub-agent models
  • Model Context Protocol tool servers
  • MCP server that keeps no session state
  • PostgreSQL and a document database
  • Cloud data warehouse with staging and merge
  • Docker multi-stage builds
  • Managed serverless services and jobs
  • Secret management and managed SQL
  • Scheduling and budget-alert functions
  • Team-chat interactive cards and signed webhooks
  • Payment-provider webhooks with signature verification
  • YAML job definitions
  • Vitest and pytest

Impact

Routine engineering-management, finance and content work moved into chat agents while a person stayed firmly in control of every consequential change. Finance figures come from code, reports cannot run on stale inputs, purchase handling shows exactly which step failed, and there is a complete, searchable record of what each agent proposed, who approved it and what it did. No metrics are claimed.

Skills demonstrated

  • Agentic system design
  • Human-in-the-loop safety design
  • LLM tool use and tool-registry design
  • Multi-agent orchestration and cost-aware choice of model tiers
  • Deterministic guardrails around LLM output
  • MCP development
  • Chat bot integration
  • Anomaly heuristics
  • Cloud cost governance
  • Serverless deployment and CI/CD

Demo

Live demo

Chat with a pretend project agent for an invented app studio. Routine requests run at once and every figure is worked out by code; a change asks you to confirm; deleting a task needs an approval card that runs once, expires, and refuses a second click; and a budget switch stops the agent when its allowance runs out. Every step is written to a log.

Try the demo

A demo here uses only invented names and data.

All work