Coding Agents Escaped the IDE. Bring Them to Your App.

Connecting AG-UI to A2A with a serverless AWS bridge.

Coding agents escaped the IDE

Coding agents changed what it means to ask software for help. You delegate a goal, watch tools run, inspect progress, and steer the next step. The useful interaction is the work between the prompt and the answer.

Claude Code and Codex made this familiar to developers. Research, document preparation, and operational investigations need the same pattern. Bringing it into your application means letting people leave and return without losing the work while still having same form factor as existing CLI agents. So what does it mean to bring your agent CLI experience to thecloud?

Consider a simple journey: ask an agent to research options in Slack, open the linked conversation in Web, then request a deeper comparison. The new answer also appears in the original Slack thread. The surfaces change; the application conversation stays together.

Start with a research request in Slack, then ask a contextual follow-up in Web. Composite based on the supplied screenshots.

My Web + Slack reference implementation explores that experience. Its central design choice is to separate the lifetime of the interaction from the lifetime of the work. A closed browser tab should not accidentally become a cancellation command.

Why now?

Recreating this experience once meant building much of the agent runtime yourself. Durable managed runtimes can now own execution, tools, persistent history, and recovery. Applications can focus more on how people interact with that work.

Reusable boundaries help too: AG-UI for the interactive Web side, A2A for task-oriented communication. Meanwhile, users expect background work they can return to and steer across multiple surfaces.

The problem has shifted from “How do I build a long-running agent loop?” to “How do I make a durable agent feel native to my application?”

Interaction lifetime ≠ work lifetime

A Slack request needs an acknowledgment in seconds. A browser session is temporary. The research task may take twenty minutes. Tying execution to either connection makes leaving the app a threat to the work.

The central design choice is to separate the lifetime of the interaction from the lifetime of the work. A closed browser tab should not become a cancellation command.

The interaction bridge

An interaction bridge accepts user actions, connects them to durable work, and lets different surfaces observe or control it. Returning later reconnects the user to the conversation rather than starting again.

I use AG-UI to send Web runs and receive agent events, and A2A to expose a task-oriented boundary behind the bridge. Slack maps its native messages and threads into the same work model. Neither protocol supplies durability by itself.

AG-UI handles Web interaction; A2A represents work. This implementation supplies the A2A adapter to the managed runtime.

The bridge owns application identity, permissions, and routing; linked Web and Slack users must resolve to the same identity. The managed agent remains the source of truth for conversation history and execution. On reconnect, read current work and canonical history, rebuild the UI, and resume observation. A dropped stream does not mean work stopped; cancellation is explicit. **Streams are for liveness; durable state is for recovery.**

Ordinary follow-ups create new tasks in the same conversation. Human-input responses continue existing tasks, with controls depending on the surface.

How the implementation works

I run the bridge serverlessly on AWS. API Gateway and Lambda handle interactions. EventBridge and SQS decouple Slack input; task updates drive replies back to Slack. Aurora DSQL stores coordination metadata, while S3 holds pending inputs rather than a transcript.

Logical AWS paths, with related handlers grouped. Edge hosting, scheduler, webhook, and push-delivery details are omitted; the managed agent remains outside the AWS application boundary.

The Anthropic Managed Agents runtime owns the long-running execution, so a twenty-minute task need not keep an application worker alive for twenty minutes. Connected observers can still occupy Lambda invocations. The useful property is a lightweight application layer around durable work; another cloud or runtime could support the same design.

When this architecture is useful

If the agent responds in five seconds and the user stays on the page, normal request/response is simpler. This architecture helps when work outlives interactions, users leave or switch surfaces, work pauses for human input, retries must avoid duplicate work, or connections fail during execution.

Conclusion

Claude Code and Codex made starting work, returning later, and continuing to steer it familiar. Bringing that experience into your application means giving interaction and execution different lifetimes.

Slack and Web become ways to observe and steer durable work. Protocols and cloud services support that idea; the durable interaction model is what users experience.

Your agent is async. Your UX doesn’t have to feel like it.