How a Berlin EdTech is adopting AI across their entire tool stack — from customer interviews to delivering increments in production

The situation

A Berlin-based EdTech company with a small engineering team needed their AI tools to do more than answer questions. They wanted Claude and ChatGPT to actually work inside their toolchain — create Jira tickets, search Slack history, query dashboards, manage Google Docs, trigger CI/CD pipelines. Not through a chatbot UI with buttons, but directly from Claude Code sessions and ChatGPT conversations.

The problem wasn’t connecting services. APIs exist. The problem was doing it safely for a team where a single engineer maintains the infrastructure. When an AI agent can send emails, close issues, and modify documents, you need more than permissions — you need rules that the AI itself can’t override.

What they built

Instead of stitching together individual MCP servers per service, they built a single gateway that exposes every connected tool through one MCP endpoint. The AI doesn’t need to know which server handles Jira or which one handles Gmail. It calls one endpoint, specifies the action, and the gateway routes, validates, and executes.

The architecture is deliberately simple: every action is either a read or a write. Reads return data. Writes change state. There’s no natural-language routing layer guessing what you meant — the AI specifies the exact action name, and the gateway executes it deterministically. This turned out to be the single biggest improvement for reliability. When you remove ambiguity from the execution path, error rates drop to near zero.

What’s connected

Hooks: where the real control happens

Every tool call passes through a hook pipeline — configurable in YAML, not hardcoded. There are two types:

Policy hooks enforce rules. They can block, require confirmation, or restrict what the AI is allowed to do. When someone tries to transition a Jira ticket without meeting the workflow prerequisites, the hook blocks it. When the AI attempts a destructive Google Workspace action, the hook requires explicit confirmation first.

Enrichment hooks make actions smarter. When the AI creates a GitLab merge request, a hook checks if a Jira ticket is referenced — and enforces the link if it’s missing. When the AI writes a Jira description in Markdown, a hook converts it to Jira’s native ADF format automatically. The AI doesn’t need to know about ADF. It writes Markdown, and the hook handles the rest.

There are currently 22 hooks in production. They run on every request, typically in under 5ms. The team adds new hooks when they discover a pattern the AI keeps getting wrong — instead of re-prompting, they codify the rule once and it applies everywhere.

Privacy by architecture

The gateway stores no messages, no emails, no documents. OAuth tokens are encrypted with KMS, and the key is customer-controlled. Logs are held in a RAM-based ring buffer — they exist only while the process runs. When the system creates a bug report, it captures a snapshot of the ring buffer at that moment, scrubs it for PII (emails, names, IPs), and attaches it to the GitLab issue. After that, the original logs are gone.

Redis keys never contain PII — user identifiers are SHA256-hashed. An automated PII audit runs in production and flags any violations. The team calls this “zero data at rest”: the gateway processes everything, stores nothing.

The things that make it daily-driver ready

• Parallel execution — The AI can fire multiple read actions simultaneously. “What’s on my calendar, any open MRs, and what’s the latest Amplitude DAU?” — three services, one response, under a second.
• Quality monitoring — A daily health check computes a routing health score from production telemetry. If empty response rates exceed thresholds, an issue is created automatically.
• Hot reload — Change hook rules, access control, or service config without restarting the gateway. One API call, zero downtime.

By the numbers