Agent Stitch

Solo designed and built the company’s ABM agent on Claude Managed Agents. I led decisions end-to-end across product infrastructure—system prompt, per-tenant memory, and skills—to shape the agent’s behavior, while also defining the core user experience for a non-chat agent interface.

An agent backend that reads from and writes to the frontend

The system has two halves and a loop between them. The frontend listens to a live event stream from one managed-agent session per job. User actions become events into the session, and tool calls become UI surfaces.

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

Trust, feedback, state, depth, and centerpiece

I designed and shipped the production app solo in roughly a week using AI coding tools, then dogfooded it by running real outbound campaigns through it myself. Once the agent was proven in phase zero, the production design split into five big bets.

Trust through layered control

The naive answer to making an autonomous agent feel safe is plan-before-act: propose a plan, let the user approve it, then execute. But a product that asks permission once and disappears for 30 days fails the same trust test as one that never asks. I built control into every moment the user might want it.

Pre-flight used a structured plan card with approve, edit, and reject actions. In flight, an intervention bar let users pause, stop, or guide the agent. Irreversible writes required confirmation, every artifact remained editable, and permission policy was enforced at the MCP layer.

Interacting with the UI is the feedback loop

Most AI products start with a personalization wizard: “Describe your tone in three to five sentences.” I deleted mine. Wizards produce aspirations, not working models—what users think they want rather than what they actually edit when they see a real draft.

Every surface in Stitch became a training interface. Approvals, edits, audience tweaks, and sidebar questions all write silently to one central memory file. Users never declare their tone or ICP; they edit real work, and the agent adapts. The personalization is the work.

State, not stream

An infinite chat thread works when the task is “answer my question right now.” It breaks when the task is “run a 30-day campaign across 150 contacts.” I designed the interface as a state machine, not a chat log.

The UI reflects the structure of the business workflow, and the agent’s behavior is confined to those states. Information intake becomes a structured form; a proposed plan becomes one deliberate card; execution becomes a status pill and calm narration; draft review becomes a triage queue; sending becomes live metrics; and completion becomes an explorable results region.

Progressive disclosure instead of separate modes

GTM tools have bimodal users: a salesperson who wants the answer and a RevOps operator who wants the audit trail. The easy mistake is splitting the product into a simple mode and an advanced mode. I refused that fork.

Depth lives behind one button: Observe. A new user sees a clean working pane. A power user opens a side panel with the raw event log and a read-only Ask Stitch sidebar that draws from session history without interrupting the workflow.

Every action is a managed session

This decision is more architectural than visual, but it makes everything else hold together. Every operation that needs reasoning, tool use, or memory access runs as a managed-agent session rather than 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.

From intelligence platform to intelligence that acts

Stitch drove approximately $300K in sales pipeline during the demo stage. It also shifted Seam’s positioning from an “intelligence platform” to “intelligence that acts.”

The product made the agent’s autonomy legible without reducing it to chat. Users could understand the plan, intervene while work was running, train the system through normal interaction, and inspect as much depth as their role required.