# Don't Deploy Another Agent. Give It Somewhere to Live > The agentic shift does not end software engineering. It moves repeated engineering into a governed platform where agents can be configured, operated, evaluated, and evolved as capabilities rather than separate deployments. - Author: Kostas Karolemeas - Published: 2026-09-01 - Topics: agentic AI, Gaia, AI platforms, AI engineering, enterprise AI - Canonical URL: [https://www.voxelperfect.com/writing/dont-deploy-another-agent-give-it-somewhere-to-live](https://www.voxelperfect.com/writing/dont-deploy-another-agent-give-it-somewhere-to-live) I keep seeing teams build every AI agent as a miniature software project. Choose a framework. Write orchestration code. Connect a model, tools, memory, and data. Package the runtime. Deploy it somewhere. Add tracing, evaluations, permissions, and governance when the prototype becomes important. Then repeat the exercise for the next agent. A paper circulating this week gives that pattern a provocative challenge. [_The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm_](https://arxiv.org/html/2606.05608v1) argues that the agent becomes the software. Code changes from the permanent carrier of human-written decision logic into a temporary instrument generated or invoked by a model as it works toward an outcome. I do not believe software engineering is ending. The paper's title runs ahead of both its evidence and the systems we can reliably operate today. But it points toward a real architectural shift. If the agent is becoming the operational capability, why do we still deploy every agent as another standalone application? My answer from building Gaia is increasingly direct: **Do not deploy another agent. Give it somewhere to live.** ## The agent is dynamic. Its environment must be durable. The paper defines an agent through a model, tools, memory, and a planning mechanism. That is consistent with the lineage of systems such as [ReAct](https://arxiv.org/abs/2210.03629), which interleaves reasoning with actions against external environments. Those ingredients explain how an agent can act. They do not, by themselves, make it an operable application. An enterprise still needs to know what the agent is for, which tools and data it may use, which model should handle each task, how state persists, where people intervene, how quality is evaluated, who can change the system, and what evidence supports a release decision. It needs logs, access control, cost visibility, incident handling, and a controlled way to improve behavior without losing accountability. When every agent is its own project, each team has to assemble that environment again. The reusable parts become local code, infrastructure, conventions, and glue. A successful prototype therefore creates a second project: constructing the operating system around it. The alternative is to make the environment the durable product. Inside Gaia, an agent is not primarily a repository waiting to become a service. Teams define its purpose, persona, instructions, model choices, tools, context, workflows, channels, permissions, and evaluation criteria inside a shared governed platform. Gaia provides the runtime in which those definitions execute and the lifecycle through which they are observed, evaluated, released, and changed. The agent can remain dynamic because the environment around it is stable enough to govern. ## “No code” is not the important claim It would be easy to describe this as no-code agent building. That would undersell the change and overstate the disappearance of engineering. There is still code. Gaia itself is engineered software. Models execute code and call APIs. Some integrations require custom implementation. Complex applications still need architecture, data contracts, security decisions, interface design, and rigorous testing. What changes is **where repeated engineering lives**. Application teams should not have to write a new orchestration layer, deployment unit, evaluation harness, audit trail, permission model, and operational dashboard for every agent. Those are platform responsibilities. Once they become shared capabilities, a team can spend more of its effort specifying the work and less of it rebuilding the machinery that lets the work run safely. The same precision applies to deployment. Gaia has to run somewhere, and it can coordinate external services. But an individual agent does not need to become another independently packaged service with its own operational stack. It lives as a governed capability inside Gaia's runtime. That is closer to the shift I see than “agents eliminate software.” The platform absorbs the software concerns that should not be reinvented per agent. ![An agent lives inside Gaia's governed runtime with shared tools, context, workflows, evaluation, and governance.](/writing/dont-deploy-another-agent-give-it-somewhere-to-live-linkedin-governed-runtime.png) _The operating model: configure the agent inside a shared governed runtime instead of deploying another standalone agent stack._ ## An AI application is more than an agent The agent is also not the entire application. A useful enterprise AI application may need a conversation workspace, editable artifacts, shared document folders, search and retrieval, graph-based workflows, human checkpoints, evaluation datasets, delivery tasks, and governance evidence. It may combine several agents or use an agent for only one part of the experience. This is why Gaia is designed as more than an agent builder. Its [platform model](https://thegaia.ai/platform) keeps runtime orchestration, document work, workflow topology, evaluation, governance, and delivery evidence inside one control plane. Its [application blueprints](https://thegaia.ai/applications) show how customer experience, research, document workflows, education, and enterprise workspaces can inherit the same operating surfaces without rebuilding the stack for each use case. That changes the unit of reuse. A team does not begin with an empty repository and a list of libraries. It begins with platform building blocks and an operating model. An agent can use approved tools and document context. A workflow can combine agents, branches, loops, and human approval. An evaluation can remain connected to the configuration and release it informs. Governance does not have to reconstruct what happened from logs scattered across several products. The deliverable becomes a working capability inside a shared system, not an isolated agent plus a collection of promises about what will be added later. ## The engineering moves up a level The paper describes a future role for people as intent architects, coordinators, and outcome auditors. I agree with the direction, but those titles can sound lighter than the work actually is. Specifying intent means defining boundaries, not merely writing a good prompt. Coordination means designing state, authority, failure handling, and handoffs. Auditing outcomes means creating evaluation signals that can distinguish a plausible answer from a dependable result. Gaia's [delivery process](https://thegaia.ai/process) makes those responsibilities explicit across planning, exploration, development, and evaluation. Teams define purpose and success criteria, select data and tools, shape agent behavior and interaction, then test the system against functional, operational, governance, and safety expectations. That is engineering. The center of gravity has moved from encoding every decision path in application code toward designing the conditions under which a reasoning system may act. The distinction matters because today's agents are not reliable enough to justify hand-waving away the surrounding discipline. The same “end of software engineering” paper cites [EvoClaw](https://arxiv.org/abs/2603.13428), a benchmark in which performance fell from above 80% on isolated tasks to at most 38% in continuous software-evolution settings. Long-running work exposes context drift, accumulated errors, weak technical-debt awareness, and incomplete verification. That evidence does not weaken the platform argument. It strengthens it. When agent behavior evolves at runtime and small failures can compound, we need more continuity between configuration, execution, evaluation, evidence, and change control. A standalone deployment boundary gives us a place to run code. It does not automatically give us a way to govern a living capability. ## A practical test for an agent platform The easiest way to evaluate this architecture is to ask what has to be rebuilt for the second agent. Does the team need another service, another tracing setup, another permission scheme, another evaluation tool, another dashboard, and another release process? Do the controls apply consistently across models and workflows, or are they conventions every project must remember to reproduce? Can a reviewer move from an agent's purpose to its runtime evidence and evaluation history without reconstructing the system from several products? If most of the operating model begins again with each use case, the organization has an agent collection, not an agent platform. The stronger model is cumulative. Every new tool integration, evaluation pattern, workflow component, governance control, and delivery template should make the next AI application easier to build and safer to operate. The platform becomes organizational memory expressed as reusable capability. That is the opportunity I see in Gaia. We do not need to pretend that code has vanished. We need to stop making every agent carry its own version of the same engineering. The agent should be free to reason, use tools, and adapt within its scope. The platform should provide the durable place where its purpose, authority, context, evidence, and evolution remain legible. Do not deploy another agent as a miniature software project. Give it somewhere to live. ## Sources - Zhenfeng Cao, [_The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm_](https://arxiv.org/html/2606.05608v1), 2026: the preprint's agent-as-software thesis, agent model, proposed engineering shift, and stated limitations. - Shunyu Yao and colleagues, [_ReAct: Synergizing Reasoning and Acting in Language Models_](https://arxiv.org/abs/2210.03629), ICLR 2023: the foundational reasoning-and-action pattern discussed in the article. - Gangda Deng and colleagues, [_EvoClaw: Evaluating AI Agents on Continuous Software Evolution_](https://arxiv.org/abs/2603.13428), 2026: evidence on the performance gap between isolated and continuous agent work. - Gaia's [platform overview](https://thegaia.ai/platform), [application blueprints](https://thegaia.ai/applications), and [delivery process](https://thegaia.ai/process): the public product model and operating capabilities described here.