Agent Briefing Gateway

A design model for the agent that stands between a human and a batch of working sub-agents, so the human receives one consolidated brief per cycle instead of a stream of interruptions — with an override channel for the genuinely urgent, and approval gates that a parked agent can actually be resumed through.

Status: model only. This repo plots out how it should work. Nothing here is built. See open questions for what is still unsettled.

Where the idea comes from

Working for individual clients, I wanted an outbound email gateway: a piece of middleware that held my messages to a client through the week and delivered one consolidated status report on a schedule, with an override for anything that genuinely could not wait.

This is the same mechanism pointed the other way. There, the scarce resource was the client's inbox and the traffic was outbound. Here the scarce resource is my attention, and the traffic is inbound — a batch of AI agents each working a separate task, each with progress to report, questions to ask and actions to get approved. Left unmediated, five agents produce five conversations and the supervision cost exceeds the work saved.

So: the same staging-and-batching middleware, with an agent in the middle instead of a mail relay, and status updates rather than emails as the payload.

Shape

  worker agents                gateway agent                     human
 ┌──────────────┐        ┌───────────────────────┐
 │ agent A ─────┼──────▶ │  event intake         │
 │ agent B ─────┼──────▶ │    ↓                  │
 │ agent C ─────┼──────▶ │  triage + dedupe      │   ── scheduled brief ──▶  📄 daily digest
 │ agent D ─────┼──────▶ │    ↓                  │
 │ agent E ─────┼──────▶ │  interrupt budget     │   ── override channel ─▶  📱 push / SMS
 └──────┬───────┘        │    ↓                  │
        │                │  brief composer       │   ── voice briefing ───▶  📞 scheduled call
        │                └───────────┬───────────┘
        │                            │
        │                     approval ledger  ◀──── decisions ────────────────┘
        │                            │
        └──── resume(checkpoint) ◀───┘

Three rules hold the model together:

1. Workers never address the human. They emit typed events to the gateway and nothing else. No worker holds a channel to a person, and no worker can write to the override channel — urgency is requested by a worker and arbitrated by the gateway.
2. A worker that needs a decision parks. It checkpoints, emits an approval request, and exits. It does not sit spinning on a live context window for six hours waiting for an answer.
3. An approval binds to a specific proposed action, not to an agent. When the answer comes back, the gateway resumes from the checkpoint and re-verifies the world before executing. If the preconditions moved, the approval is void and the question gets asked again.

The documents

Document	What it covers
The model	Roles, the event taxonomy, triage, and the interrupt budget
State and resumption	Parking, checkpoints, the approval ledger, and why resumption is the hard part
Channels	The scheduled brief, the override channel, escalation policy, quiet hours
Transports	What to send it over — email providers, Telegram, Discord, push, voice — and why it's more than one
Voice briefing	The Twilio call: agenda freezing, spoken approvals, readback, post-call relay
Event contract	The wire format workers emit and the gateway consumes
Prior art	What already exists, what to steal, and where the actual gap is
Open questions	Decisions not yet made, and the ones I keep changing my mind about

Worked examples of the payloads and a rendered brief are in examples/.

What to call it

Not "human in the loop" — the human is not in the loop of any individual task. This is human supervisory control, or human-on-the-loop: an operator on the loop of a fleet, intermittently receiving information from processes that close their own loops.

More precisely, on Sheridan and Verplank's levels of automation it sits at level 5, management by consent — the machine proposes and acts only once the human agrees — and it refuses level 6, management by exception, where the machine acts unless vetoed in time. That refusal is rule 3 above, and the prior art explains why the literature is emphatic about it.

What this is not

• Not a work orchestrator. It does not decide which agent does what, split tasks or manage dependencies between them. Assume something else already does that. This orchestrates communication with the human, which is a separate concern that tends to get bolted onto work orchestration and done badly.
• Not a notification router. Routing moves a message to a channel. This holds messages back, merges them, drops the ones that resolved themselves before the brief went out, and spends a bounded number of interruptions per day.
• Not a framework. The model should survive whatever the workers are built on.

Roadmap

1. Model written down — this repo.
2. Event contract fixed, and one worker emitting real events into a file-backed queue.
3. Checkpoint/resume proven end to end on a single approval gate. This is the step that decides whether the rest is worth building.
4. Daily brief composed and delivered by email.
5. Override channel with the escalation policy enforced.
6. Voice briefing.

Licence

MIT — see LICENSE.