The lab · Tulip Labs
The science of agents that act.
Five programs, one question each: when may an agent assert, when may it act, how do you prove what it did, what does its code run on, and did it do well for the right reason — judgment. Each program publishes its method, ships its receipts, and states its status honestly.
Frontier labs train capability. We train Clusiana.
A multi-agent system is not one model reasoning. It is an orchestration loop of narrow decisions — which agent runs, which tool to call, what arguments to pass, whether a claim is grounded, whether the finished run went well. Those decisions are small, bounded, and constant — the regime where a small model beats a large one. Clusiana is our family of small, open-weight models, one for each of those decisions, all governed and all running on the open-source SDK.
01A large model plans; Clusiana controls
The open-ended reasoning stays on a general model — systems are planner-limited, and planning is where judgment lives. Around it, the Clusiana models handle the mechanics and the control decisions: route, select a tool, build its arguments, check the schema, verify the step, ground the claim, admit the action, judge the run. We never train the planner; we train everything that governs it.
02Small, because control runs in the hot path
A Clusiana model sits in front of every action, so it must answer in tens of milliseconds — and it often must run inside a regulated or air-gapped network where no data may leave. Small, open-weight, self-hosted models are not a compromise here; they are the requirement. They also cost an order of magnitude less than a frontier call, on decisions that happen constantly. In practice the family is a shared small base with lightweight per-task adapters — and plain code where a decision needs no model at all.
03The record is the training data no one else has
Every governed action — the decision, the policy, the outcome, and the human approval when there was one — lands on a tamper-evident record. That record is a labeled dataset of your own actions and judgments, and it specializes your Clusiana models to your world: the admission model gets sharper about your risky actions, the evaluator learns your definition of a good run. The audit trail you keep for compliance is also the flywheel that makes the models better. A framework or a frontier lab cannot have this data; it is yours. The bottleneck is data, not compute — and the record is the data.
04Not a better guard model — a governed, self-improving one
Excellent open guard models already exist, and we use the category. But they are generic filters, trained once, the same for everyone. Clusiana differs on three axes: specific to your tools and policy, self-improving from your record, and governed — a guard model flags a score; the runtime stops the action, holds it for a person when policy says so, and writes tamper-evident proof. Where a good open model already fits a task, we specialize it on your record rather than rebuild it. The moat is the assembly, not the weights.
Clusiana runs on the open-source SDK at tulipagents.ai — the foundation everything builds on — where the gate enforces each model and the record trains the next generation. The five programs below are how we get there — each one a Clusiana model, each with its status stated plainly.
When may an agent assert?
Mechanism. A claim counts only when the evidence behind it clears a set bar; below the bar the agent abstains, and the abstention is recorded with its reason. GSAR partitions an answer's claims into grounded, ungrounded, contradicted, and complementary, scores how well the whole is supported, and decides: proceed, regenerate, or replan.
Receipts. Published as GSAR (arXiv:2604.23366) and shipped in the runtime — the same scoring gates what a Tulip agent is allowed to conclude. Deep dive below.
When may an agent act?
Mechanism. Every consequential action passes an admission decision before it runs: allow, deny, or hold for a person. The decision is enforced by the runtime, not suggested to the model — a prompt can change what the model wants; it cannot change what the gate admits.
Receipts. The enforced allow / deny / hold gate ships in the runtime today. In progress: small open-weight action-risk classifiers to make the decision fast and learnable — with the dataset, the training recipe, and the weights released open, so the result can be checked rather than trusted.
How do you prove what an agent did?
Mechanism. What separates a record from a log: every decision and action lands on a hash-chained, signed trail, and verification fails on any edit. A log tells you what someone wrote down; a record is evidence that what it says happened, happened, in that order, untouched.
Receipts. The hash-chained, signed record ships in the runtime and is the spine through everything else the company builds. In progress: a canonical cross-language serialization spec, so a trail written in one language verifies in another.
What does agent code actually run on?
Mechanism. Defender-side research on the shared hardware underneath agents — starting with GPUs, where isolation is assumed more often than it is measured. This is the substrate research behind Clusiana: a cross-process GPU timing side channel that fingerprints a co-tenant's model from an ordinary, unprivileged process. It grounds where the Clusiana models run, and gave the family its name.
Receipts. Results reported with confidence intervals; two fixes merged upstream into vLLM; a self-audit tool ships with the findings so defenders can measure their own exposure. Deep dive below.
Did the agent do well, for the right reason?
Mechanism. Trajectory evaluation a risk owner can trust: did the agent complete the task, did it succeed for the right reason at the root, did it wander. Scored over the same tamper-evident trace the admission gate wrote — so a passing score is evidence about what actually ran, not a screenshot of a happy path.
Receipts. In development. Nothing to cite yet; when there is, it will appear here with its method.
A typed grounding layer: partition an answer's claims into grounded / ungrounded / contradicted / complementary, score the support, and decide — proceed, regenerate, or replan.
GSAR — grounded answer verification
When an AI draws a conclusion, is it actually supported by the evidence it cites?
Often not — every fact is real, but the conclusion over-reaches. GSAR measures that gap: it partitions an answer's claims into grounded, ungrounded, contradicted, and complementary; scores how well the whole is supported; and decides whether to proceed, regenerate, or replan — with six monotonicity and adversarial-robustness properties proven and locked under tests. It's published and peer-readable, and it's the engine behind the runtime: a finding ships only when its evidence clears the bar.
The substrate research — where Clusiana got its name
What can a neighbour learn about your model on a shared GPU? A timing probe of about a second, from an ordinary unprivileged process, distinguishes 46 model·engine classes — and crosses a MIG partition through the shared clock domain. Learning to identify a model on the metal is what led to training the small models that belong there.
# fingerprint an endpoint from its GPU timing — grounded by construction from tulip_integrations.compute import probe_to_finding finding = probe_to_finding("https://target/v1", provider="runpod") v = finding.verdict print(v.model, "·", v.engine, "·", v.hardware) # 7-8B class · vLLM (continuous-batching) · H100/A100 class
This is the substrate research behind Clusiana: a cross-process GPU timing side channel that fingerprints the inference engine and the language model running on a co-located GPU — no exploit, no privileged access. It grounds where the Clusiana models run — the shared, regulated, air-gapped environments that demand small self-hosted models — and identifying a model on the metal is the origin of the whole approach. Results are reported with confidence intervals and positioned against prior work. We publish the risk, the result, and the defense; the offensive method stays in the lab.
True to the defender-first rule, the single most useful artifact isn't the attack — it's a standard-library self-audit tool a defender runs on their own infrastructure to measure whether their workload is identifiable from a co-tenant. The finding was disclosed in coordination with NVIDIA's security team, and two fixes from this work are merged upstream into vLLM.
Scope, stated up front: this targets shared-GPU configurations where multiple unprivileged processes share one physical GPU (Docker --gpus all, MPS, some shared-tenant cloud offerings, WSL2). A dedicated single-tenant GPU — with no co-tenant to observe — is out of scope.
We practice coordinated disclosure, and we work defender-first: every security finding ships with something a defender can run today, and the offensive tooling stays in the lab. If our work touches a system you operate, or you believe you've found an issue in something we publish, reach us at [email protected]. We acknowledge reports promptly and work to a sensible timeline before anything goes public.