We build with AI, in the open
Everything below is real and running, built by a Chicago managed-IT firm using AI, including the site you're reading. Consider this a tour of the lab. Tron Netter, in the corner, will answer questions about any of it.
Software Brain
The engine behind everything on this page.
A conversation-first, memory-bearing, tool-using AI architecture modeled on neurological principles, built as a TypeScript monorepo. Every other exhibit below runs on it.
01 · Memory
Scoped memory that persists across conversations, so every system built on the Brain remembers what matters instead of starting from zero each time.
02 · Voice
A full voice stack: speech-to-text, text-to-speech, and realtime conversation, the same packages that let you call Tron Netter from this page.
03 · Rebuild-Ready
A canonical architecture document specifies the whole system in enough detail that a competent team could reconstruct it from the document alone.
TypeScript monorepo · scoped memory · voice (STT/TTS/realtime) · canonical architecture doc v17
@aicompany/core
An entire AI-company website in one config file.
Reusable middleware that gives any business an AI persona and everything a working AI company site needs around it. It ships today as a git submodule inside two live production sites: this one and IT Support Chicago.
01 · Every Channel
One persona across web chat, SMS, email, and voice, plus OAuth sign-in for visitors who want an account.
02 · The Whole Site
An admin console, first-party analytics, SEO surfaces, a nightly knowledge crawler, and a single-VM deploy stack come with it.
03 · One Config File
A single site.config.ts drives all of it: the host site supplies the config, the middleware does the rest.
chat / SMS / email / voice · admin console · analytics · nightly crawler · one config file
ai.xl.net
The site you're reading right now: our maximum-oversight deployment.
Every constraint here is a decision, not a limitation. Safe by architecture, not by promise.
01 · Human BCC
Every email our AI sends is BCC'd to a human, so nothing leaves unreviewed.
02 · No Tools, No Internet
The public persona has no tools and no live internet access, so it can never take an action we haven't designed.
03 · Published Knowledge Only
Its knowledge is a nightly crawl of xl.net and ai.xl.net, so it only speaks about what we publish.
Try it: chat, text, email, or call Tron Netter on this page.
human BCC on all outbound email · no tools, no internet · nightly knowledge crawl · single Azure VM behind a Cloudflare tunnel
IT Support Chicago
Our controlled autonomy experiment: the deliberate opposite of the site you're on.
itsupportchicago.net was designed as a test of a 100% autonomous organization: how far can an AI-run operation go with no human in the loop?
01 · Maximum Autonomy
No human in the loop: the experiment exists to find out how far an AI-run operation can go on its own.
02 · Hardened Sandbox
A GCP confidential VM with AMD SEV memory encryption, Shielded VM boot integrity, IAP-only SSH, and deny-all ingress.
03 · Fully Separate
Its own infrastructure, completely separate from XL.net client systems, so the experiment can fail safely.
Maximum oversight here, maximum autonomy there: we run both, on purpose, to learn where the line is.
GCP confidential VM (AMD SEV) · Shielded VM · IAP-only SSH · deny-all ingress
Visit itsupportchicago.net (opens in a new tab)QBR Machine
A client name in, a complete quarterly review package out.
The AI teammate working alongside our XL.net Technology Officers. Not a chatbot bolted onto a form: Claude Code running purpose-built, git-versioned skills that produce the actual deliverables XL.net presents to clients every quarter, sourced from live systems, with every number traceable to where it came from.
01 · Gap Analysis
A scored assessment of the client's security, network, server, and workstation environment, validated and self-tested before a human ever sees it.
02 · Asset Strategy
A lifecycle plan for every asset: when the firewall gets replaced, when the switch stack ages out, what it costs and when.
03 · QBR Deck
The client-facing review itself: a frozen 11-slide template where only the words change, fed real numbers from the Gap Analysis and Asset Strategy, not estimates.
Every provider connection runs through XL Lakehouse, our scoped and audited access layer. No provider API keys ever live in the AI's workspace. Its memory persists, too: client context, feedback, and working agreements carry forward quarter to quarter instead of resetting every conversation.
Claude Code · git-versioned skills · template-locked deliverables · validate, approve, self-test · Lakehouse-scoped access
Onboarding Toolkit
A client name in, a documented IT environment out.
The platform XL.net techs use on every new MSP onboarding. One place to discover the network, capture identity and cloud posture, validate completeness, and generate client runbooks, sourced from on-site scans, cloud connectors, and uploaded vendor reports, with every field traceable to where it came from.
01 · Discovery
On-site network scans, M365 tenants, and uploaded vendor reports merge into one inventory: deduplicated, classified, and ready for review.
02 · Intake & Review
Structured forms capture what automation misses. A review dashboard shows what's complete, what's open, and what's still blocking export.
03 · Runbooks
Client IT runbooks (new hires, terminations, patch policy, LOB apps) pre-fill from discovery data and refine with AI before export to documentation.
Client data stays scoped to the project: SSO login, a full audit trail, human approval on every change. An in-app AI assistant proposes edits; nothing writes until a tech approves it.
on-site discovery · cloud connectors · AI-assisted runbooks · human-in-the-loop · audit everything
XL Lakehouse
One vault holds every key; apps borrow access, never secrets.
The access layer behind every XL.net AI teammate. Instead of scattering provider keys across workspaces, internal apps connect once to Lakehouse, which holds the credentials, enforces what each app is allowed to touch, and makes every upstream call itself, so secrets never leave the vault.
01 · Scoped Access
Each AI workspace gets only the providers and operations it needs: nothing broader, nothing permanent without approval.
02 · Curated Tools
Common workflows ship as ready-made playbooks with guardrails: reads enabled, writes off by default, destructive actions structurally absent.
03 · Audit Trail
Every call is logged with who asked, which app, which credential, and what happened, so access can be reviewed, rotated, and revoked without guesswork.
Provider keys live in a dedicated secrets vault, not in anyone's chat session. Humans approve new apps and expanded access, and credentials stay tied to the person responsible for them. When the QBR Machine pulls live Autotask and VSA numbers, it goes through here, so the deliverable stays traceable end to end.
scoped access · per-human credentials · write-default-off · full audit log · self-service access requests
XL API Gateway
Your cloud, your keys, one governed front door.
What XL Lakehouse does inside XL.net, the Gateway does inside each client's own cloud: one local proxy that Cursor workspaces, internal tools, and developer VMs call instead of holding provider keys themselves. Operators onboard a client once, provision a site from the console, and wire who may reach which upstream API from a single place. The console is live; client gateways are deploying now.
01 · Deploy
Provision a gateway (and optional locked-down developer VMs) into the client's own subscription, with live health visibility and a controlled path to take a site down.
02 · Govern Access
Register consumer apps, map upstream providers, store credentials in the client's vault, and grant access per app. Deactivated credentials fail closed, and every change leaves an audit trail.
03 · Route Traffic
The gateway checks each caller's identity and permissions, attaches the right credential, forwards the request upstream, and returns the response unchanged, with usage counted per app, provider, and credential.
Secrets never sit in the console database or in developer workspaces: they are fetched from the client's vault only when a permitted request needs them, verified before go-live, and cut off the moment a grant or credential is revoked. Fleet alerts and scheduled updates keep sites current; no API keys get mailed around.
per-client isolation · vault-backed credentials · grant-checked proxy · audited fleet operations
Roleplay
A public multi-user AI playground running directly on the Brain SDK.
roleplay.xl.net is our external-tenant experiment: what happens when the Software Brain powers a product that isn't about XL.net at all.
01 · Brain SDK In-Process
The Software Brain's orchestrator, memory, and voice packages run inside the app itself to power multi-user AI roleplay.
02 · Realtime Voice
Live voice via STT/TTS and the xAI realtime API, so characters can speak, not just type.
03 · Gated and Isolated
Google sign-in with admin approval gates entry, and the tenant's data lives in its own isolated databases: your data stays yours.
Brain SDK in-process · realtime voice · Google sign-in + approval · isolated per-tenant databases
Visit roleplay.xl.net (opens in a new tab)Leo Netter
The AI teammate we test on ourselves first.
Leo Netter is our internal test bot: a memory-bearing assistant built on the Brain SDK, deployed to the people most likely to complain about it: us.
01 · Slack DMs Only
It lives only in Slack DMs for the XL.net team and never talks to customers.
02 · Rough Edges First
It exists so we hit the rough edges of a memory-bearing AI teammate before anyone else does.
03 · Architecture Is Canonical
Every behavior, tool, and test is written into the architecture document before code lands.
Slack DM-only · internal to the XL.net team · architecture-is-canonical governance
SpamSlayer
Is this email safe to open? A five-second answer, in Slack.
A phishing-triage bot the team runs on itself. DM it a suspicious email, @mention it in any thread, or forward one into a channel, and it returns a clear verdict (Safe, Likely safe, Suspicious, or Dangerous), a recommended action, and the specific reasons behind the call. It turns "hey, is this real?" into a self-serve check with reasoning good enough to teach on.
01 · Four Checks
Sender and headers, phishing language and impersonation, URL safety, and attachment risk: four checks on every message, from a pasted email, raw headers, a bare URL, or a dropped .eml or .msg file.
02 · Never Clicks the Link
It judges a URL by its structure and destination, never by visiting it, and compares the visible link text to the real href: the tell on most credential-harvest emails, caught without handing attackers a fingerprint of the tool.
03 · Errs Toward Caution
Verdict first, reasoning below. When the evidence is mixed it returns Suspicious, not Likely safe: a false alarm costs a moment, a miss costs an account.
The same analysis rubric ships as a standalone Claude Skill (email-safety-check), so the exact logic also runs on a file inside a desktop Claude session, not just in the bot. It listens over an outbound WebSocket with no inbound ports of its own, and runs sandboxed on a low-cost VPS.
Python · slack-bolt (Socket Mode) · Claude Sonnet · .eml / .msg parsing · sandboxed systemd VPS · also a Claude Skill
Want to build things like this?
You just toured our lab. We teach teams to build their own AI workflows and automations, the smart and safe way.