DEV Community: Avidor Rabinovich

What an AI operating system actually is

Avidor Rabinovich — Fri, 31 Jul 2026 07:00:35 +0000

An AI operating system is the layer that decides which agent runs, on which data, and under whose approval. It is not a bigger model, and it is not a prompt library.

That sentence is the whole post. The rest is why it took a rewrite to say it that plainly.

The measurement that started this

We keep a list of ten questions we would like to be a correct answer to — things like what is an AI operating system and how do you govern an agent that touches production data.

We appeared in none of the answers.

The pages were not wrong. They were the wrong shape.

Why shape beats volume

A person reads top to bottom and forgives a slow opening. A retrieval system does not read your page — it looks for a span it can lift and attribute. A paragraph that opens with a story gives it nothing to take. A sentence that opens with a definition gives it everything.

The rewrite changed four things, and none of them were stylistic:

Open with the definition. First sentence, subject-verb-object, no throat-clearing. The test: if a stranger quoted that one sentence with no surrounding context, would it still be correct and complete?
A TL;DR above the fold. Three to five lines that stand alone if nothing else is read.
An FAQ in the reader’s words. The questions people actually type — not the phrasing your marketing uses for them.
Say what the thing is not. Negative definitions are unusually quotable, and they stop a model from filling the gap with someone else’s framing.

What the layer actually has to do

If you are building this rather than writing about it, two constraints did most of the work for us.

One path to the model. Every model call goes through a single seam instead of scattering across the codebase. Swapping a provider becomes a routing change rather than a rewrite, and you get exactly one place to log, cap, and refuse. Nothing running on our engine calls a model directly — that is the rule we hold ourselves to, not an aspiration.

A human signature on the decisions that cost money — how our regulated products are built, not a blanket claim about everything we ship. Agents can run an entire process and still stop at the one step a person must own. In a regulated workflow that constraint is what makes automation possible at all; it is not the thing blocking it.

Two honest caveats

This is one team’s rewrite, not a study. I have the before. The after needs enough indexing time to mean anything, and I will publish it whichever way it goes.
Answer shape is not a trick. If the page is not actually correct, making it quotable only makes the wrong thing easier to quote.

The canonical version of this piece lives on our blog: https://papyrus.synaptixlabs.ai/blog/ai-operating-system

If you want the wider context on what we build on top of this layer, that is at https://synaptixlabs.ai.

Inbound vs Outbound: The Two Postures of Agents-as-a-Service

Avidor Rabinovich — Wed, 22 Jul 2026 17:48:07 +0000

One of our agent crews reviews defense contracts. Another spends its days attacking a bank. They're the same kind of thing — and seeing why takes about three minutes.

A defense procurement contract lands: hundreds of pages of schedules, exhibits, and clauses that modify other clauses. A crew of AI agents reads it against a requirement checklist and hands back a ledger of verdicts, each one pinned to the exact passage that justifies it. Review work that took analyst-weeks comes back in hours.

Somewhere else in our portfolio, a different crew spends the afternoon attacking a bank. The bank is staged — a security-exercise scenario — but the work is real: one agent probes for weaknesses, another defends. No customer will ever meet either of them. That's the job description.

The first crew is a product. The second crew is staff. When people say "we use AI agents," they usually mean one of these two things without noticing there was a choice — and the difference matters more than the model, the framework, or the vendor.

Inbound: the crew is the product

The contract crew is Argus, our contract-intelligence proof-of-concept. Its user never sees an agent. They see a dossier: every requirement resolved to met, partial, or gap, and every verdict grounded in a discipline of three words — Requirement → Proof → Evidence. The multi-pass retrieval underneath, the clause assembly, the panel of three reviewer judges voting to consensus: all of it stays below the waterline. The user experiences a result.

That's the inbound posture. Agents power what the user experiences — an answer, an analysis, a document reviewed — and the crew is what's underneath. Argus earns far more than a paragraph, and next week it gets one: a full teardown. Hold that thought.

Outbound: the crew runs the company

Point the same machinery inward and you get the other posture. Outbound agents never touch an end user. They build, test, secure, and market the business itself.

Our public engine demo stages this side as red versus blue: CHIMERA, a red-team persona, probes a banking scenario for weaknesses while SENTRY defends it — a red agent on one model attacking, a blue agent on a different model defending, both orchestrated by the same conductor.

Vigil, our monitoring tool, works this posture in earnest. Its triage agent, vigil-router, runs cheap and fast on Groq's Llama 3.3, because high-volume bug triage should cost next to nothing. Its coding agent, vigil-coder, spends real money on Claude Sonnet, because code reasoning is worth the spend. Two agents, two models, two cost tiers — and zero end users between them.

