The company's brain — an always-on AI operator system, grounded in production data, supervised by humans.
I'm a developer at IntiGo — a mid-sized logistics business: ~100 vehicles, 275 drivers, hundreds of merchants shipping parcels through us every day. Argus is the AI operator system I'm building to run the business the way a CEO uses specialist staff — except the staff are AI agents grounded in our actual production database, and the human supervising them is me.
“What if the company itself had a mind?”
A network of specialist AI agents — each one good at one thing — connected through a shared backbone, all reading from the same production (read-only) replica database, all logging every decision they make. Claude is the decision-maker. Agents handle routine work autonomously. Anything ambiguous, sensitive, or high-stakes escalates to a human through Slack and email.
Over time the system earns more autonomy in categories where its track record is clean, and stays cautious where it's not. Less AI assistant, more AI workforce that runs the business while everyone sleeps and shows the receipts every morning.
Three things changed. First, the models got good enough — Claude can read an email, look up an order in a database, and write a reply better than most staff under time pressure. That wasn’t true in 2023.
Second, the plumbing got cheap. n8n, Postgres, a Mac mini under a desk, the Claude API — the entire stack costs less than one mid-level salary per year.
Third, the grounding problem is solvable. This is the one nobody talks about enough.
Most 'AI employee' products I've seen advertised fake the hardest part. They ingest documents, do some RAG magic, and hope the model says something sensible. That doesn't work in operations.
If a customer asks 'where is my parcel' and the AI invents a tracking number, the company loses the customer. If it quotes a wrong price, the company loses money. If it commits to a delivery date that doesn't exist, the company loses trust — and trust is the actual product in logistics.
Before composing any customer-facing reply, the agent must call a read tool against our production database. The reply is built from what comes back. If the lookup returns nothing — unknown order, no matching client, missing record — the agent doesn't guess. It drafts and escalates. Unsexy plumbing work. Also the entire game.
Watches the company inbox in near real time. For every incoming email, Claude reads it and chooses one of four actions: do nothing (newsletters, receipts, automated notifications), respond (draft a reply), notify (ping a human on Slack and email because someone needs to act), or escalate (the agent isn't sure — kick it upstairs).
Every decision logged. Every latency tracked. Every token counted. The non-negotiable rule: auto-send is disabled at launch. Every reply is a draft a human approves, until override rates prove the agent safe in a given category. Then, and only then, it earns the right to send on its own.
Same architecture, applied to Facebook first (Instagram and WhatsApp later — they share the Meta API). Replies to comments. Answers Messenger DMs. Publishes posts from a human-approved calendar.
Every reply is grounded in real data. Customer comments 'where is my parcel?' — the agent looks up the actual shipment and answers with the actual status. Customer asks for a quote — the agent pulls real pricing. Customer asks about a refund — the agent doesn't touch it; it drafts for human review.
Public channels mean public mistakes, so the autonomy bar starts higher than email. Only the safest, most repetitive intents auto-reply. Everything emotional, legal, complaint-shaped, or unfamiliar drafts for human review.
The first two modules listened. Module 3 talks — at scale. A directory layer over the intigo_finance database lets the LLM resolve the right person from across thousands of members (1,000+ drivers, merchants and partners), open a two-way conversation on the right channel (email, WhatsApp, SMS), and ground every outbound message in actual operational data: 'Where is parcel COL-4821 that you're carrying?' is built from a live lookup, not a guess.
When the recipient replies, the agent reads the reply against the same grounded context and decides the next step — close the loop, draft a follow-up, or trigger an action. Any action with real-world consequences routes back through Argus's existing trust gate: draft for human approval first, autonomous send only once the override rate proves the agent safe in that category.
Argus needs an internal cockpit, not just outbound channels. Module 4 is the CRM surface on top of the brain: leads, sales pipelines (New → Qualified → Meeting Scheduled → Proposal Sent → Won/Lost), marketing automations, HR — and, later, support. Same grounding rule: every action — assign a lead, send an email sequence, move a stage, schedule a reminder — is built from a live read against intigo_finance, and every consequential action still routes through Argus's existing trust gate.
The decision layer here runs on a local Gemma 4 on a Mac mini under the desk, not the cloud, for three reasons. The workloads are routine enough that Gemma is good enough; HR and lead data are sensitive and never leave the building; and at IntiGo's volume, local inference costs €0 per call. Claude (cloud) and Gemma (local) split by workload — Claude for the hard reasoning and customer-facing replies, Gemma for the high-volume routine CRM work and anything privacy-sensitive.
A hybrid stack, because nobody has solved this with a single tool. n8n on both sides — pulling the world in (webhooks, databases, APIs, email, schedules) and pushing decisions out (replies, alerts, database writes, API calls, published content). The AI in the middle is the brain that decides what to do.
A Node.js / TypeScript service handles the decision logic — the Claude calls, the guardrails, the database writes. Postgres is the truth layer: every event, every decision, every action, every metric. Audit trail and dashboard source in one place.
MCP is the backbone protocol so new tools can be added without rewriting agents. GitHub-backed everything so the system is portable — develop on a PC, production runs on a Mac mini, secrets stay out of the repo, the whole thing reconstructs in twenty minutes on any machine.
Agent orchestration frameworks (LangGraph, CrewAI, AutoGen) are flexible — you build everything yourself. 'AI employee' SaaS products (Lindy, Relevance AI, Cognosys) are pre-baked and generic — they can't ground in a specific company's Postgres schema. Vertical AI agents (Decagon, Sierra, 11x) are excellent at one thing — not a company brain.
Enterprise knowledge platforms (Glean, Hebbia, Sana) are mostly search and summarization over documents. Palantir Foundry is the original operational brain — decades old, billion-dollar product, not for SMEs.
There seems to be a gap in the middle for the opinionated, one-company AI operator. Argus is the bet that this gap is real — and that a single mid-sized operational business can be its own brain.
Argus is not a fixed flowchart. It is a team of specialist agents reacting to events on a shared bus: a connector pulls something in (an email, a DB change, a form, a schedule) and emits an event. The right expert wakes, grounds itself in intigo_finance, acts — and its action emits a new event, which wakes whoever is responsible next. The loop continues until the work reaches a terminal state.
Five layers: connectors (in), event bus, the team (orchestrator, expert, trust gate, hand-off), channels (out), truth & audit. The loop is the point — a channel action emits a new event that wakes whoever is responsible next.
“Where is parcel COL-4821?” — emitted, routed, grounded, gated, sent, then re-entered as a new event when the customer replies. No expert calls another directly — each emits, the next wakes.
Each expert is one config row: a role, a prompt, the events it subscribes to, its tools, and its own trust gate. Adding a specialist is adding a row. Here are five examples, as they would live in the table.
Answers "where is my parcel?" across every inbound channel, with the real status read from the DB.
Receives a lead, dedupes against the directory, scores it, and creates the card in the pipeline (Module 5).
Detects a refund request, gathers the order and payment context, and escalates to a human — never auto-sends.
Handles data questions from internal teams on Slack — read-only, never writes, never faces a customer.
Decides not what to say — decides who and where. Routes every alert to the right member on the right channel (Module 3).
The agent that picks the other agents. For every event it filters eligible experts, presents a short list to the LLM, and hands off to the chosen one.
| You want… | You add | Layer | Code deploy? |
|---|---|---|---|
| A new input source | a connector (n8n trigger) | 1 | n8n config |
| A new way to communicate | a channel (n8n send + enum) | 4 | n8n config |
| A new kind of specialist | an expert (config rows) | 3 | No — dashboard |
| More power for a specialist | a tool (rows + join) | 3 | Handler if genuinely new |
intigo_finance first. No fabrication.The articles published as I go, and the community threads where I pressure-test the design. Reading on is optional — it's here if you want to see how the build actually evolves.
The opening shot. The question — what if the company itself had a mind? The grounding principle that makes it different from chatbots (the agent never makes up a fact), the gap I see in the market between flexible frameworks and enterprise platforms, and the first two modules I'm starting with.
The V1 I'm committing to: narrowly scoped, inbox triage and human routing first. Four constrained tools (do nothing, respond, notify, escalate). Before composing any answer that touches a real fact, the agent looks it up in the production database. LLM pluggable, database single-source-of-truth, guardrails baked in from day one — not bolted on later.
The knowledge problem: how does a local AI actually know the company-specific procedures that live in people's heads, not in the database? The answer I land on is a knowledge-layer database for the rules — separate from the production DB — paired with live access to the production DB for the data. Crucially, nothing else in this whole system goes live without a human signing off, so the knowledge stays editable, never stale, never fabricated.
Part 4 — V1 is live. The agent's first job is the unglamorous, repetitive one nobody wanted: handling the inbound email queue. Shadow mode first (it watches and proposes, a human acts), then assist mode (it acts under one-click approval), then autonomy only on paths the trust gate has cleared. The boring-first principle: earn autonomy on a job where mistakes are recoverable and outcomes are auditable, before letting it touch anything that matters.
Posted the V1 design to r/GrowthHacking to pressure-test it — to ask the community what could go wrong, what's been done before, and what they would do differently. Three concrete points surfaced from the thread that are now top of the backlog.