Thanks to visit codestin.com
Credit goes to github.com

Skip to content

docs(email): partner-facing Capability & API Spec (v2.0)#1619

Merged
itomek merged 7 commits into
mainfrom
docs/email-spec-v2
Jun 12, 2026
Merged

docs(email): partner-facing Capability & API Spec (v2.0)#1619
itomek merged 7 commits into
mainfrom
docs/email-spec-v2

Conversation

@kovtcharov-amd

@kovtcharov-amd kovtcharov-amd commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

Why this matters

Software partners integrating the Email Triage Agent — and our own eval engineers — had no single reference for what the agent does, how to call it, and how to generate test data. This adds a self-contained spec covering all 12 shipped/wired capabilities plus 5 planned, the three-tier guardrail model (when the user is asked to approve), ten end-to-end multi-capability workflows, the three integration surfaces (REST / MCP / full agent), a consolidated error model, and an evaluation & synthetic-data format grounded in the labelled mailbox corpus.

It also documents the proposed schema 2.0 taxonomy change — 4-bucket → 5-bucket (URGENT · NEEDS_RESPONSE · FYI · PROMOTIONAL · PERSONAL) plus a suggested_action verb, retaining the independent is_spam / is_phishing flags — tracked in #1615. Today's shipped contract (schema 1.0) is clearly marked as current.

Notes

  • Single self-contained file (fonts inlined) — opens in any browser, light/dark toggle, collapsible navigation, in-text endpoint links.
  • Lives alongside the email agent package at hub/agents/python/email/specification.html.

Test plan