One engine, facing both directions

Here's the move that makes this an architecture rather than a coincidence: both postures run on the same engine. Ours is Nexus, the harness above the vendors — one layer between the entire portfolio and eight model providers, built to enforce a single rule: no product calls an LLM provider directly.

Every request, whichever way the crew faces, walks one governed path — auth → KeyVault → agent catalog → 7-layer memory → system prompt → provider routing → SSE stream → SXC metering — and the two postures are that same path pointed at different consumers:

                       ONE GOVERNED ENGINE
       auth → keys → catalog → memory → route → stream → meter
                   │                         │
     ◄── INBOUND ──┘                         └── OUTBOUND ──►
     the crew IS the product          the crew RUNS the company
     the user sees a result           the user never appears

     Argus — contract verdicts        CHIMERA vs SENTRY — red-blue
     backed by evidence               drill on a banking scenario
                                      Vigil — bug triage + code fixes

The catalog is the steering wheel. Each agent is a database row, not code — the row carries its model and its cost tier — so when a better model ships, the swap is one row, and both sides of the company get the upgrade the same afternoon.

Two honesty notes, because the source pieces make them plainly. Nexus is a live internal substrate — deployed, load-bearing, the engine behind our own portfolio — not a public SaaS you can sign up for. And Argus doesn't run on it yet: every model call in that crew already funnels through one seam cut to match the engine's entry point, so graduating onto Nexus is a planned flip, not a rewrite. The Vigil agents are already catalog rows.

Most companies pick one by accident

Teams adopting agents usually land in a single posture and never notice the other exists. The inbound-only shop ships smart features while it still runs itself by hand. The outbound-only shop automates its back office while its product stays dumb. Neither is wrong. Both are half.

Run both on one governed engine and the halves start compounding: a sharper router, a deeper memory, a cleaner audit trail — each improvement lifts the products and the company that builds them at once. That duality is how a small team operates a whole portfolio, because the crews powering the products and the crews testing, securing, and marketing them are the same class of thing, built once, governed the same way. The full argument — what the engine is, and why governance is the half everyone skips — is in the flagship case for an AI operating system.

Next week: the teardown. We open Argus all the way up — how a crew of governed agents reviews a defense contract in hours, why the number-one retrieval failure is a vocabulary gap, and what it takes to back every verdict with evidence.

Originally published at Inbound vs Outbound: The Two Postures of Agents-as-a-Service on the SynaptixLabs blog.

Every Verdict Backed by Evidence: What That Actually Means

Avidor Rabinovich — Wed, 22 Jul 2026 17:41:29 +0000

Three minutes on the difference between a system that answers and a system that proves.

"Every verdict backed by evidence" sounds like a slogan. It's actually a specification — and once you see what it demands, you can't unsee which AI tools have it and which are just confident.

Start with what most people picture when they say "AI reviewed it": a bare, prompt-only chatbot. You paste in a document, ask a question, and get back a fluent paragraph. It reads well. It might even be right. But you have no way to know, because the answer arrives with nothing attached — no source, no trail, no way to check it short of doing the work yourself. Fluency is doing all the persuading, and fluency is a terrible proxy for being correct. A model can be articulate and wrong in the same sentence, and it will never tell you which one it's being. (Some chat tools now bolt on citations — a real improvement — but bolting on is not the same as building the whole system so evidence is the default path.)

An accountable review crew is built so that can't quietly happen. The difference comes down to four things a bare, prompt-only chatbot doesn't give you — and that make its claims checkable, not infallible:

Grounding. Every finding is tied to a specific passage in the actual source — not the model's memory of what such documents usually say, but this document, this line. The claim is anchored to the text, or it isn't made.
Citations. Each verdict carries the exact location its proof lives at, so anyone can open the source and see for themselves. The output isn't an answer; it's an answer plus the receipts.
An audit trail. Because the work is done by a crew of narrow agents — retrieve, assemble, judge, roll up — each step is a place you can stop and inspect. And when a panel rules on a finding, the record keeps the shape of the agreement: a unanimous call and a split call are not the same thing, and the trail says which it was.
Human-governed acceptance. The machine does the reading; the human keeps the decision. Every finding arrives pre-grounded precisely so a human reviewer can accept, reject, or challenge it on the merits — spending their judgment on judgment, not on scrolling. Nothing ships because the model felt sure.

