MassAI case study: how we use Claude agents in production

We were our own first client

Our internal rule is simple: we don't propose a system to a client that we haven't run ourselves first. Our own operations are our permanent testing ground — this is where we learn what survives production, what breaks under pressure, and what is worth taking to clients.

What follows is not a demo prepared for a slide deck. We built a system on Claude that is useful enough to take part in the company's operations every day — and controlled enough that we know exactly where it is not allowed to act on its own.

Where Claude agents work every day

An agent available around the clock, on Telegram. It runs on our own server and is the same counterpart at any hour: it takes a task from a phone, executes it, and reports back. Context persists — today's conversation knows what was decided last week.

Monitoring with escalation. Our services are checked continuously. When something goes down or errors start repeating, the agent sends an alert to Telegram with the details already gathered — a human steps in informed, rather than starting the investigation from zero.

End-to-end publishing. The site's news section, in Romanian and English, goes through a complete pipeline: HTML integrity checks, a dedicated Open Graph image for every article, sitemap updates, and submission to Search Console. Social media distribution is another runbook the agent executes, with human approval before anything goes live.

Email, integrated with a brake. The company's email is connected through an MCP server we built ourselves: the agent reads, sorts, and drafts replies. Actually sending always requires a human's confirmation.

Records that don't expire silently. The agents keep a registry of credentials and integrations and alert well in advance — before an expired token stops a production flow.

The stack: Claude Code, the Agent SDK, and MCP

Each component has a precise role. Claude Code is the execution layer — the environment where agents actually work: reading, writing, running tools, checking results. The programmatically built agents — the ones running around the clock on the server — use Anthropic's Agent SDK, on a Python stack.

Access to the company's tools goes through MCP (Model Context Protocol) servers built in-house — email, analytics, publishing. Every tool has a clear interface and scoped permissions: an agent gets exactly the capabilities its task requires, and nothing more.

Memory is persistent, file-based, with an index loaded at every session. Context compounds: decisions, conventions, and lessons carry over from one day to the next, and the agent becomes more useful the longer it works.

The company's procedures are skills — versioned runbooks the agent executes step by step. Once a flow has been done manually a few times, we turn it into a skill; from then on it is repeatable and verifiable.

How we split the work across models

One architectural decision has proved especially important: work is split across subagents running models of different capability. Mechanical tasks go to fast, inexpensive models; integration and review to mid-tier models; architecture and the hard decisions to the most capable model.

Every deliverable then goes through a review loop where a different agent checks the work — the evaluator is separate from the executor, and an implementer never validates its own output. The practical effect is twofold: cost stays proportional to the difficulty of each task, and quality never depends on the self-assessment of whoever produced the deliverable.

Autonomy with brakes: where the agent stops and the human steps in

Just as important is what the agents are not allowed to do on their own. Any write to production systems — the website, the servers — needs an explicit GO from a human. Emails only leave after confirmation. Content publishing waits for a human's editorial approval.

These brakes are a design choice, the same one we build into client implementations. An agent that can take irreversible actions without a human stop is an operational risk, no matter how capable the model. Mature autonomy combines machine speed on execution with human judgment on the decisions that matter. It is also where European regulation is heading: transparency, logging, and human oversight by design.

What we learned and what transfers to clients

Three lessons have held up often enough that we apply them in every implementation:

The runbook comes before the autonomy. You can automate well a procedure you can write down clearly. If the process is chaotic, the agent will execute it chaotically — faster.

Accumulated memory is the difference between a tool and a colleague. An agent that retains your company's decisions and conventions saves exactly the time usually lost re-explaining context.

Human gates go in on day one, on the irreversible actions. It is far easier to relax a brake that proved unnecessary than to undo a mistake made at machine speed.

What we use internally is not a product to copy wholesale — every company has different tools and different risks. The architectural patterns are what transfers: executable procedures, memory that compounds, scoped tool access, human gates on the irreversible. If you want to see how this model would translate to your company's operations, start with our guide to operational AI agents.

References: ↗ Claude Code (Anthropic) · ↗ Model Context Protocol