Self-contained HTML spec for the Email Triage Agent: the 12 shipped/wired capabilities plus 5 planned, the three-tier guardrail model, common workflows, the three integration surfaces (REST / MCP / full agent), a consolidated error model, and an evaluation & synthetic-data format grounded in the labelled mailbox corpus. Documents the schema-1.0 contract plus the proposed schema-2.0 taxonomy (#1615). For software-partner integration and test/eval data generation.
@github-actions

Copy link
Copy Markdown
Contributor

Review — docs(email): partner-facing Capability & API Spec (v2.0)

Approve with suggestions. This is a genuinely strong partner-facing artifact and every contract claim I spot-checked against the code is accurate. The blocking-level concern is long-term drift: a 256 KB hand-authored static spec re-states a contract that the repo already auto-generates from the pydantic models. Nothing here must change to merge, but a few small fixes and one structural decision are worth making now.

No security issues. No prompt-injection content — the file's "untrusted email body" discussion is legitimate subject matter, not an instruction to the reviewer.

Verified accurate against the code

  • EmailCategory buckets {urgent, actionable, informational, low priority}src/gaia/agents/email/contract.py:47
  • schema_version default "1.0"contract.py:59
  • Status codes 403 / 422 / 502 / 503 all exist and match their described triggers — src/gaia/api/email_routes.py
  • Endpoint paths /v1/email/{triage,draft,send} and the draft→token→send gate — email_routes.py:73,547
  • Corpus tally: 863 + 605 + 169 + 165 + 35 = 1,837

Issues

🟡 Important — the contract reference will silently drift from the code

The repo already has src/gaia/agents/email/spec_html.py (#1263), which renders the endpoint spec by deriving field rows directly from the contract pydantic models "so the spec stays in sync with the contract automatically." This new file re-documents the same contract (EmailTriageRequest/Response, EmailAddress, EmailMessage, status codes, the Part 4 field tables) by hand, in static HTML. The moment contract.py changes, the hand-authored Part 4 is wrong and nothing flags it.

The file's own footer is honest about this ("The contract reference reflects the current schema 1.0 models…"), which is good — but honesty doesn't prevent the drift. This is the one thing worth deciding before this becomes the partner-facing reference:

  • Preferred: generate the Part 4 contract section from the models (extend spec_html.py) and hand-author only the capability / guardrail / workflow / eval narrative around it. That keeps the auto-sync guarantee feat(email): browser-openable HTML endpoint spec #1263 was built for.
  • Minimum: add a test or CI check that fails when contract.py's public fields change without this file being regenerated, so the drift is caught rather than discovered by a partner.

Not a merge blocker for a doc, but please file/track it — a wrong contract table in a partner spec is costlier than a wrong sentence in a guide.

🟢 Minor — both "Source of truth" footer links 404 today

The footer links point to hub/agents/python/email/gaia_agent_email/contract.py and …/api_routes.py — the post-#1102-migration destination, which doesn't exist yet (hub/agents/python/email/ currently holds only this HTML). Both links are dead on main right now, and the route file is named email_routes.py, not api_routes.py. Until #1102 lands, point them at the live files:

  • src/gaia/agents/email/contract.py
  • src/gaia/api/email_routes.py

🟢 Minor — headline stat tiles don't reconcile

The summary tiles read 17 Capabilities · 4 Completed · 12 In progress · 9 Planned · 3 Approval tiers. 4 + 12 + 9 = 25, not 17, and "9 Planned" contradicts the copy elsewhere ("5 more are planned (13–17)" and the at-a-glance "6 planned features"). If the tiles intentionally fold personalization (P1–P5) into the counts, that's not obvious to a reader doing the arithmetic. Please reconcile the numbers or label what each tile counts.

🟢 Minor — placement / discoverability

Raw HTML in a hub package dir (rather than MDX under docs/ + a docs.json entry) is a deliberate, reasonable call for a self-contained partner handout, and the PR explains it. Flagging only that nothing references the file today — if partners or eval engineers are meant to find it, add a pointer from docs/guides/email.mdx or the hub README so it isn't an orphan.

Strengths

  • Accurate where it counts — the contract, status codes, taxonomy, and endpoint behaviour all match the implementation, not a guess at it.
  • Honest status taxonomy — every capability is tagged validated / wired / planned, and the footer cleanly separates "shipped schema 1.0" from "proposed schema 2.0" and "intended behaviour." That candor is exactly right for a partner doc and avoids overselling wired-but-untested paths.
  • Self-contained and well-built — fonts inlined, light/dark, collapsible nav, in-text endpoint links; opens anywhere with no build step. The eval/synthetic-data section grounded in the real labelled corpus is a useful bonus for integrators.

Verdict

Approve with suggestions. Safe to merge as documentation. Please (1) fix the two dead footer links and the route filename, (2) reconcile the headline counts, and (3) track the contract-drift concern — ideally by generating Part 4 from the models the way spec_html.py already does, so this spec inherits the auto-sync guarantee instead of diverging from it.

itomek
itomek previously approved these changes Jun 11, 2026
Renames the partner-facing spec to specification.html and adds five end-to-end workflows — including a multi-round meeting-time negotiation (propose → counter → re-check → confirm), a search-driven find-and-act, commitment tracking, a prioritization-learning loop, and an attachment-aware reply.
Ovtcharov added 5 commits June 11, 2026 16:40
…the full spec

Reframes the Evaluation section to specify the dataset a complete test/eval/optimization run needs — required fixture format, must-include coverage, and what a triage-only corpus is missing — rather than describing a specific example corpus. Aligns it with the rest of the spec: schema 2.0 native taxonomy, all 17 capabilities, the 10 workflows, the REST/MCP/agent surfaces, and the error model.
Replaces the prose coverage notes with two concrete fixture shapes — a per-message expected block and a chained scenario fixture (multi-turn, e.g. the W6 scheduling negotiation) — and a coverage matrix mapping all 17 capabilities, P1-P5, and W1-W10 to their fixture type and validating assertion, so the dataset can validate the full agent including chained workflows.
…uarantine (zero-confirm)

Workflows W1-W10 are now collapsible, each with a one-line scenario blurb that stays visible when collapsed. Phishing handling moves from confirm-gated quarantine to spam-style auto-quarantine: detected phishing is auto-moved to the quarantine label, the user is notified (no prompt), and can review/unmark a false positive at any time. Updated capabilities 4 and 9, the guardrail tiers (quarantine Tier 2 -> Tier 1), the at-a-glance table, workflows W1/W4, the coverage matrix, and the hard-fail invariants.
…ing, unattended guardrails)

New section covering how the email agent runs unattended: time/event/user triggers, the THINK->ACT->SCHEDULE self-scheduling loop, human-readable schedule format with persistence, and the unattended guardrail rule — Tier 0/1 run automatically (auto-quarantine notifies + reverses) while Tier 2 actions queue for approval and never auto-fire. Marked planned (autonomy engine #555). Wired into the nav + coverage matrix.
@itomek itomek added this pull request to the merge queue Jun 12, 2026
Merged via the queue into main with commit 9ab7da1 Jun 12, 2026
41 checks passed
@itomek itomek deleted the docs/email-spec-v2 branch June 12, 2026 13:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants