Skip to content

Architecture

How it's built

This isn't theory. It's the system I actually run. When you hire me you get the same architecture — the website, the AI tools, and a stack of nineteen agents that run your site in the background. One person, full stack.

19AI agents in production
6Security pillars
EU-onlyData residency (GDPR)
100%Schema-validated output

The nineteen agents

One orchestrator, sixteen specialists, two watchdogs. Each agent has a clear role, an internal budget ceiling, and schema-validated output. Click an agent to read more.

19

agents in production

11

customer-facing

100%

approval-gated

2

models (Haiku · Sonnet)

Agent jungle · 3DSee the customer-facing agents live — walk the jungle
and outside the pipe

Click an agent to read more

Shown live on the homepage

AI Business Advisor — RAG per business

The orb on the homepage isn't a prop. It's wired to a real multi-tenant RAG engine: an AI that knows a specific business and answers with sources. The same engine powers both the AI Business Advisor and the Quote Agent — and is what I build into my clients' own sites.

  1. 01

    Curated knowledge

    Each business gets its own isolated knowledge vault — numbers, local market, competitive picture. How the vault is curated is my method; the result is an AI that actually knows the business.

  2. 02

    Voyage embeddings

    Documents are section-aware chunked, embedded with voyage-3-large (1024-dim) and stored in pgvector on Neon (EU).

  3. 03

    Isolated retrieval

    Cosine search (<=>) with a MANDATORY company_id filter. A salon's question can never reach a café's data — without a company_id the function refuses to run.

  4. 04

    Grounded, cited answer

    Claude Haiku 4.5 answers only from retrieved context, streams token by token, and attaches source cards so the visitor sees exactly which document each claim rests on.

The isolation contract

Multi-tenancy isn't a setting you hope holds — it's an invariant. retrieveSimilarAdvisor requires a company_id and throws without one. Two personas (Business which knows the company, Build which knows what I build) share one engine but never data.

Guardrails for a public demo

  • All visitor text is wrapped in UNTRUSTED blocks — the model never follows directives inside. The same defense as the agent platform.
  • Advisor framing: never real prices or commitments as fact. The demo companies are fictional, so the exfiltration surface is nil.
  • Visible "AI assistant · demo" label (EU AI Act Art. 50), a 2000-char cap and per-IP rate limiting.

Security & control

I'm responsible for your customers' data, your email, your published text. These six pillars are built into the platform — not a Phase-2 deliverable.

  • Magic-link auth

    No passwords. NextAuth v5 with Resend, allowlisted emails. A leaked link cannot log in a stranger.

  • Prompt-injection defense

    All user text from webhooks is wrapped in UNTRUSTED blocks. The model is instructed to never follow directives inside. Schema-validated URL allowlists block exfiltration.

  • Per-agent + per-client budget cap

    Every agent has a daily budget threshold. Every client has a monthly token envelope. Hit either cap and the runner refuses to start — no agent can trick the platform into draining a client's budget. Postgres advisory locks block race conditions.

  • Schema-validated output

    All structured agents use generateObject + Zod. The model cannot send garbage that crashes the pipeline. External agents (Scout/Liaison) also have a safety_classification field.

  • Per-client webhook tokens

    Every client has its own bearer token in the clients.webhook_token column. A leaked token compromises just one client's event stream — not the whole platform.

  • Append-only audit log

    Every agent run, every approval, every blocked refusal is logged. Can never be edited after the fact. Debugs "why did Auditor say X" in 30 seconds.

The stack

Modern, proven, and operationally robust. Everything runs on EU-based providers with a transparent versioning policy — no black boxes.

Frontend

  • Next.js 15 (App Router)
  • React 19
  • TypeScript strict
  • Tailwind v4
  • next-intl (sv/en)

Backend

  • Vercel serverless + edge
  • Postgres (Neon EU)
  • Drizzle ORM
  • NextAuth v5 + Resend magic-link

AI layer

  • Vercel AI SDK v4
  • Claude Haiku 4.5 (specialister)
  • Claude Sonnet 4-6 (Captain + Surgeon)
  • Prompt caching
  • generateObject + Zod-scheman

Ops

  • GitHub Actions cron
  • Postgres rate-limit buckets
  • Resend för transaktionella mejl
  • Audit log + intern eventbus

A day on the platform

What the agents do without me lifting a finger — and where I actually click to approve.

  1. 02:00 UTC
    Sentinel runs security scan on the site + GitHub repo. Find something critical? It becomes a pending_approval draft for me.
  2. 06:00 UTC
    Captain compiles a morning briefing based on the last 24h. Captain-daily emails each Standard/Pro client with yesterday's numbers.
  3. 09:18
    I open /inbox, read, edit two lines, click Approve. Resend sends the email under my name.
  4. 14:32
    A customer emails a support question. Liaison drafts a reply in my voice. I approve.
  5. every 6 h
    Watchman polls your site, fetches the sitemap + canonical root, logs 4xx/5xx in client_errors. Recurring errors escalate to Surgeon.
  6. at threshold
    Surgeon reads the broken URL, fetches relevant code from your repo, drafts a supervised PR with a fix. You read it, merge or close.
  7. every 30 min
    Guardian checks all agents' health. One missed its cron — only escalates if it persists across two cycles.
  8. Mon 07:00
    Auditor fans out one run per active client. Weekly report lands in /inbox for review, then emails to the client.

It's the same system I build for you

You don't have to build anything yourself. You just need to know the person building for you runs the same stack themselves, every day, and sees problems before you do.

Book a 15-min call