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, 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, Aegra), rather than worked around locally.