Adding email as the front door to our patent agent.

We build an AI agent for European patent work, and the interface we built for our users to actually talk to it is email. They send a message to a dedicated address, attach the documents their patent process already produced — an examination report from the EPO, a draft set of claims, the prior art the examiner cited — and the agent reads the message, runs its workflow, and replies in the same thread. This post is about how we wired that channel using the Podesta SDKs, and why email turned out to be a much better answer than the dashboard we briefly considered building instead.

Why email.

Patent attorneys live in email. Every document they reason against arrives there already — from the EPO, from their clients, from their own colleagues drafting in parallel. A separate dashboard would have asked them to download an attachment from one inbox, log into a new tool, upload the attachment there, and read the response in a different window. Three operations added to a workflow that did not need any of them. Forwarding the email they were going to forward anyway adds zero.

The second reason became clear once we shipped: email already has the conversational primitives we needed — threads to maintain context, replies to preserve intent, attachments as the obvious surface for documents. The work, in the end, was writing a parser for a format the user already knew, not designing a UI.

What the channel does end to end.

A message arrives at our inbound address. A small Rust service receives it, parses the MIME envelope, and extracts attachments. PDFs go through Podesta's document ingestion — the same path Studio uses for documents uploaded into the editor — and come back as structured markdown the workflow can reason against. The message body and metadata are normalised into the inputs the Akribes workflow expects.

The workflow itself is the same composite Akribes script that powers every other piece of our agent's reasoning: classification of what the user is asking for, the legal analysis appropriate to that classification, and the assembly of a structured response. None of that changes when the input arrives over email instead of over some hypothetical API.

The result comes back as a structured object — typed response sections, citations, any uncertainties the workflow flagged. The service renders that into a readable HTML reply, sends it from the address the user originally wrote to, and uses the standard mail-threading headers to keep the reply in the conversation the user started.

What the Podesta SDKs did the work of.

Almost everything that is not email-specific.

• The agent itself. The Akribes script that handles the reasoning is the same script every other front-door of our product calls. We never maintained a second copy of any prompt, any sub-workflow, or any provider configuration.
• Document ingestion. Patent attachments are PDFs, often hundreds of pages, often with figures that matter for the analysis. Podesta's document conversion is a VLM-based PDF-to-markdown pipeline we plugged into with a single SDK call; we never assembled our own OCR, layout analysis, or structure recognition. The same call handles .docx and .html for the messages that arrive in those shapes.
• Streaming execution. Workflow events stream through the SDK in real time. The email channel does not render a progress bar — there is no progress bar in an email — but we hook the event stream for structured logging, partial-result handling, and the long-running-job monitoring that would otherwise mean polling.
• Auth and audit. Every email-driven workflow run carries the inbound sender as the user identity in our metrics, via a short-lived scoped token the SDK mints per request. Per-customer cost accounting, per-customer rate limits, and a clean offboarding path all fall out of that — none of which we built the underlying infrastructure for.

What we did write.

The service is the mail-specific glue: MIME parsing edge cases, address normalisation, the threading-header dance, attachment deduplication, sender allow-listing per customer, and the rendering layer that turns a structured workflow output into a readable HTML email. None of that is AI work. The agent itself, the document conversion, the workflow engine, the streaming protocol, the auth model, the cost accounting, the eval harness that scores changes to the underlying agent — those were all on the platform side of the line.

The detail that mattered most to adoption.

The single channel-side decision that did the most for how users took to the system was replying from the address the user wrote to rather than from a single canonical agent address. Patent firms typically write to whichever address lives in the email signature of the colleague who last forwarded them something, or to an alias that maps to a particular case. The expectation is that the response comes back from the same place; threading depends on it, and so does intent. A reply from a single canonical address reads as a system. A reply from the address the user actually wrote to reads as a continuation of the thread they started. The Akribes workflow does not care which it is; the channel does. The difference in how users responded to the version that got this right was disproportionate to the size of the code change.

What it took to make production-grade.

The interesting work, after the integration itself, was the boring kind:

• Idempotency on retries. SMTP retries silently; the same message can land twice. We dedupe on message-id with a small window.
• Quotas per customer. A token attached to a customer means the rate limit is per customer; deciding what limits to set was its own conversation.
• Failure paths that say something useful. When the workflow runs out of budget, or a document fails to convert, or the message body is empty, the user gets a reply that explains what to fix — not silence and not a stack trace.
• A replay log. Every inbound message and every outbound reply is archived in a form that lets us replay it through a newer version of the workflow when the agent improves. That replay surface turned out to be the most valuable artefact the channel produced, because it gives us a real corpus of customer cases to regression-test against without ever touching a customer's mailbox.

Close.

We picked Podesta so that our engineering effort could go to legal reasoning rather than to workflow orchestration and document conversion. The email channel is a concrete instance of that bet paying off: a usable front door for our users, shipped with most of our engineering still pointed at the patent-law work we are actually trying to be good at.