Inside My AI Control Center: Routing, Memory and Evals for a Small Company

I run a small company with a lot of systems: our own products, client platforms, servers and websites. For most of 2026 the extra pair of hands has been AI agents. After a few months of copying context between chat windows, I built a control plane for that work. I call it the AI Control Center.

It runs on my workstation: a set of Node.js MCP servers, a PHP API with a React admin, and a MariaDB database that holds everything the agents know and do.

Six MCP servers, about 130 tools

Claude Code talks to the platform through six MCP servers:

core: tasks, memory, approvals and policy checks;
agents: asking another model, delegating work, feedback and performance tracking;
infra: SSH, SFTP, database queries and backups for every project;
loops: event-driven autonomous jobs;
content: research pipelines, Search Console and the local ComfyUI studio;
governance: controlled HTTP access.

Every tool call is logged. That log has been the single most useful debugging tool I have.

Routing between models

There are 12 registered agents using more than nine models: Claude, GPT-4o and Codex, Gemini 2.5 and the Gemini CLI, DeepSeek, Grok, models through OpenRouter, and a Bulgarian-language Gemma model. A call can fall back from its primary model to Codex and then to OpenRouter, with circuit breakers so a failing provider is skipped instead of hammered. Every attempt is logged with its cost and latency.

The hard part was not the cascade itself but the small differences between providers. One returned an empty successful response when its reasoning ran out of tokens. Another needed a timeout that grows with the requested output length. They also report cached tokens differently, which matters once you track cost. None of this is in the marketing pages; you find it in your logs.

Memory, and two lessons about it

The platform keeps a memory graph in 11 tables: entities, observations, events, relationships, patterns and a working set for the current task. A daily optimizer tidies each entity, and a weekly job consolidates summaries.

Two lessons. First, I built a contradiction detector based on text similarity, measured it, and removed it, because it did worse than having none. Second, I caught the consolidator turning claims into facts: something an agent had guessed got summarized, and after a week the summary stated it as known. Memory needs provenance, or it will launder guesses into truth.

Evals that gate, not decorate

Each autonomous loop declares how its results are checked. Some checks are plain code that inspects the stored result, others use an LLM judge, and a judge's verdict has to follow from the stored data rather than from its own opinion. On top of that run:

a weekly golden-dataset regression across agents;
a model bake-off with a detector for fabrication drift;
a harness that runs every prompt template against every model and keeps every result, failures included.

An eval only gates a loop if a real check claims it. A declared check that nothing runs is worse than none, because it looks like safety.

Autonomous loops with brakes

Loops fire on events. Each has a budget, takes a lock on the records it works on, retries a failed run up to three times before parking it in a dead-letter queue, and switches itself off after five runs that changed nothing. Anything risky goes to an approval queue, and automatic approval is limited to low-risk, allow-listed actions. Context is also classified on five sensitivity levels, with redaction and blocking before it reaches an external API provider.

What I'd tell someone building one

Start with the boring parts: logging, budgets, approvals and locks. Cleverness can come later, but you can't add an audit trail to last month's runs. Write down every invariant you discover. I'm at 58 of them, and each one is a bug I don't intend to meet twice.

The full picture, including the MCP servers this platform drives, is in my AI and MCP portfolio.