Agent Architecture Evolution: From Monolithic Self‑Management to Distributed Hosting

Agents are moving from proof‑of‑concept demos to large‑scale production. At this stage, engineering focus must go beyond workflow orchestration and prompt tuning to address deployment models, state management, security isolation, elastic scaling, and collaboration mechanisms that determine whether an Agent system can truly operate in production.

Why Agents Cannot Use Traditional Microservice Patterns

Monolithic Agents combine the Agent loop, conversation state, long‑term memory, tool environment, and deployment unit. Unlike ordinary web services, Agents are autonomous: they decide next steps based on model inference, leading to nondeterministic execution paths and breaking the usual idempotency assumptions. They also depend on tool environments, where installed software, service connections, and temporary files become part of the Agent’s state.

Three Forms of Monolithic Agents

Local deployment : Users install the Agent on a personal computer and connect it to enterprise chat tools. This approach is easy to start but tightly couples the Agent’s lifecycle to the device, scatters dependencies and credentials, and lacks centralized governance, making it unsuitable for enterprise‑scale use.

Kubernetes pod : Each Agent runs in its own pod with a PVC for state. This moves the Agent to the cloud and solves some deployment issues, but still treats the Agent as a single‑process workload. Security isolation is limited to container boundaries, resources may be wasted during idle periods, and scaling based solely on CPU/memory metrics does not reflect the true workload characteristics.

Runtime sandbox : A dedicated VM‑level sandbox provides millisecond cold start, on‑demand launch, and second‑level pause/resume, matching the bursty nature of Agent workloads. After task completion, compute resources are released while preserving necessary state. However, the sandbox still represents a single point of failure for upgrades, fault recovery, and high‑concurrency scaling.

Core of Distributed Agents: Split State Before Hosting

Transitioning to distributed Agents requires extracting state from the Agent loop. The article categorizes state into three types:

Session : The event sequence linking user, model, Agent, and tools.

Memory : Long‑term knowledge distilled from sessions and reusable across sessions.

Environment sandbox : The actual execution environment for tools.

Once these are externalized, the remaining Agent loop becomes stateless and can be scheduled, scaled, and upgraded like any ordinary service.

Remote Session storage enables high‑availability backup, TTL, rollback, and branching. Memory serves as a platform‑level data asset for downstream tasks, audit, and security triggers. The environment sandbox must support pause/resume, full‑disk snapshots, and binding to sessions or users, allowing both one‑off tasks and long‑running personal assistants.

From Function‑as‑a‑Service to Fully Managed ReAct

In the function‑as‑a‑service stage, developers submit only the loop’s main function. The platform handles Session lifecycle, sandbox scheduling, elastic scaling, cold start, logging, and gradual rollout, turning the development model into “write a business function”.

Fully managed ReAct removes the need to write a loop altogether. Developers declare a system prompt, skills, and MCP; the platform provides built‑in loop control, tool orchestration, context handling, error retry, and monitoring, turning the Agent into a configurable component rather than code.

The article summarizes hosting maturity in four stages: monolithic harness (full control by user), distributed harness (state externalized but user still manages services), function‑as‑a‑service harness (only brain function delivered), and fully managed harness (platform runs the entire runtime).

Multi‑Agent Collaboration: Registry and A2A Are Just the Start

When a single Agent is distributed, enterprises face new challenges: discovering other Agents with required capabilities, delegating tasks, and sharing context. Service discovery and A2A calls are addressed by an Agent Registry that registers Agents, MCPs, and HTTP services, enabling capability‑based lookup and unified invocation protocols. Context sharing across Agents remains an open infrastructure gap.

From Single‑Point Capability to a Complete Runtime

Tencent Cloud Agent Runtime provides an end‑to‑end system covering deployment, governance, evaluation, memory, identity, gateway, and collaboration. It consists of:

Agent Engine, Agent Govern, Agent Evals (deployment, ops, testing)

Agent Memory, Agent Registry, Agent Wall, Agent Sandbox, Agent Identity, Agent Gateway (state, security, execution, connectivity)

The sandbox layer further handles isolated execution environments, lifecycle management, multiple environment types, and elastic efficiency, illustrating that the Runtime solves not just a single execution problem but the full spectrum of production governance.

Conclusion

The evolution path can be summarized in three layers:

Path layer : Moving from monolithic self‑management to distributed hosting is essential for scaling Agents.

Physical layer : Compute‑storage separation and sandboxing split state, execution, and security into independently governable infrastructure.

Collaboration layer : Registry and A2A provide a common foundation for multi‑Agent discovery and invocation, while context sharing remains a future challenge.

Only when state can be migrated, environments isolated, permissions audited, and instances elastically scaled will Agents transition from demos to production‑grade services.