--- title: "Managed Agent Platform: Production Infrastructure for Configurable AI Agents" description: "Managed Agent Platform is the self-hosted agent infrastructure I am building as one product: a Deep Agents runtime on a self-hosted Agent Protocol server where a new assistant is a stored configuration rather than a new codebase — isolated code sandboxes, credential injection kept outside the agent's reach, per-tool approval gates, model providers switchable without a redeploy, and a control plane for multi-tenant governance, all in active development." date: "2026-06-17T07:00:00Z" last_updated: "2026-08-28" build_time: "2026-08-28T03:11:43Z" project_name: "Managed Agent Platform" project_description: "A self-hosted platform for running AI agents in production rather than as one-off scripts, in active development as one product: a configurable Deep Agents runtime where a new assistant is a stored configuration, an isolated code sandbox with credential injection kept outside the agent's reach, per-tool approval gates, model providers switchable without a redeploy, and a control plane for multi-tenant governance being built on the same architecture." status: "In Development" project_group: "enterprise-ai-platforms" period_from: "2026-06-17" related_skills: ["artificial-intelligence","mcp","python","databases","quality-assurance","system-analysis","product-management","docker","kubernetes"] related_experience: ["ai-product-manager-at-spotware"] keywords: ["Agent Platform","AI Agents","Deep Agents","LangGraph","Agent Protocol","Agent Runtime","Code Sandbox","Credential Injection","Human in the Loop","Multi-Provider","Agent Orchestration","Semantic Memory","Python","PostgreSQL"] license: "https://creativecommons.org/licenses/by/4.0/" canonical: "https://www.alexfeel.info/projects/managed-agent-platform/" --- ## Overview I am building a self-hosted platform for running AI agents in production rather than as one-off scripts. The core idea: an agent should be a **stored configuration**, not a codebase. One configurable runtime — model, system prompt, tools, subagents, skills, memory, access rules, approval gates — and every new assistant is a configuration record served through an API, deployed on a schedule or on demand, with no redeploy and no new repository. The platform is in active development as one product — the runtime, the sandbox layer, the access model, and the control plane that will make it managed. Nothing here runs production workloads yet: I build, test, and continuously exercise every capability in local deployments as it lands, and the sections below describe where the build currently stands — a growing list, not a finished one. ## Built So Far The foundations below are implemented, covered by tests, and exercised continuously as new capabilities land on top of them: - **A configurable Deep Agents runtime on a self-hosted Agent Protocol server.** Agents run as LangGraph graphs served by [Aegra](https://github.com/aegra/aegra), backed by PostgreSQL for threads, checkpoints, and storage, and Redis for multi-instance dispatch and streaming. The agent factory builds a differently configured agent per request from one strictly typed schema — a typo in an assistant's configuration fails loudly instead of silently misbuilding the agent. - **An isolated code sandbox for agents that touch real repositories.** Agents that clone, read, and modify code do it inside an isolated sandbox with a prebaked multi-language toolchain image, thread-scoped reuse across a conversation's turns, and warm snapshots for fast cold starts. Credentials are injected at the boundary — the agent uses them without ever holding them. - **Access control an operator can reason about.** Filesystem permission rules (allow, deny, or interrupt-for-approval; first match wins), a restrictable tool surface, and per-tool human-in-the-loop gates — with the known reliability limits of approval gates inside dynamically dispatched code documented and pinned by regression tests rather than papered over. - **Dynamic, code-driven orchestration.** Instead of a hand-wired workflow graph, the model can author its own dispatch logic at run time — loops, fan-out, conditional multi-phase flows — through a sandboxed code-execution tool that dispatches subagents programmatically. This is the concrete difference from fixed-node automation tools of the n8n class: the workflow shape is decided by the agent per task, under the same approval gates as everything else. - **Provider and model choice as configuration.** Anthropic, OpenAI, and OpenAI-compatible endpoints are interchangeable per assistant; switching a model is a configuration change, not a deployment. That makes cost and capability trade-offs an operating decision instead of an engineering project. - **Scheduled and stateless execution.** Assistants run on cron schedules or as stateless one-shot invocations from CI, with end-to-end tests covering the awkward combinations — a scheduled run that needs a sandbox, an interrupted approval, a resumed thread. - **Opt-in semantic memory.** A pgvector-backed store for per-user preferences and durable memories, scoped deliberately to agent memory rather than pretending to be a knowledge base. The engineering discipline matches the ambition: the platform carries a real end-to-end test suite that boots the actual server over a throwaway PostgreSQL, and an architectural layering rule — platform capabilities must never depend on any specific agent harness — enforced by a test that fails the build on a violating import. ## The Managed Layer, Same Product The control plane is what turns a runtime into a managed platform: an assistant and agent registry, users and roles, a vault for connector credentials with audit, knowledge-base ingestion, and the product UI. It is part of the same in-development whole, not a someday appendix — its architecture is decided (its own services, its own data, integration through APIs rather than a shared database), and the runtime is already built for it: every persisted record carries its tenant from day one, precisely because retrofitting multi-tenancy later approaches impossible. The build simply reaches the layers in order, and this is the layer it reaches next. ## Why It Matters Every organization adopting agents rediscovers the same needs in the same order: isolation for agents that touch real systems, credentials that agents can use but not read, approval gates on consequential actions, cost control through provider choice, and a way to ship the next assistant without shipping new infrastructure. This platform is those answers built once, as infrastructure — and the defects found while building it were filed upstream in the open, across the sandbox and server layers it builds on ([OpenSandbox](https://github.com/opensandbox-group/OpenSandbox/issues?q=author%3Aalex-feel), [Aegra](https://github.com/aegra/aegra/issues?q=author%3Aalex-feel)), rather than worked around locally. ## Site index - [llms.txt](https://www.alexfeel.info/llms.txt) - [Complete index](https://www.alexfeel.info/llms-index.txt)