Everyone is building AI agents that do tasks. GlassBox is the opposite bet: one agent whose only job is to build your team's automations — and then get out of the way.
I built it at my day job, for internal teams across sales, ops, marketing and engineering. The full concept is written up as a public presentation (there's a Russian version too), and the architecture docs and installation guides are on GitHub — the code itself is private, but the repo documents the design honestly enough that you could rebuild it.
The gap nobody's tools cover
Watch what teams actually ask for, week after week, and a pattern emerges. It's rarely "write me code" and rarely "make a big strategic decision." It's chores: query this data, filter it by that condition, post the result to Slack or Notion, every Monday. Someone does it by hand. Then someone else asks for a nearly identical thing. Then the first person goes on vacation and the chore silently stops.
The existing tooling misses this in two different ways. Coding assistants — Claude Code, Cursor, Copilot — are brilliant, but they need a human sitting there running them. They don't wake up on Monday morning on their own. Black-box agent products go the other way: they'll run autonomously, but you can't see what they did, why they did it, or what they'll do next. No audit trail, no way for the team to inspect or fix the logic. For anything touching real company data, that opacity is disqualifying.
The gap is specifically recurring, autonomous, multi-user tasks. Frequent enough to be worth automating, boring enough that nobody wants to own them, and shared enough that "a script on my laptop" isn't an answer.
The inversion: an agent that builds, then steps aside
GlassBox's core move is that the AI agent is the builder, not the runner. The lifecycle looks like this:
- Someone describes the need in Slack, in plain language: "Every Monday, send the expiring-packages list to this channel."
- A Claude-powered agent builds an n8n workflow — the trigger, the data queries, the filtering, the destination. It's doing the same thing a competent automation engineer would do, just in minutes instead of a sprint.
- The workflow runs autonomously on its cron schedule or event trigger. The agent is no longer in the loop. No LLM call on Monday morning — just a plain n8n workflow executing deterministically.
- The team edits workflows directly in n8n. This is the "glass box" part. The output isn't agent behavior you have to trust; it's a visible, editable workflow diagram anyone with access can open, understand, and change.
For developers there's a fifth surface: MCP exposes the same tools to Claude Code, so an engineer can build or modify workflows from their IDE instead of Slack.
The consequence I care most about: intelligence is spent once, at build time. After that, the automation is just plumbing — inspectable, auditable, and free to run.
Architecture: six layers, deliberately boring
The system is six layers, and most of the design decisions were about removing cleverness rather than adding it:
- Interfaces — Slack for most users, n8n's own editor for power users, and the IDE (via MCP) for developers.
- Agent runtime with guardrails — the Claude-powered agent that interprets requests and assembles workflows, constrained in what it's allowed to touch.
- Intent routing — deciding what kind of request this is and which tools it needs.
- Tools — n8n's REST API for workflow CRUD, data query tools, and Atlassian APIs for the systems teams already live in.
- State — Postgres and Redis.
- Models — Claude Sonnet 4.6 for the reasoning-heavy workflow construction, Haiku 4.5 for cheap routing. Everything runs on a VPN-gated cloud VM (4 vCPU / 16 GB) — no company data leaves the perimeter except the model API calls themselves.
The knowledge layer is the decision people push back on most: it's curated markdown files with freshness tracking, deliberately no vector DB. For a bounded internal domain — our data schemas, our naming conventions, our destinations — a few dozen well-maintained markdown files that the agent reads directly beat a RAG pipeline. Retrieval can't hallucinate relevance when there's nothing to retrieve; the agent either has the documented fact or it doesn't, and freshness tracking tells us when a file has gone stale. A vector DB would have added infrastructure, an embedding pipeline, and a new failure mode, to solve a scale problem we don't have.
Because multiple teams share the system, RBAC and audit trails aren't afterthoughts — who can build what, who can touch which data sources, and a record of every action the agent took. That's the other half of the "glass box" name: not just visible workflows, but visible agent behavior.
What's actually running, and what it costs
I'll keep the outcomes honest, because this is early. The first production workflow is a sales digest of expiring client packages — the exact "every Monday" example above, running daily. It saves the sales team roughly 30 minutes a day of manual querying and copy-pasting. That's one workflow, not a fleet; the platform's value grows with each one added, and the interesting test is the second and tenth workflow, not the first.
The cost model is where the inversion pays off. Building a workflow costs $5–10 in model tokens — that's the one-time spend of Sonnet reasoning through the construction. Running it costs approximately zero, because execution is plain n8n with no LLM in the loop. Compare that to per-seat agent SaaS at roughly $1,200 per user per year, forever. A hundred workflows through GlassBox is a $500–1,000 one-time spend on infrastructure the team owns and can inspect.
What I'd tell someone building this
The counterintuitive lesson is that the AI is the least interesting layer. Claude assembling an n8n workflow works well; that part was never in doubt. The real design work was everything around it: guardrails on what the agent may touch, audit trails so autonomy is reviewable, markdown knowledge that stays maintainable, and the choice of n8n as the output format — because an automation your team can read is worth ten that they have to trust.
If the details are useful to you, the presentation walks through the concept and the GitHub repo has the architecture docs and installation guides.
Originally discussed (in Russian) on my Telegram channel, where I share cases like this from work and side projects.