--- title: "AI agent deployment modalities · embedded, standalone, headless · Agent Fieldbook" url: https://agentfieldbook.org/catalog/modalities/ description: "Where an AI agent runs decides who controls its data, cost and reach. The four deployment modalities as an arc from human-mediated to headless, where the API is the UI and SaaS products become substrates other agents drive directly. Each modality defined, exampled and sourced." section: "Catalogue · Modalities" source: Agent Fieldbook — generated from the published page --- # The four modalities of deployment **Where an agent runs determines who controls its data, cost and reach.** The Fieldbook tracks four deployment modalities, local, cloud, caged and headless, to show how the environment around an agent shapes its practical capabilities and constraints. The agent runs entirely on the user's own hardware: full data control, no egress, capped by local compute. - [↗ source · confirmed](https://github.com/ollama/ollama) The agent runs on managed infrastructure: serverless, sandboxed containers, or a fully managed platform. - [↗ source · confirmed](https://developers.cloudflare.com/workers-ai/) An agent locked inside one vendor's product surface: usable only through that vendor's UI, not callable as an external agent. The platform lock-in problem. - [↗ source · research](https://www.salesforce.com/agentforce/) Agent-first: the product is exposed as an API with no required UI: "the API is the UI." Other agents can drive it directly. - [↗ source · confirmed](https://www.salesforce.com/news/) ## Field notes Where an agent runs sets who controls its data, cost and reach **Deployment is an architectural decision, not an implementation detail.** **Local** agents run on an individual's device, keeping the person close to the work and its controls. **Cloud** agents run as managed services, with providers operating the infrastructure and inference. **Caged** or vendor-locked agents are contained within a vendor's product surface. **Headless** agents run without a browser, operating through services, tools and APIs. **Autonomy changes the deployment model.** Today 96 of 103 catalogued agents are cloud-deployed and only one is headless, which shows how early that shift still is. Manual agents are productive but they pause when the operator does: run under close supervision from a laptop and the work stops when the person steps away. Cloud and headless architectures make longer-running, less supervised execution possible. A useful rule of thumb is that supervised agents run locally or within a platform, while unsupervised work moves to the cloud or goes headless. The transition should be intentional, because greater autonomy needs stronger trust, clearer permissions and governance that matches the consequences of the work. - [Brandon Chaplin](https://www.linkedin.com/in/brandon-chaplin-digital-marketing-strategist) ## Common questions ### What is a headless AI agent? An agent with no interface of its own, driven by other software through an API instead of a person clicking a screen. It is how agents get called by a backend service, a scheduled job or another agent. ### Where do AI agents run? Four places, in practice: on a local machine, as a cloud service, inside a vendor’s product, or headless behind an API. Almost everything in production today is cloud-hosted, because the work needs to carry on when nobody is watching. ### Should an AI agent run locally or in the cloud? Locally when the data must not leave the machine or you want to supervise each step. In the cloud when the task is long-running or has to continue unattended. A local agent stops when the person does, which is the limit most teams hit first. ### Can I run an AI agent on my own computer? Yes. Agent frameworks run fine on a laptop and can call either a hosted model API or a local open-weights model. Running the model locally as well needs a lot of memory and a capable GPU, and it will be slower than a hosted equivalent. ### What is vendor lock-in with AI agents? When an agent only runs inside one company’s product, on that company’s models, data and pricing. It is convenient and awkward to leave, because the prompts, tools and integrations rarely move to another vendor without being rewritten. ## Next in the learning path - [Agent vs operator The lens the whole catalogue is classified by](https://agentfieldbook.org/catalog/agency/) - [Agent platforms The substrates agents are deployed on](https://agentfieldbook.org/catalog/platforms/) - [Agent topologies How the parts inside a modality coordinate](https://agentfieldbook.org/design/topologies/) - [Agent APIs The interface a headless agent is driven through](https://agentfieldbook.org/developers/api/) ## Entries _4 entries listed on this page._ | name | description | subjectOf | | --- | --- | --- | | Local | The agent runs entirely on the user's own hardware: full data control, no egress, capped by local compute. | https://github.com/ollama/ollama | | Cloud | The agent runs on managed infrastructure: serverless, sandboxed containers, or a fully managed platform. | https://developers.cloudflare.com/workers-ai/ | | Caged | An agent locked inside one vendor's product surface: usable only through that vendor's UI, not callable as an external agent. The platform lock-in problem. | https://www.salesforce.com/agentforce/ | | Headless | Agent-first: the product is exposed as an API with no required UI: "the API is the UI." Other agents can drive it directly. | https://www.salesforce.com/news/ |