The short version
Trade Republic (10M+ customers, 18 countries, a fully licensed bank) runs an internal "AI employee" that serves around 47 teams, handles over 10,000 sessions a week, and in some team channels solves over 90% of incoming requests on its own. The infrastructure bill is about 100 bucks a month, because it runs on repurposed company laptops.
The design inverts the usual agent stack: routing, permissions, and confidence checks are plain deterministic code, and an LLM is only invoked when code can't classify the problem. The idea worth stealing: put the guardrails and the decision-making outside the model, in code the model can't override, and let people improve the agent with a one-click feedback loop that turns into reviewable PRs.
Key takeaways
Deterministic first, LLM last
When a Slack message arrives, pure code decides what the problem is and what to do about it. The routing layer spends zero tokens and often decides in under a millisecond. Only when code can't figure out what the problem is about does the system invoke an LLM.
Three confidence gates, configured per channel
Each channel gets a 0-100 confidence scale with two thresholds. Below the first (say 50): stay quiet, don't spam people. Between them (50-80): propose a solution and tag humans for approval. Above the second (80+): investigate first, then act autonomously. It never auto-merges, because a bank can't have that.
Permissions in code, not in prompts
He calls the "please don't expose secrets" markdown-file approach hope, not control. Over 30 categories of security hooks fire deterministically around every task, CLI call, or curl command; some native CLI tools are banned in favor of custom wrappers. The system knows who is asking, so a finance document shared with the agent can't be leaked to someone outside finance just by asking nicely.
Compile-time knowledge, not runtime lookup
Skills, routes, sub-agents, and configs are markdown and YAML artifacts defined at org, domain, or team level and compiled into each team's agent, with team IDs, projects, and channels baked in so the LLM never wastes a lookup. Teams can override org artifacts, with one exception: hooks. A team cannot override a company rule.
Feedback becomes PRs
Anyone can type a thumbs-up or thumbs-down message in the thread. The system analyzes the thread against its knowledge and comes back with "I improved myself, want to merge the change?" Teams merged over 500 of these self-improvement PRs within a few months. It never self-improves without a human merging.
It also shows up uninvited
Scheduled jobs run as pure code, full agentic, or a hybrid that checks state in code for free before spending tokens; a guided mini framework lets compliance, finance, and legal people write these jobs themselves. A knowledge-graph workflow ingests a team's Confluence and a year of conversations, and a weekly data pass finds blind spots and files knowledge PRs to fix them.
The numbers
- ~47 teams served, ~150 Slack channels, running 24/7
- 10,000+ sessions per week, roughly 50,000 problem sessions per month
- 60 parallel sessions at peak, within a single domain
- 90%+ of incoming requests solved autonomously in some team channels
- 500+ self-improvement PRs merged within a few months
- 30+ categories of deterministic security hooks
- 15 dashboards, 250+ technical panels, per-route and per-trigger cost tracking
- ~100 bucks/month infrastructure cost, on repurposed company laptops
Caveats
All numbers are the speaker's own, with no external write-up to check against. The 100-bucks figure is explicitly infrastructure only: LLM token costs sit on top, and the talk doesn't give that bill (the deterministic-first design exists partly to keep it down). The system is an internal tool, not a product, though he says the engine is generic and previews what's next: shared context across Slack, Meet, Jira, and GitHub in one session, plus harness- and LLM-agnosticism (Claude Code, Codex, OpenCode, Cursor CLI, Bedrock, GCP, or bare metal) behind a one-line config change. On "does this replace engineers" he's direct: the point is not cutting headcount, it's removing the two-day dependency-upgrade kind of work nobody enjoys.
Why it matters for Teams AI builders
Most agent setups this community runs put the LLM in charge and bolt guardrails on afterwards. This talk describes the opposite architecture, in production, at a bank: code decides, the LLM executes, and policy lives in hooks the model cannot override (he name-checks Anthropic's Claude Tag as a step in the right direction that is still nowhere near this). The compile-time injection trick is immediately usable: anything you know statically about a team or project belongs in the prompt artifact at build time, not in a tool call at runtime. Same for the feedback loop: a reaction in a thread that becomes a reviewable PR against the agent's knowledge is a pattern any of us could wire up with the tools we already use.
Join the discussion
Which decisions are you currently asking an LLM to make that ordinary code could make instead? In this talk, a simple score of how well an incoming request matches something the agent already knows decides whether it acts, asks a human, or stays quiet. And on the feedback loop: Trade Republic's agent improves by opening PRs against its own knowledge base whenever someone leaves feedback, and teams merged 500+ of them in a few months. Be honest about your own team: would you review those PRs properly, ignore them, or rubber-stamp them without reading?