Our defense contract-review product Argus makes this specification concrete — a real capability (redacted client, synthetic public walkthrough, built to graduate onto Nexus). It checks a requirement list against hundreds of pages and grounds every verdict along a fixed chain — Requirement → Proof → Evidence: what the checklist demands, the passage that satisfies it, and the exact place that passage lives. A reviewer panel rules, its consensus is recorded, and a human governs the acceptance. It pairs the published outcome — hours, not weeks — with findings you can open and check, so no one is asked to take its word for anything.

The reason this matters beyond one product is that evidence isn't a feature you bolt onto a chatbot — it's a property of how the system is built. It comes from running work through a governed engine, where grounding, citation, and human acceptance are the default path rather than an afterthought. That's the bet underneath everything we build: an AI you're meant to rely on has to be able to show its work, and showing its work has to be architecture, not a promise. Trust that can't be checked isn't trust. It's just tone.

The full teardown — how the Argus crew actually runs — is here: Argus: Reviewing Defense Contracts in Hours, With Every Verdict Backed by Evidence. The worldview it lives inside — one governed engine, many products — is here: The Case for an AI Operating System.

Originally published at Every Verdict Backed by Evidence: What That Actually Means on the SynaptixLabs blog.

Part 2 — Bring the Team, Not the Prompt

Avidor Rabinovich — Wed, 22 Jul 2026 17:40:52 +0000

Part 1 open-sourced our scaffold — the disciplined folder shape we start every agent-built project from. Inside it is a small crew of named agents. This post is about the part people ask about most: how that same crew shows up, unchanged, whether you open the project in Claude Code, Codex, Cursor, Gemini, or Devin.

Every tool wants its own rulebook

There's a snag waiting for anyone who uses more than one AI coding tool, and you hit it fast.

Each tool reads its instructions from a different place. Claude Code looks in a CLAUDE.md file and a .claude/ folder. Gemini wants a GEMINI.md. Cursor keeps optional rules in .cursor/rules/. Codex, Devin, and a growing list of others read AGENTS.md. Some of these overlap — but describe your "reviewer" role once and you've told one corner of your toolkit, not the rest of it.

So the same role ends up written down in four places. You improve the wording in one of them. The other three keep the old wording. Nobody meant for them to disagree, but now they do — they've drifted.

That would be a filing annoyance if a person were reading. It's a live hazard when an agent is. The agent opens whichever copy its tool happens to read, takes it as gospel, and acts — fast, across a dozen files, sure of itself. The rule it followed was the stale one, and you find out in the diff.

One brain, not five copies

The scaffold's answer is to stop keeping copies. One folder is declared the single source of truth: .claude/. That's the canonical brain — the roles, the doctrine, the step-by-step procedures, all in one place. When you want to change how an agent behaves, you change it there, once.

Every other tool's file stops being a copy and becomes a thin adapter: a pointer that says the real rules live over there, plus a line or two of local wiring — never the rules themselves. AGENTS.md, CLAUDE.md, GEMINI.md, the Cursor rules: each one points back to the same brain. Edit the brain, and every tool is already reading the new version.

And you don't have to trust that it stayed in sync. A script ships in the repo — scripts/check_adapters.py — and it runs in the project's CI on every push. It checks that each named agent still points at a real role, that every pointer resolves to a file that exists, that each tool's list of agents names the same crew, and that no adapter has quietly fattened up with a pasted-in copy of the rules. Any one of those failing fails the build. The consistency is a test that runs, not a promise you make.

One brain, five thin adapters — edit once, every tool already reads it.

Class, persona, and a name

Now the crew itself. It's built from two layers, and the order between them is the whole trick.

A class is the job. It's a binding contract — the mission, what's in scope, the lines it will not cross, and what has to be true before the work counts as done. The class is the part with teeth.

A persona is that class wearing a name. It adds a voice and a few personal instructions, and nothing more — it can't soften a verdict, skip the evidence, or quietly widen its own scope. One rule settles every conflict: class always wins. ARIA and "the design lead" can never disagree, because ARIA is the design lead with a name on. Each agent also answers to its class and an alias or two, so you can call it however comes to mind; every name resolves to the same contract.

The scaffold ships three of these, worked all the way through.

JANUS runs the cpto class. JANUS turns a fuzzy idea into requirements you can actually test, reviews the work when it comes back, and holds the release gate — the one who says ship or don't ship.

ARIA runs ux-design. ARIA owns how the thing looks: the direction, the design kit the front end is built from, accessibility, and the final call on whether the result matches the drawing.

CORE runs dev. CORE builds the feature across the stack — checking for something to reuse before writing anything new, writing tests, and verifying its own work before handing it back.

