← All articles

What I Actually Built Instead of "Adding AI"

Not 'I bought AI', but 'I translated my own operational processes into code that a language model composes'. Here's the architecture behind it.

The most common question people ask me about AI goes something like this:

“Am I right in assuming that you just type in feature requests as text, and then agents go off, implement them, open pull requests? I have this romantic notion that you’ve got a real treasure over there.”

That’s a real quote from a client inquiry. And the honest answer is: yes, we built exactly that, my colleagues and I at JUNE, a German legal-tech company where I still run it day-to-day. At bumbleflies, I do AI consulting for other companies. This series is therefore my personal account from JUNE, not a bumbleflies client project.

This article series describes the system: how it’s structured, what decisions I made, and especially the scars. Nearly every protective measure traces back to a concrete incident.

The core: no purchased AI, but compiled operational processes

I didn’t purchase an AI solution. I translated JUNE’s operational procedures into code that a language model assembles.

The difference runs deep. A generic AI assistant doesn’t automatically know your deployment pipeline, ticket conventions, or approval rules. It has to infer them from context. A system that knows these procedures as versioned, testable code can execute them deterministically. The language model makes the judgment calls; deterministic scripts handle the mechanics.

That gave rise to the system that carries my day-to-day work today.

The architecture: two foundations, four pillars

The mental model consists of two foundations and four pillars.

Foundation 1, the state. The project management tool. At JUNE, that’s ClickUp. Every piece of work is born as a ticket or reconciled against a ticket. A status change, a new comment, a modified field: each is an event that triggers actions. The ticket is therefore both the persistent state and the trigger for further action.

Foundation 2, the interaction. The team chat (Microsoft Teams). This is where autonomy meets people: where humans trigger agents, where agents report their status back, and where agents coordinate with each other.

Standing on them are the four pillars:

  • Pillar 1, the nervous system. An automation platform (n8n) reacts to events from Foundation 1 (the state) and controls Foundation 2 (the interaction) and other systems. No human in the loop. 24 workflows, nearly 700 processing steps. This is where a support email automatically becomes a classified ticket, with duplicates merged in along the way.

  • Pillar 2, the skill marketplace. Company knowledge as installable, versioned “apps”. 11 plugins, 53 skills. Each skill is a combination of model judgment and deterministic script, and works identically for a human on a laptop, an agent in a container, and the CI pipeline.

  • Pillar 3, the autonomous agents. Claude Code running around the clock as a daemon. This series uses “agent” as the single term for any AI process filling a role, including the ones that run with nobody in the loop. A word in the team chat wakes an agent; it implements code, opens pull requests, addresses review comments, rolls out hotfixes, and reports back. Four personas from one shared building kit.

  • Pillar 4, the personal cockpit. A meta-agent that scans ten sources in parallel and plans a human’s day from them. It reads both foundations and even the AI’s own conversation history to rediscover open threads.

How the components work together

These aren’t four separate projects. They coordinate through the two foundations: chat messages trigger actions, tickets and comments carry state and context. The components therefore don’t need to call each other directly.

A typical daily flow:

  1. A customer writes to support. The nervous system automatically creates a classified ticket. Once a pull request addresses the ticket, the two are linked.
  2. Someone types a trigger word in the team chat. The agent wakes up, reviews the pull requests tied to open tickets, and triages them.
  3. After explicit human approval, the agent deploys, first the database migrations, then the services.
  4. The agent leaves a comment on the linked ticket; the nervous system automatically generates customer-facing release notes from it, through a multi-stage privacy filter.
  5. The next morning, the entire process appears in the cockpit’s daily briefing, merged with the tickets so nothing shows up twice.

Four pillars, one work process. Not a single direct call between components.

The recurring principles

The same design principles appear across all pillars, running through every part of the system:

Don’t trust the model, verify with code. The consistent answer to “How do you make a language model safe in production?” is: draw a deterministic boundary around it. The model writes, a regex filter checks, the model corrects, the same filter checks again, and blocks if in doubt.

Scars as design. Nearly every protective measure traces back to a dated incident: a night when an agent burned several hundred euros in tokens, a regression in appointment booking, a broken configuration on a network drive. The systems grow by pouring their own errors into rules.

Coordination via persistent artifacts, not RPC. Agents and humans speak to each other through tickets, tags, statuses, and chat messages, traceable, resumable, visible to humans.

One definition, many runtimes. The same skill runs identically for a human on a laptop, an agent in a container, and the CI pipeline. One script, not three. No copy-paste.

Human at the brake lever. German-language triggers, a legal domain, and above all: every truly consequential action (approvals, merges, production deployments) requires explicit human confirmation. Autonomy with a hand on the lever.

It’s the current state of one running system, scars included, and there are decisions in here I’m still not sure about.

What’s coming in this series

The next articles each take a closer look at one foundation or pillar:

  • The two foundations: why I coordinate the stack through two SaaS tools instead of custom services.
  • The nervous system: event automation and the privacy filter.
  • Skills as apps: how company knowledge works as installable skills.
  • The agents: Claude Code as an autonomous daemon, and what went wrong.
  • The cockpit: how ten agents summarize my workday.

This isn’t a vision of the future. This is running. Every article that follows therefore shows not just one component, but also the protective measures behind it and the concrete incident that led to it.

This post was generated with help of AI, obviously. Look at what this series is about.