Triggering Agents from Anywhere
Introduction: Triggering Agents from Anywhere
Throughout this course, you have built a complete REST API that launches, pauses, resumes, and collaborates with AI agents. You implemented persistent storage, lifecycle control, and human-in-the-loop workflows. In this final lesson, you will see all that work pay off by connecting a web-based user interface to your existing API — without changing a single line of backend code.
This demonstrates Factor 11 (Trigger from anywhere, meet users where they are). The principle states that well-designed agent APIs should work with any client interface. Whether your users prefer a command-line tool, a mobile app, a Slack bot, or a web dashboard, the same agent logic serves them all. You will watch a web UI solve a practical problem by calling the exact endpoints you have already built.
The 12-Factor Agents Methodology Recap
Before diving into the demonstration, let's review the complete 12-Factor Agents methodology. These principles guided every decision you made throughout this journey:
| Factor | Name | Description |
|---|---|---|
| 1 | Natural Language to Tool Calls | Agents translate user intent into structured tool invocations |
| 2 | Own Your Prompts | Keep prompts in version-controlled files you can edit and test |
| 3 | Own Your Context Window | Manage what goes into the context explicitly rather than relying on frameworks |
| 4 | Tools Are Just Structured Outputs | Tool calls are data structures the agent produces, not magic |
| 5 | Unify Execution State and Business State | Store agent progress in the same database as your application data |
| 6 | Launch/Pause/Resume with Simple APIs | Expose lifecycle control through standard REST endpoints |
| 7 | Contact Humans with Tool Calls | Treat human escalation as a first-class tool the agent can invoke |
| 8 | Own Your Control Flow | Write explicit loops and conditionals rather than hiding them in abstractions |
| 9 | Compact Errors into Context Window | Feed errors back to the agent as context so it can recover |
| 10 | Small, Focused Agents | Build agents that do one thing well instead of trying to handle everything |
| 11 | Trigger from Anywhere | Design APIs that any client can call, meeting users where they are |
| 12 | Make Your Agent a Stateless Reducer | Each step takes state in, produces new state out, with no hidden side effects |
Throughout this learning path, you have implemented all twelve factors of the 12-Factor Agents methodology.
Seeing Your Agent in Action
Now let's see everything you've built in action. We've created a simple web client that interacts with your REST API through the same endpoints you've been using all along. No special backend code. No modifications to your infrastructure. Just a clean, user-friendly interface calling the /agent/launch, /agent/state/{id}, /agent/pause, /agent/resume, and /agent/provide_input endpoints you designed.
Watch as this client sends a real garden-planning problem to your agent:
In this demonstration, you'll see the complete workflow unfold: the agent launches with a prompt about planning a rectangular garden bed. As it processes the problem, it realizes it needs additional information and invokes the ask_human tool, which automatically pauses the workflow. The web UI displays the agent's question to the user. The user provides the missing information, and the existing agent run resumes execution with that data. During processing, we demonstrate the pause/resume capability by manually pausing the execution mid-workflow using the /agent/pause endpoint, showing that you have complete control over agent execution at any moment. We then call the /agent/resume endpoint to continue execution, and the agent completes its work, with the final result appearing in the UI. From the agent's perspective, it doesn't matter whether the request came from a web browser, a Python script, or a mobile app. The API treats every client the same way.