They pass work to each other by what the work needs, not by who feels like doing it. JANUS turns the idea into testable requirements. CORE implements them, with tests. JANUS reviews the result and decides whether it ships. ARIA owns the design; CORE builds it as drawn. Every handoff is a named step, not a vibe.

The same team, wherever you open the project

Here's the part that pays for the discipline.

That same crew — same names, same contracts, same boundaries — shows up in every one of those tools. You don't rewrite a prompt when you switch apps. You call the agent, and it loads the same contract wherever you are:

Tool	Call JANUS	Call ARIA
Claude Code	`/janus`	`/aria` (also `/uiux`, `/aria-uiux`)
Codex	`act as JANUS` (or `$janus`)	`act as ARIA` (or `$aria`)
Gemini CLI	`/janus`	`/aria` (or `/uiux`)
Devin	`@skills:janus` (or auto)	`@skills:aria`
Cursor	`act as JANUS …`	`act as ARIA …`

We've run this for real, not just drawn it. JANUS scoped and planned work inside Devin; ARIA reviewed the same design in Codex and again in Claude Code — the same role, the same rulebook, no rewrite in between.

One honest caveat: these tools run on different underlying models, so the exact words an agent chooses will shift from one to the next. What doesn't shift is the job — the same mission, the same boundaries, the same bar for done. You're carrying a governed team between tools, not babysitting a brittle prompt you re-tune for each one.

And because AGENTS.md is an open standard rather than one vendor's format, the crew reaches past those five. Any tool that reads it — Windsurf, Amp, Aider, and Zed among them — picks up the same team with no new adapter to maintain.

What's next

So the team travels. The rules travel with it, and a test keeps them honest.

In Part 3 we stop describing and start building. We hand this crew a real, small product and let it plan, build, and judge the thing end to end — so you can watch the whole loop run instead of taking our word for it. Swap the agent, keep the project; next, we build in the open.

Part 2 of 3. Grounded in the public *github.com/SynaptixLabs/scaffold** repo (v1.0, MIT).*

Originally published at Part 2 — Bring the Team, Not the Prompt on the SynaptixLabs blog.

Argus: Reviewing Defense Contracts in Hours, With Every Verdict Backed by Evidence

Avidor Rabinovich — Tue, 21 Jul 2026 14:41:02 +0000

Premiere of The Teardown — the show where we take one real product and open it up: what it does, how it actually runs, and where it honestly stands today. No demos-that-only-work-on-stage, no outcome we can't point at. First up: Argus.

Reviewing a defense procurement contract used to be a job measured in weeks. Argus does it in hours — and, more importantly, it can show you why it reached every conclusion it reached. "Hours, not weeks" is the headline. "Every verdict backed by evidence" is the part that makes the headline safe to believe.

This is the first episode of The Teardown, so the format is worth stating once: we pick a real product, we walk through the problem it solves, the crew that solves it, and the discipline that keeps it honest — then we tell you plainly where it stands, badges and redactions included. No product gets torn down here on the strength of a slide. If we can't point at the mechanism, it doesn't air.

The problem: a contract nobody has time to read the way it deserves

Start with the artifact itself. A defense procurement contract runs to hundreds of pages — dense, cross-referenced, and unforgiving. Buried inside it is a set of obligations the delivered work has to satisfy, and in the engagement Argus was built around, those obligations came to a structured requirement checklist of 79 rows — each row a specific thing the contract demands.

The review is the tedious, high-stakes part: take each of the 79 requirements, go find where in those hundreds of pages the contract actually addresses it, decide whether it's satisfied, and — this is the load-bearing bit — be able to prove the decision to someone who was not in the room. A human analyst can absolutely do this. It just costs weeks of concentrated attention, and manual review at that length carries real fatigue and consistency risk.

That's the shape of the problem: not "read faster," but check every requirement against the actual text, and carry the proof for every check. Speed without the proof is worthless here. Getting a wrong answer quickly is worse than getting a right answer slowly.

The crew: governed agents, each with a narrow job

Argus is built for the inbound, product-serving posture — the crew is the product. (Inbound and outbound are two postures on one runtime; Argus is the inbound side.) The user brings a contract and a requirement list and gets back a reviewed dossier; underneath, a crew of governed agents did the work. The design choice that matters is that it is a crew, not a single model asked to "review this contract." Each agent has a narrow, inspectable job:

Retrieval finds the passages in the document that bear on a given requirement — the smart search across hundreds of pages so a human isn't scrolling.
Assembly lines each requirement up against the specific clauses and passages that speak to it.
A panel of reviewer judges rules on whether the requirement is met — not one model's opinion, but several, so the dossier records the agreement behind each verdict rather than a lone call.
Roll-up turns the pile of individual verdicts into a gap analysis: what's covered, what's missing, what's ambiguous.

