Knows how the business works
A knowledge pack written for it: the job lifecycle, what every automation does and when, what “held” or “stuck” means, who owns which outcome, and which system wins when two disagree. Business knowledge, not source code.
JARVIS
An assistant that does the work, and asks first
JARVIS gives the people who run the company an assistant of their own, typed or spoken. It knows how the business works, asks the Job Adding System about any job, pulls numbers from every platform, builds the report and drafts the post, the update or the email. Then it waits: nothing changes until the person approves it on screen. Underneath, each person gets a governed server of their own, built so that nothing it does can slow the automations the business runs on.
34read-only JAS checks, over MCP
4layers of limits between it and JAS
0production credentials the agent can reach
1 clickto approve every change it makes
The demo
A morning with JARVIS
Three and a half minutes on the executive profile: a spoken brief, a stuck job explained, a board pack built in one prompt, then a Slack post, six CRM updates, a work board and an email to an outside address, each approved on screen before it goes. It ends on the guardrails. A mock demo: the screens are rendered and every record in them is illustrative.
3 min 33 s · mock demo, illustrative data
Read the transcript
Spoken lines only: the typed requests and the answers are on screen in the video.
JARVIS Good morning, Dylan. Everything's running, and JAS is healthy.
Dylan JARVIS, what needs my attention this morning?
JARVIS Three things. Four jobs have been waiting more than ten days on Ausgrid network approval. Overnight, the automations ran clean, except the AroFlo sync, which held two jobs for missing materials. And ops are waiting on your answer about the expo budget, in Slack. Your first meeting is at nine thirty.
Dylan Post in the installs channel. Thank the crews for hitting forty-one installs in October.
JARVIS Here's the draft. It's on screen for your OK.
JARVIS Posted.
Dylan Reply to Ausgrid's email. Thank them, and confirm we'll send the revised diagram by Friday.
JARVIS The draft is on screen. It's going outside the company, so please give it a read.
JARVIS Sent.
Dylan That's all for now. Thanks, JARVIS.
JARVIS Any time, Dylan. I'll be here.
What it does
Ask in plain English, by keyboard or by voice
Asks the Job Adding System
Any job, end to end, through the same read-only checks the staff console uses: why it is stuck, what ran overnight, what is waiting on whom. The checks it relied on are named in the answer.
Builds the report in code
It writes and runs report code in a sandbox, against the company’s own integration clients. “An October board pack: signings, installs, revenue and overdue invoices” comes back as a deck, every number pulled from its source.
Makes the change, once approved
It posts in Slack, updates the CRM and the work boards, replies to an email or files a document, always as the person who asked. Each change is held until they approve it, and anything going to a customer is flagged first.
Knows what isn’t its to change
Anything the Job Adding System owns is refused, with where the change belongs and an offer to draft it. A pull bigger than the day’s budget is refused up front with an estimate, and nothing destructive is on the menu.
Talks back
The ring is a small app on the person’s own server: push to talk, a calm British voice, a sentence or two out loud and the detail on screen. Speaking can ask for anything. Only a click approves it.
Two profiles, one build
Executives
the bazooka- A server each, so one person’s conversations and files never sit on another’s box.
- All 34 JAS checks, the knowledge pack and the integration kernel, for reports and small tools in their own projects.
- Changes in Slack, the CRM, the work boards and Microsoft 365, each approved. Accounting, field service, rebates and design data, read only.
- The ring, and the larger budgets.
Sales reps
the shotgun- A smaller server each, with no codebase in the workspace.
- The CRM, the work boards and Slack as ready-made tools, every update approved.
- The JAS checks a rep needs, with every money field stripped from the results by JAS itself.
- Allowlisted web research and tighter budgets.
How a request flows
The agent asks. The gateway decides.
The agent can write any code it likes in its sandbox. The only way from there to a platform is the gateway, a separate process under a separate Linux user, and the gateway is the security boundary.
- You askIn the assistant panel in VS Code, or out loud to the ring. Your server is reached over a private network from your own devices. Nothing on it is open to the internet.
- The agent worksIt reads the knowledge pack, asks JAS, and writes and runs code in a sandbox with no network of its own. It holds no production credentials.
- The gateway decidesWho is asking, whether they have budget, whether JAS can spare it, and whether JAS owns the thing being changed.
- You approveA write waits. The gateway shows its own rendering of the change, not the agent’s, and only your click releases it.
- It happens, as youIt goes out under your own sign-in, so the platform’s history shows your name, and one audit line records it.
Inside the gateway, every request
- who
- route
- budget
- JAS reserve
- ownership
- hold for approval
- filter
- audit
- send as you
The JAS connector
Every job, over MCP
The Job Adding System publishes its catalogue of read-only checks as an MCP server, the open protocol assistants use to call tools. They are the same Python checks behind the staff console’s Ask JAS, run over JAS’s own records, so a question never sets off a live call to the accounts, the CRM or the work boards.
34 tools, in six families
- One job
- finding it by the customer’s name, then its overview, timeline, why it’s stuck, installer and install details, forms, the signing pipeline, its CRM record and board item
- Applications and compliance
- network applications, meter requests, NMI status, compliance certificates, rebates
- Money
- deposits, invoices, the bill chaser
- Lists and reports
- signings, installs, the review board, breakdowns
- Automations
- health, runs, the schedule, what an automation does, exceptions
- Reference
- the glossary, and the time in Sydney
Four layers, so JAS is never hurt
- Behaviour. The workspace rules: plan before calling, a handful of checks per question, never fan out across sub-agents, never poll. Courtesy only, which is why three more follow.
- The gateway. One call at a time, a per-minute and a daily budget, and heavy checks count three times.
- JAS itself. Per-person and global windows, input caps, and refusals written for an agent to read: a normal tool error that names the limit and when to retry, never an auth failure it would retry.
- The operating system. The connector’s service is capped on CPU, memory and processes, so a busy morning on JARVIS cannot slow the automations.
Who is asking. Each server signs in with its own managed identity, which holds a single application role. JAS maps it to the person and checks them against the staff console’s allowlist on every call, so removing one line on the JAS side and restarting the connector cuts a server off at once.
How it gets there. The route reuses the edge that already fronts the staff console: a request must carry that server’s service token and come from that server’s address, or it never reaches production. No new software, and no network change on the production server.
What comes back. Structured verdicts, never free text: data for the agent to reason over, not prose it could mistake for instructions. Every call is audited against the person who asked, and sales reps’ results have every money field removed by JAS itself, so even a misconfigured gateway could not leak one.
The integration kernel
Ship the integrations, not the system
The clients JAS uses to talk to each platform are the most valuable code it has: more than a year of verified behaviour, from paging and retries to each platform’s quirks and rate limits. Every executive workspace gets exactly those, read-only, and nothing else.
What ships
- The platform clients: the CRM (with bulk query), the work boards, Microsoft 365 mail, files and sheets, accounting, field service and rebates, plus design and quoting and crew scheduling, read only.
- A Slack Web API client written to the same pattern. JAS only ever posted through webhooks, and full control of a person’s own Slack needed more.
- A transport shim that points every client at the gateway and drops its own sign-in. The gateway adds the person’s credential on the way out.
- A budget dry run, so a big pull can be costed against today’s allowance before it starts.
What stays home
- The automations and the business pipelines.
- The staff console and the MCP server.
- The infrastructure and the tests.
- Every token store and environment file.
A JAS release that changes a client becomes a JARVIS update: a new workspace pushed like a software update.
How a kernel is made
- Copy the listed modules from a pinned JAS commit.
- Point every client’s base URL at the gateway and strip its own authentication.
- Remove the writers only JAS’s automations use: invoice and contact creation in the accounts, task and material creation in field service, rebate lodgement.
- Generate the ownership rules from the same constants JAS uses, so the gateway refuses a write to anything JAS owns or listens to.
- Run the kernel’s tests against recorded responses.
- Scan for secrets, then seal it into a versioned bundle.
Approvals and budgets
Every write waits for a click
Held until approved
- The gateway holds the write and returns its own summary: the platform, the record, the exact text, the recipients.
- The person approves it in the panel, or on the ring’s card. A spoken “yes” never approves anything.
- One approval can cover a batch of up to twenty writes of the same shape, all shown in full.
- Writes are idempotent for fifteen minutes, so re-running a script after an approval does not write twice.
- Anything going to a customer is flagged first: an outside email address, a shared channel, a CRM comment that isn’t internal.
- No bot, no service account, no shared fallback. A per-person switch turns actions off instantly.
Budgets, so JAS keeps its share
- Every platform with a limit worth noticing gets a per-person budget, by the minute and by the day, costed in the platform’s own unit: a call, or Monday.com’s complexity points.
- Everyone’s budgets together must fit inside a fixed share of each pool JARVIS shares with JAS. The build fails if a profile change breaks that, so adding a person is a visible decision.
- The gateway reads each platform’s own remaining-quota counters and stops when a pool runs low, whoever spent it.
- Where a platform meters per app, JARVIS has its own registered app and draws on a pool of its own. Where it shares JAS’s key, it is read only and inside its share.
Security
A prompt is not a security control
Every hard control sits below the agent: Linux users, file ownership, the firewall and separate processes. The agent’s own rules sit on top, for good behaviour and a clean experience, not as the boundary.
Nothing worth stealing
The agent runs as an unprivileged user with no production credentials. Tokens live in the server’s own vault, reachable only through the server’s identity, and the firewall stops the agent’s user from reaching the metadata service that issues it.
One way out
Per-user firewall rules let the agent reach only the proxy, the gateway and the local resolver, all on the loopback. The proxy logs every destination and denies paste and webhook sites, and the shell runs in a sandbox whose only route out is the gateway.
Nothing to knock on
No inbound ports. SSH answers only on the private network, with keys only, and each person’s devices can reach their own server and nothing else. A server can start no connection to anything on that network.
Guardrails it cannot edit
The policy, the workspace and the gateway are root-owned and read-only to the agent. Bypass and auto-approve modes are switched off, only IT’s hooks and permission rules load, and every change to the policy files is logged.
Tested from the inside
A doctor command runs the negative tests as the agent user: reach the internet directly, reach the metadata service, read a secret, use sudo, write to the policy. Each one must fail, on every server, before anyone is onboarded.
Built like the rest
Bicep and cloud-init build the server; a versioned bundle and an idempotent apply step do the rest, so a rebuild is a deploy, not a rescue. Each server checks its packages against public vulnerability data every morning and its listening ports every five minutes.
Python • MCP • Azure • Bicep • cloud-init • Key Vault • Entra ID • Tailscale • nftables • Squid • systemd • Cloudflare Access • Azure AI Speech