Seam AI is an Account based marketing platform that automates sales workflows through AI agents. When I joined, these agents were separate tools. Each one solved part of the problem—finding companies, prospecting contacts, enriching data—but users had to manually stitch them together.

Confirmation bias crept in with no feedback loop to prove or disprove it. Static human judgment was the ceiling. Stitch is the agentic layer that runs the work automatically. One agent. Prospect. Draft. Send. Learn.

Two halves and a loop between them. The frontend listens to a live event stream from one managed agent session per job — that's the agent backend, living on the model provider's infrastructure. User actions become events into the session. Tool calls become UI surfaces.

The Stitch server in the middle is a thin proxy: it holds credentials, forwards events, enforces the tool taxonomy. Most endpoints are five or ten lines.

Before I wrote a single production component, I built a 400-line local prototype and lived in it for a few days. Three tabs: a chat window, an agent-config tab, and an MCP/skills tab. The whole point was to validate the agent's behavior before committing to a UI. I needed to know — could I enforce plan-before-act with prompting alone? Would the agent learn from my edits silently? Could I make it tell the difference between "find me new contacts" and "look up someone we know"?

I designed and shipped the entire production app solo, in roughly a week, using AI coding tools. I then dogfooded it by running real outbound campaigns through it myself, which is also how every interaction pattern got pressure-tested. Once the agent was proven in Phase Zero, production design split into five big bet:

The naive answer to "how do you make an autonomous agent feel safe" is plan-before-act. Have the agent propose what it'll do, let the user approve, then execute. But it's not the whole story. A product that asks for permission once and then disappears for 30 days fails the same trust test as one that doesn't ask at all. So I built control into every moment the user might want it.

• Pre-flight — the plan card. Structured. Approve / Edit / Reject. Revisions stack.
• In-flight — the intervention bar. Pause, Stop, or steer with a free-form Guide text area.
• Per-action — irreversible writes always need a confirmation.
• Per-artifact — every draft, plan, audience is editable.
• Structural — permission policy at the MCP layer.

Every AI product right now has a personalization wizard. "Describe your tone in 3–5 sentences." I deleted mine. Wizards produce aspirations, not working models — what the user thinks they want, not what they actually edit when they see a real draft. So I made every surface in Stitch a training interface instead. Every approval, every edit, every audience tweak, every sidebar question — they all write silently to one central memory file.

The user never declares their tone. They edit a few drafts, and the agent adopts the voice. They never declare their ICP. They tweak a few audience filters, and the agent narrows. The personalization is the work.

Every other AI product looks the same: one infinite chat thread. That shape works when the task is "answer my question right now." It breaks when the task is "run a 30-day campaign across 150 contacts." So I designed the interface as a state machine, not a chat log.

UI reflects the structure of the business workflow, and the behavior of agent is confined to them - each state gets its own UI shape:

​

• Information intake → structured form
• Proposing a plan → a single deliberate card
• Executing → a status pill + a calm narration thread
• Drafts pending review → a triage queue
• Sending → a live metrics surface
• Complete → an explorable results region

GTM tools have bimodal users — a salesperson who just wants the answer, and a RevOps operator who wants the audit trail. The easy mistake is forking into a "simple" mode and an "advanced" mode. I refused that.

Instead, depth lives behind one button: Observe. A new user sees a clean working pane. A power user clicks Observe and a side panel slides out with the raw event log and a separate read-only sidebar called Ask Stitch, which draws from session history, is read only, and does not interrupt the workflow (inspired by claude /btw and claude-assisted editing and managed session debugging on Claude console.)

This one's more architectural than visual, but it's the bet that makes everything else hold together.

Every operation in Stitch that needs reasoning, tool use, or memory access runs as a managed agent session — not as an ad-hoc LLM call. Foreground jobs are sessions. Background knowledge refreshes are sessions. Sidebar memory writes go through session-attached tools. The dashboard reads live session state instead of querying a jobs table.