The reason to split the work this way isn't architectural fashion. It's accountability. When the work happens in one opaque pass, you get an answer and little to interrogate. When narrow agents each do one legible thing, and each step is instrumented, every part of the reasoning is a place you can stop, inspect, and check. The crew is designed to be audited, not just trusted.

The evidence: Requirement → Proof → Evidence

Here is the discipline that separates Argus from a chatbot that happens to be pointed at a contract. Every finding is grounded along a fixed chain: Requirement → Proof → Evidence.

Requirement — what the checklist demands (one of the 79 rows).
Proof — the passage retrieved from the contract that satisfies it.
Evidence — the exact location where that passage lives, so anyone can go verify it against the source.

Nothing is asserted into the void. A verdict you can't trace back to a specific place in the document isn't a verdict Argus is willing to record. And because the ruling comes from a panel rather than a single judge, the dossier keeps the shape of the agreement too: a unanimous call and a split call are not the same thing, and the record says which it was — a 3-of-3 verdict reads differently from a 2-of-3, and the reviewer treats them differently.

That is what "every verdict backed by evidence" actually means in practice. Not a confidence score the model made up about itself. A citation you can open. The output isn't an answer — it's an answer plus the receipts, arranged so a human reviewer can accept, reject, or question each finding on the merits. The machine does the reading; the human keeps the judgment. That division is the whole point.

The outcome — and the honest status

The register on the site is deliberately narrow: hours, not weeks. That's the outcome we stand behind, and we're not going to dress it up with numbers we can't show you. There is no published ROI figure, no customer count, no revenue claim attached to Argus — because none of those are ours to invent, and a teardown that pads its outcome is exactly the kind of thing this show exists to be the opposite of.

Two honest-status facts belong right here, in daylight:

The client is redacted, and stays that way. Argus was built around a real defense engagement, but the client's identity is not ours to disclose. The story has to carry itself on the mechanics, which is why we've spent this whole teardown on the mechanics. The client's identity never has to appear for any of it to be useful.
The public demo is a synthetic, fully-redacted walkthrough. What you can see publicly is not a real contract — it's an interactive, manufactured stand-in (drag to pan, click any requirement) that illustrates the same pipeline: how each requirement is graded Requirement → Proof → Evidence, confirmed by multi-reviewer consensus — without exposing a single real line of anyone's procurement. The capability is real; the public demo shows it on synthetic data, on purpose.

That's the state of it, plainly: a working system, a redacted client, a synthetic public demo, and one outcome claim we'll defend.

Why this is what SW-3 looks like

Step back from contracts for a second, because Argus is a clean instance of a larger shift.

SW-1 is the analyst reading all 79 requirements against all several-hundred pages by hand. Correct, careful, and measured in weeks.
SW-2 is that same analyst with a copilot — better search, a summarize button, faster typing. Genuinely helpful, and yet the analyst is still hand-carrying every requirement through the same pipeline. The bottleneck didn't move; the typing got quicker.
SW-3 is the arrangement Argus actually is: a governed crew does the deterministic, high-volume work — retrieve, assemble, judge, roll up — and the human does the thing only a human should, which is govern the verdicts and own the decision. Agents build the dossier; you accept the release. Every finding arrives pre-grounded so the human's judgment is spent on judgment, not on scrolling.

That's why "hours, not weeks" isn't a productivity tweak: the speed comes from reallocating the work, not just speeding up the human, and the evidence discipline is what makes that reallocation safe to trust. Two separate properties — Argus is built to carry both. Its agents are provider-abstracted behind a single seam today, and built to graduate onto Nexus, the Agents-as-a-Service engine — which is the reason the same evidence discipline can show up in the next vertical without being rebuilt from scratch.

If your version of this is messier

Most companies with an Argus-shaped problem don't have a clean 79-row checklist and a tidy contract. They have hundreds of pages of something — claims, filings, policies, spec sheets, tickets, case files — that a small number of experts read slowly and expensively, usually without a consistent, reviewable audit trail. That's the problem worth bringing us.

Bring us the messy version of it. We'll tell you honestly what's buildable — then shape our own engine and products into the solution, and run it with you. Not a slide, not a toolkit you wire together yourself. A crew that does the reading, grounds every verdict in evidence, and hands the judgment back to you.

→ See how we'd scope it: synaptixlabs.ai/services

That's the teardown. Next time, another real product — same rule: if we can't show you the mechanism, it doesn't air.

Originally published at Argus on the SynaptixLabs blog.