TL;DR - HockeyStack closed $50M from Bessemer Venture Partners, Y Combinator, and Uncorrelated Ventures to scale Revenue Agents — autonomous AI agents that work every deal and account 24/7 across new business, prospecting, and expansion. The interesting architectural choice: HockeyStack’s reasoning engine is not a frontier LLM. It is a proprietary ML model called the Blueprint that reverse-engineers each customer’s winning sales process from their event data. The LLM sits downstream as the execution and natural language layer. If you are designing a vertical agent, HockeyStack is the cleanest public example of an “ML brain, LLM executor” architecture — the inverse of what most teams ship.

What HockeyStack Actually Sells

HockeyStack started in 2021 as a B2B revenue analytics and attribution platform — the kind of tool that stitches Salesforce, HubSpot, ad platforms, Gong, and product data into one buyer journey so a CMO can answer “which campaign actually drove pipeline?” The founders — Emir Atlı, Arda Bulut, and Buğra Gündüz, the CEO — dropped out of college in Turkey, went through Y Combinator, and built the company into a Series A attribution vendor.

That is the company HockeyStack used to be. The company they are now is something different.

In April 2026, HockeyStack announced a $50M raise and the launch of “Revenue Agents for the Enterprise.” The pitch: per-deal autonomous agents that monitor every live opportunity against a learned pattern of how the customer’s own top reps win, execute the next-best action, and loop in the human rep when judgment is required. The customer list spans Fortune 100 revenue teams including 8x8, AppsFlyer, Outreach, Yext, and Sendoso, with over 300 customers reached in under two years.

This is a category bet: HockeyStack is positioning Revenue Agents as a new product category sitting alongside (or above) attribution, CRM, and revenue intelligence. The bet is architectural, and it is the part worth studying.

The Blueprint Is the Brain

The single most useful sentence on HockeyStack’s site is in their description of the platform: agents follow a “validated, data-grounded process.” Read past the marketing voice and notice what is not being claimed. The agent is not reasoning from first principles each turn. It is not asking an LLM “what should I do next on this deal?” and trusting whatever comes back. It is executing against a blueprint — a learned, structured representation of the customer’s winning sales process.

The Blueprint is HockeyStack’s proprietary ML model. Per their own description, it is built by analyzing every won and lost deal, every touchpoint, and every signal in the customer’s data to surface specific, validated patterns. Each Blueprint is unique to a revenue motion or business unit and updates continuously as new deals close and market conditions shift.

Crucially, the Blueprint is not a fine-tuned LLM. It is described as a machine learning model that continuously learns on new outcomes — an event-chain pattern-mining pipeline trained on the customer’s own deal history. The LLM enters the picture downstream: surfacing tasks in natural language to reps, generating outreach copy, and handling the human-facing surface. The reasoning about what should happen on a deal is the Blueprint’s job.

This inverts the dominant pattern in AI agent products. Most “AI for X” startups treat a frontier LLM as the reasoning engine and bolt on retrieval, tools, and memory around it. HockeyStack treats a domain-specific ML pipeline as the reasoning engine and uses the LLM as the execution and language layer.

Detail belongs in the prose, not the diagram. Three components carry the real weight.

Atlas: The Event-Based Substrate

Most CRMs are record-based: a deal is a row, with fields. HockeyStack’s foundation, called Atlas, is event-based: every interaction is a timestamped event resolved to one identity graph. Per their own product page, Atlas unifies every interaction into a single event-based timeline with full identity resolution — CRM, outreach sequences, call recordings, web activity, and the data warehouse all resolved to one time-stamped source of truth.

This matters because the Blueprint cannot mine winning patterns from flattened CRM fields. As contentgrip’s coverage of the raise observed, many meaningful buyer and seller signals are inherently event-like — web activity, product usage, conversation outcomes, buying-committee changes — and when those signals get flattened into static fields, teams lose the sequence, timing, and causality that define a winning play. An event-based model preserves them.

For builders, the lesson is upstream of agent design: if your reasoning layer needs sequence and causality (and most consequential agent decisions do), your data layer has to preserve them. You cannot retrofit event semantics onto a record-based store after the fact without losing fidelity.

Revenue Agents: Per-Deal, Always-On

The agent layer is where the Blueprint gets executed. HockeyStack’s framing: dedicated agents monitor every deal and account, execute the right moves autonomously, and flag risks, with individual Revenue Agents assigned to each deal and account, operating around the clock.

Concrete agent behaviors HockeyStack has shipped, per their agents page: identifying missing stakeholders and triggering outreach to unblock deals, detecting competitor dissatisfaction signals and launching displacement outreach, redistributing account attention based on revenue risk, and identifying when messaging stops converting. Each behavior is an instance of “deal deviates from the Blueprint pattern → agent acts.”

The reps interact with this through a surface called the Rep Cockpit — a daily workspace where agents surface direct tasks with reasoning. Senior leaders get separate Manager views for coaching and pipeline forecasting. This shape — agent surfaces work, human reviews and acts — is the same shape Rogo’s Felix uses with email as the substrate. Different surface, same async-handoff pattern.

HockeyStack also describes a multi-agent orchestration model: one agent retrieves data, another runs analysis, a third validates the output before the user sees it. The validator step is doing real work — it is the guardrail that catches the LLM hallucinating a stakeholder or fabricating an account fact before that error propagates into a rep’s outreach.

The Reverse-Engineering Bet

There is a strong claim underneath all of this, and HockeyStack states it plainly: your top performers run plays that live in their heads, and the Blueprint finds and deploys them across your entire team. The bet is that “what your best rep does” is a pattern recoverable from the event stream — not just tribal knowledge.

This is non-obvious. Sales has been resistant to standardization because the tacit-to-explicit conversion loses something. Whether HockeyStack’s pattern mining actually captures what the best reps do, or just captures the surface signals correlated with their wins, is the empirical question that will determine whether this category sticks. As one industry analyst noted in coverage of the raise, enterprises will look for clear proof that an event-based architecture improves forecast accuracy, sales productivity, or expansion conversion — not just that it produces more data. That bar has not been independently proven yet.

But it is the right bet to be making. If the architecture works, the moat is significant: every customer’s Blueprint is a one-of-one asset trained on their data, hard to rip out, and gets better as it ingests more deals.

Two Architectures for Vertical Agents

It is worth naming the two patterns explicitly, because they map cleanly onto a choice every vertical-agent builder is now making.

Pattern A — Frontier LLM as brain, harness around it. The reasoning engine is a frontier model. The vertical work is in the harness: tool layer, evals, output formatters, audit trail, data integrations. When a better frontier model ships, you swap the engine. Examples: most agentic platforms today, including the agent harness several finance and legal AI companies have publicly described.

Pattern B — Domain ML as brain, LLM as executor. The reasoning engine is a custom ML pipeline trained on customer data. The LLM handles natural language interfaces, generation, and tool calling. The vertical work is in the data pipeline, the pattern model, and the per-customer training loop. HockeyStack is the clearest public example.

Neither is universally right. Pattern A is faster to ship, benefits automatically from frontier-model gains, and is easier to swap. Pattern B is more defensible if your domain has rich event data and recoverable patterns, and it gives you deterministic behavior the LLM cannot match.

In Model Reliability Engineering terms: Pattern A invests heavily in Harness Engineering. Pattern B invests heavily in Context Engineering, taken to its logical extreme — the context isn’t just retrieved, it’s mined and structured into a deterministic decision pattern before the LLM ever runs.

What’s Actually Being Transformed

Sales orgs do not get replaced; their middle gets compressed. The classic problem HockeyStack is targeting — the best rep closes 2-3x more than the median, and nobody knows why — has been a fixture of sales leadership for thirty years. The traditional response was process documentation, MEDDIC training, and rep shadowing, and it did not close the gap because tacit knowledge resists capture.

If Revenue Agents work as advertised, what changes is not headcount; it is the variance band. New reps execute closer to top-quartile from week one because the agent surfaces the next move. Top reps spend less time on context-stitching (one HockeyStack customer testimonial cites three hours a day of cross-tool data wrangling eliminated, though this is vendor-curated and worth treating as directional rather than benchmarked) and more time on the relationship work that actually requires a human. Managers run pipeline reviews against a model rather than vibes.

The honest caveat: this is the promise. As of April 2026, the public evidence is the customer list, the funding round, and HockeyStack’s own product descriptions. Independent benchmarks of forecast-accuracy lift or expansion-conversion lift do not yet exist publicly. Buyers in this space should ask for them.

Five Lessons If You Are Building a Vertical Agent

1. Decide which brain you are building. Pattern A and Pattern B are different companies with different moats. Pick deliberately, not by default.

2. Event-based data preserves causality. Record-based data destroys it. If your agent needs to reason about why something happened, your substrate has to keep the sequence.

3. The validator agent is doing real work. Multi-agent orchestration with a dedicated check step is a cheap way to cut hallucination risk before output reaches the user.

4. Per-customer learning is a moat. Per-customer training is hard. A model that gets better as the customer uses it is structurally defensible — but only if you can run that loop without ongoing human curation.

5. Async surfaces beat new UIs. HockeyStack’s Rep Cockpit and Manager views, like Rogo’s email interface, surface agent work where the user already lives. Adoption follows the path of least friction.

What to Do This Week

Pick a workflow you have watched a domain expert do — one with rich, structured signals leading up to the decision. Now ask: could a small ML model trained on past instances of this workflow predict the right next action better than an LLM prompted with the same context?

If yes, you have a candidate for Pattern B. The investment is in the data pipeline and the model, not the prompt.

If no — if the signals are sparse, unstructured, or judgment-dominated — you are in Pattern A territory, and your work is in the harness around the frontier model.

The mistake to avoid is the third pattern: a thin LLM wrapper that pretends to be either. That is the architecture that gets disrupted next quarter when the next frontier model ships and removes whatever differentiation the wrapper claimed.

What ScienceClaw actually is

ScienceClaw + Infinite is an open-source multi-agent framework, released by MIT’s Laboratory for Atomistic and Molecular Mechanics in March 2026, where autonomous AI agents conduct scientific investigations across a catalog of more than 300 tools. Agents coordinate without a central scheduler: they broadcast unmet research needs and peer agents fulfill them through schema-matching on artifact types.

The system has three named components: an extensible registry of scientific skills, an artifact layer that preserves full computational lineage as a directed acyclic graph (DAG), and the Infinite platform — a structured space for agent-based scientific discourse with provenance-aware governance. The stack runs on top of OpenClaw, requires Node.js ≥ 22 and Python ≥ 3.8, and supports multiple LLM backends including Anthropic, OpenAI, and Hugging Face models alongside the default OpenClaw runtime. Once installed, agents run as a 4-hour heartbeat daemon — scienceclaw-heartbeat.service — that periodically scans for sessions to join, needs to fulfill, and findings to validate.

The paper presents four autonomous investigations: peptide design for the somatostatin receptor SSTR2, lightweight impact-resistant ceramic screening, cross-domain resonance bridging biology, materials and music, and formal analogy construction between urban morphology and grain-boundary evolution. The last of those produced a concrete output: a de novo Hierarchical Ribbed Membrane Lattice that, when validated with 3D finite-element analysis, resonates at 2.116 kHz and exhibits nine elastic modes in the 2–8 kHz band — relevant to acoustic filtering and bio-inspired sensing. Buehler reports that no human directed the cross-domain mapping, the gap identification, or the design generation.

The plannerless coordination loop

Most production multi-agent frameworks are orchestrator-based. A planner LLM decomposes the user’s request into subtasks, assigns them to agents, and either supervises execution or rewires the plan as new information arrives. AutoGen, CrewAI, and most LangGraph patterns sit in this family. The orchestrator is the throat through which all coordination flows.

ScienceClaw inverts this. There is no planner. Coordination emerges from three primitives: typed artifacts produced by every computation, a global index where agents broadcast unsatisfied information needs, and pressure-based scoring that biases attention toward high-impact directions.

The mechanic is straightforward. When an agent produces an artifact — say, a list of candidate peptide sequences — it is wrapped as an immutable, content-addressed record with typed metadata and parent lineage, then dropped into a shared store. When that agent hits a question it cannot answer with its own skills — say, ADMET prediction — it broadcasts the unmet need into the global index. Peer agents discovering this index during their own heartbeat cycles via the ArtifactReactor pick up matching needs, run the fulfilling skill, and post their result as another comment on the same Infinite thread, creating a growing, traceable conversation between agents that never explicitly assigned each other tasks. Schema-overlap matching does the routing: when one agent posts an artifact whose schema is a downstream input for another agent’s skill, the second agent detects the match implicitly.

If the pattern feels familiar, that is because it is. This is a modern blackboard architecture — the 1970s-era pattern where multiple knowledge sources read from and write to a shared substrate — re-implemented for typed LLM agents. Buehler describes it categorically as a pullback in category theory: distinct domains (biology, metamaterials, music) become categories of objects, the shared feature space is a functor, and the ArtifactReactor’s schema-overlap matching behaves like the universal object connecting them. That is a fancier way to say agents see each other through types, not orchestration.

Why this matters: where orchestrators break

Orchestrator-based multi-agent systems work well when the work is well-specified, the agent set is small and stable, and the planning context fits. They fall apart in the opposite regime.

As agent counts grow, the planner’s context bloats with state about every agent’s capabilities, current task, intermediate outputs, and dependencies. Plans get longer, the planner’s reasoning gets shallower per step, and small misroutings compound. Adding a new agent means changing the planner’s prompts or fine-tuning. Removing one means dependency repair. The planner becomes the channel through which all coordination passes — and the single point of contention.

Plannerless coordination shifts the harness. Instead of encoding routing in a planner’s prompts, ScienceClaw encodes it in the substrate: typed artifacts, schema matches, and pressure scores. Agents see each other through what they produce and what they need, not through a central agenda. An autonomous mutation layer prunes the expanding artifact DAG to resolve conflicting or redundant workflows, and persistent memory lets agents build on prior epistemic states across cycles. The result is an architecture that scales by addition: contribute an agent, contribute a skill, the swarm reorganizes around it without rewiring.

There is a second consequence worth pulling out. Every computation in ScienceClaw produces an immutable artifact with explicit parent lineage, accumulating in a directed acyclic graph that preserves the full provenance of every discovery. Provenance is what production AI teams typically bolt on as observability — a tracing layer wrapped around an existing system. Here it is the substrate. The DAG is the coordination medium and the audit log. You cannot have one without the other.

How agents actually select tools

The headline question for engineers reading this: how do agents decide which tools to call?

ScienceClaw’s answer is that there is no domain-to-tool routing table. The LLM analyzes the topic and selects three to five skills from the full catalog, with skills auto-discovered from the skills/ directory. The README is explicit: “No hardcoded domain → tool mapping — selection adapts to any research question.” Add a skill folder with a SKILL.md and the catalog picks it up.

The catalog spans roughly fifteen tool families covering the working set of a modern computational research lab. Sequence and structural biology are represented by BLAST, UniProt, and PDB; literature by PubMed and ArXiv; cheminformatics by PubChem, ChEMBL, RDKit, and TDC; materials by the Materials Project and NIST WebBook; plus general-purpose web search and data visualization. Each is a thin Python wrapper that exposes a uniform invocation surface. Agents reason about which skills apply, chain them, and produce artifacts at every step.

There is a separate, smaller decision the system makes at the social layer: role assignment. ScienceClaw exposes five roles — investigator, validator, critic, synthesizer, and screener — assigned based on skills and personality during session joining. Investigators explore. Validators independently re-verify findings using different tools. Critics challenge logic and propose alternatives. Synthesizers integrate disagreements. Screeners parallelize high-throughput work. Upvotes and downvotes require structured reasoning and citations; they are evidence-backed, not sentiment. Disagreement is preserved as validated, challenged, under review, or disputed rather than forced into unanimity.

This matters for engineers because role-plus-interaction-type is a different shape of coordination than control flow. You are not writing the workflow. You are writing the vocabulary the workflow uses to assemble itself.

The coordination loop, end to end

The co-ordination loop

The eight-step coordination loop runs without a central planner. Skill-based discovery, role assignment, and schema matching happen as side effects of the heartbeat — not as orchestrated control flow. The full loop and its four-layer implementation are documented in the README and the paper.

What’s actually shipped — and what to be careful about

The four investigations in the paper are real and worth reading, but the framing matters.

The peptide design investigation targeted SSTR2, a somatostatin receptor with established cancer relevance. The lightweight ceramic work was a screening pipeline. The cross-domain resonance investigation produced the Hierarchical Ribbed Membrane Lattice with the 2.116 kHz primary mode that I mentioned above, and validated the design with finite-element analysis. The urban-morphology-to-grain-boundary work built a formal analogy between two fields with no prior cross-citation. The paper’s core empirical claim is that across these four cases, the framework demonstrates heterogeneous tool chaining, emergent convergence among independently operating agents, and traceable reasoning from raw computation to published finding.

What the paper does not yet show is large-scale cross-institutional coordination. Buehler’s announcement describes ScienceClaw × Infinite as a swarm “across institutions, labs and the world”, and the architecture is built for it: anyone can deploy an agent or contribute a skill, the heartbeat runs 24/7 without a central coordinator. But the four investigations in the paper are produced by Buehler’s MIT team. The cross-institutional layer is a design property, not a demonstrated outcome — at least not yet.

The repo state confirms this is early. Five GitHub stars, four contributors, fifty-five commits at the time of writing. Posting to Infinite requires a minimum of 10 karma, which agents earn through commenting and voting before they can post — a sensible spam guard, but a reminder that the surrounding social layer is also under construction. There are rate limits: one post per 30 minutes, fifty comments per day, two hundred votes per day. This is a research artifact, generously open-sourced, that aligns with the broader DOE Genesis Mission’s stated goal of doubling the productivity and impact of American science within a decade, but it is not a production system.

That framing is also the right way to consume it.

The broader OpenClaw scientific ecosystem this sits inside is itself worth knowing about. A bioRxiv paper from late March 2026 catalogued 91 projects and 2,230 skills across 34 scientific categories in the OpenClaw scientific agent ecosystem, and ScienceClaw is one of the more architecturally distinct entries. The pattern across the ecosystem — skill-based agent design where workflows are expressed as structured Markdown files, lowering the barrier to contribution — is what makes the substrate-driven coordination model viable at all. Agents do not need to know about each other in advance because the skill catalog and the artifact types form a shared language.

What production AI engineers should take from this

The patterns transfer even if the framework does not.

Schema-typed artifacts as a routing primitive. The most portable idea in ScienceClaw is that the type of an artifact is the routing signal. If an agent produces a peptide_sequences artifact, any agent whose SKILL.md declares peptide_sequences as an input can pick it up. That removes a layer of planner reasoning. Production multi-agent systems can adopt this without going fully plannerless: type your intermediate artifacts, expose schemas as inputs and outputs, and let the substrate dispatch.

Provenance as substrate, not afterthought. Treat the artifact DAG as the source of truth for both coordination and audit. If your current observability is wrapping logs around an opaque LangGraph state, you are paying twice. ScienceClaw’s pattern — content-hashed, immutable, lineage-preserving artifacts dropped into a shared store — gives you a deterministic replay of any investigation, and the cost is mostly upfront design discipline.

Roles plus interaction types as coordination semantics. The investigator/validator/critic/synthesizer split is a coordination pattern, not a UI metaphor. You can implement it on top of any agent framework: tag each agent’s purpose, define a small interaction-type vocabulary (challenge, validate, extend, synthesize, request_help), and write your prompts to respect those roles. You will find that consensus and disagreement become legible in your traces in a way they typically are not.

Plannerless is not always the answer. Orchestrator-based architectures still win when the workload is bounded, the agent set is small, and latency matters. Plannerless coordination has overhead — the pressure scoring, the schema matching, the heartbeat cadence — and it works best when the work is open-ended and agents can be added or removed dynamically. Apply it where it fits.

If you want to experiment with these patterns without adopting ScienceClaw wholesale, the cheapest path is to add a needs board to your existing system. Let one agent post what it cannot do; let peer agents pick those needs up on their own schedule. You will learn whether plannerless coordination buys anything for your domain in about a week of work.

FAQ

Is ScienceClaw production-ready? No. Five GitHub stars, four contributors, an academic paper from March 2026, and a Vercel-deployed Infinite platform. Treat it as a reference architecture and a research artifact, not a runtime you deploy this quarter.

How is it different from CrewAI or other frameworks? Most frameworks use orchestrator-based coordination — a central agent decomposes work and assigns it. ScienceClaw uses plannerless coordination via the ArtifactReactor: agents broadcast unsatisfied needs and peers fulfill them via schema-overlap matching, without any planner assigning tasks. The closest analogue is a 1970s blackboard architecture, modernized for typed-artifact LLM agents.

Can I use Claude as the agent backbone? Yes. The repository documents Anthropic, OpenAI, and Hugging Face as supported LLM backends, with OpenClaw as the default runtime. Setup is via LLM_BACKEND=anthropic and the corresponding API key.

Does it actually produce real scientific results? The paper presents four investigations across peptide design, ceramic screening, cross-domain resonance, and urban-morphology analogy, and one of them produced a finite-element-validated metamaterial design with concrete acoustic properties. Whether those count as “real scientific results” depends on whether you mean novel publishable findings or experiments still pending wet-lab validation. The framework’s contribution is the coordination pattern; the scientific outputs are early demonstrations.

Should I read the paper or the repo first? The paper for the architecture and the experimental results. The repo’s ARCHITECTURE.md and the multi-agent examples in the README for the implementation patterns. Both fit in an afternoon.

Closing

The interesting question is not whether ScienceClaw will become the dominant scientific agent platform. It probably will not, on its own. The interesting question is what production AI engineers should port out of it before someone else does.

Type your artifacts. Make provenance substrate, not observability. Let agents post what they need rather than wait for a planner to figure it out for them. The coordination patterns ScienceClaw demonstrates are old ideas — blackboard architectures, tuple spaces, content-addressable artifacts — applied with discipline to the LLM-agent stack. They were good ideas in 1975 and they remain good ideas now.

If your multi-agent system has a planner that has become the most fragile component in your harness, ScienceClaw is the cleanest open-source reference you can read this month for what the alternative looks like. Read the paper. Skim the repo. Then go look at the planner in your own system and ask what would happen if you replaced it with a needs board, a type system, and a pressure score.

TL;DR - Auctor emerged from stealth in April 2026 with $20M led by Sequoia Capital to build an “AI-native system of action” for the messy, ~$500B/yr labor market of enterprise software implementation — the work that actually gets Salesforce, SAP, ServiceNow, or Workday running in a customer’s environment. Reading their public material with an architect’s eye, the interesting choice isn’t the agent loop or the LLM tuning. It’s the bet that artifact lineage is the load-bearing primitive: every user story, SoW, design doc, and Jira ticket is anchored in a graph that walks back to the discovery call that originated it. Frontier models are commodity; the project-scoped artifact graph compounds. If you’re building agentic systems for any domain where decisions accumulate across stakeholders over months — legal, healthcare RCM, B2B sales, regulated change management — study this pattern before you architect your context layer.

A real problem, sized correctly

Enterprise software only creates value when it’s actually deployed, and deployment is overwhelmingly a labor problem, not a software problem. Sequoia’s Julien Bek frames the ratio crisply: every dollar of enterprise software pulls roughly six dollars of services behind it. Across the top ten ecosystems — ServiceNow, Salesforce, SAP, AWS, and the rest — that adds up to about nine million implementation consultants and more than half a trillion dollars in annual labor spend, growing at a double-digit pace.

The work itself is brutal. A single deployment can span hundreds of requirements, dozens of stakeholders, and months of negotiation between what a business says it needs and what the platform can actually do. BCG’s 2024 study of more than 1,000 large-scale tech programs found that more than two-thirds miss their time, budget, or scope targets. Auctor cites their own statistics in the same vein: 50% of projects miss deadlines, and 1 in 6 exceeds budget by more than 200% — vendor-cited numbers, but directionally consistent with independent research. The interesting question isn’t whether implementation is broken. It’s whether the brokenness is structural — and if so, where the structural fix actually lives.

The architecture

Auctor’s framing is that implementation work is a context coordination problem, not a productivity problem. In a Q&A with Tercera, CEO Will Sun draws a distinction between three categories of enterprise software:

• System of record — the platform that holds data (CRMs, ERPs).

• System of work — the platform where work happens (Jira, Confluence, Asana).

• System of action — a platform that acts on the data, not just stores or displays it, while preserving the traceability and governance enterprise buyers require.

That last category is where Auctor positions itself. It’s a marketing term, but the technical substance behind it is real: rather than being a chatbot that surfaces documents from your existing systems, the system itself is the substrate where decisions accumulate, artifacts are generated, and downstream tools get synced. The company describes the loop in three layers — Capture, Contextualize, Create — which read like marketing copy until you realize each layer corresponds to a non-trivial engineering surface.

Here is what the artifact graph actually looks like inside an engagement, based on what Auctor has described publicly:

Artifact graph

The dotted line back to (A) is the actual product. The forward arrows are table stakes — anything with a decent prompt and a Confluence connector can generate a SoW from a meeting transcript today. The dotted line is where the engineering discipline lives.

Layer 1: Capture

The capture layer is the ingest plane. Auctor lists integrations with Google Meet, Microsoft Teams, Zoom, Gong, Outlook, Google Calendar, Slack, Confluence, Google Drive, OneDrive/SharePoint, Salesforce, HubSpot, Jira, Linear, Azure DevOps, Rally, and Certinia. Reading this as a list of features misses the point. Reading it as a topology of where implementation context lives is closer to right.

The non-obvious move here is that real-time meeting transcription is treated as a first-class source, not a bolt-on. Auctor’s own materials describe agents that join discovery and refinement calls, transcribe live, and pull context from past projects to steer the conversation. The Valiantys case study describes this concretely: instead of consultants taking manual notes during fifteen-stakeholder discovery sessions and consolidating afterward, requirements, action items, and meeting summaries are produced as the discussion unfolds.

That sounds modest until you think about what a “captured requirement” has to mean to be useful downstream. It has to:

• be timestamped and attributed to the speaker who voiced it

• be tagged with the stakeholder role that gave it weight (PMO, architect, exec)

• be linked to the meeting and the parent engagement

• be deduplicated against earlier captures of the same intent

• carry enough structure to be queryable later by an agent generating a SoW

This is the unglamorous schema work that turns “transcript + LLM” into something a delivery team can actually trust. Most teams underestimate how much of this is bespoke and how little of it is solved by a vector store.

Layer 2: Contextualize

The contextualize layer is where Auctor’s architectural bet shows up most clearly. In Will Sun’s own words, the very first capability he and his cofounders prototyped — the one that drew SI leaders in — was traceability. Not generation. Traceability.

The mental model he describes: a user story created months into a project should be walkable back to the original requirement, the SoW that scoped it, and the pre-sales conversation where the stakeholder first voiced the need. That walk has to survive consultant turnover, mid-project pod swaps, and the natural decay of “tribal knowledge” that erodes every long engagement.

There are a few engineering implications worth pulling out:

The graph is multi-modal. A node in this graph can be a transcript span, a section of a Word doc, a CRM field, a Jira ticket, a Confluence page, or a Slack message. Edges aren’t just “is-related-to” — they need to encode causal relationships (this requirement caused this user story to exist) and temporal ones (this requirement was superseded by that decision in last Tuesday’s call). Few off-the-shelf graph databases handle this cleanly without significant modeling work above them.

Project-scoped retrieval beats global retrieval. The Crossfuze case study describes Auctor’s account- and project-level repositories explicitly: queries are bounded to a defined scope rather than searching across everything the firm has ever ingested. This is a deliberate inversion of the “one big RAG corpus” pattern. For implementation work, it’s almost certainly correct — the consultant answering a Q in a SoW review wants context from this engagement, not the closest semantic match across 200 historical projects. Cross-project learning becomes a separate, opt-in surface — templates, playbooks, codified house standards — rather than something contaminating live retrieval.

Audit trail is the API, not a sidecar. Implementation buyers — especially in financial services, government, and healthcare — won’t trust an autonomous system unless they can ask, of any output, “what did this come from?” Bolting an audit log onto a generation pipeline after the fact rarely produces a satisfying answer. Designing the lineage as the primary data structure, with generation as a derived operation, is what makes the audit trail credible. This is the same discipline that production data engineering applies to lineage in dbt or feature stores; it’s still rare in agent systems.

Layer 3: Create

The create layer is where Auctor’s outputs land. Their own product page lists the artifact types: rough orders of magnitude, resource plans, statements of work, scopes, solution designs, process flows, user stories, and presentation decks. Each of these is a distinct generation problem with its own template, its own validation rules, and its own downstream sync target.

The interesting design decision is that generation is bounded by the project graph, not by raw model capability. A SoW draft isn’t generated from “what the model knows about SoWs”; it’s generated from the requirements, decisions, and constraints already in this engagement’s graph, with house-style templates from the SI’s own playbook layered on top. Crossfuze describes this as “first-pass content creation within clearly defined project contexts,” explicitly using Auctor for drafts that then go through their normal brand and review process.

That’s the right framing for any high-stakes generation task: the model produces a defensible draft, the human still owns approval, and the graph guarantees that nothing in the draft is stranded — every claim, number, and design decision can be traced to a source already in the system. It’s also a much better fit for fixed-fee delivery economics than “AI assistant pinging the consultant for help” — because the unit of work is the artifact, not the keystroke.

The harness, not the model

Sun is explicit on the model question: Auctor builds on frontier foundation models and tunes the system around how those models evolve, working with hundreds of consultants daily to know what works and what doesn’t. They are not building a foundation model. They are not even, as far as the public material reveals, fine-tuning one in a meaningful way. The bet is that the model is the commodity layer and the SI-specific harness — the schemas, the project-scoped retrieval, the artifact graph, the integrations, the templates, the governance — is where compounding value lives.

This is a defensible bet, and not just for Auctor. The same reasoning applies to most vertical agent companies: every six weeks the underlying model gets cheaper and stronger, and any architectural choice that depends on a specific model’s quirks decays with it. The architecture that compounds is the one that gets more useful with better models, because the harness was the durable artifact all along. The frontier labs themselves have been making versions of this argument in their own engineering writeups: the loop, the tools, the context curation are where engineering effort earns its keep, not the model behavior of any given week.

The corollary is uncomfortable for some founders: if your moat is mostly model behavior, you don’t have a moat. You have a temporary advantage on a clock you don’t control. Auctor’s choice to plant their flag on the graph instead of the model is, on its face, the more durable bet.

Governance is engineering, too

Auctor’s security page is more interesting than the average vendor compliance recitation, mostly for one detail: zero data retention with upstream AI providers, meaning customer inputs aren’t stored or logged by the underlying model providers and aren’t used for model training. For services firms whose customers include financial institutions, government agencies, and Fortune 500s, this is a precondition for sale, not a nice-to-have. The rest is what you’d expect from a startup chasing enterprise contracts: AWS infrastructure, AES-256 at rest, TLS 1.3 in transit, SSO/SCIM via Okta/Azure AD/Google, SOC 2 Type II, ISO 27001, and regional data residency.

The governance story matters because it’s the gating constraint on the whole architectural play. An audit trail is only as trustworthy as the platform’s ability to demonstrate its handling controls to a procurement team. The system-of-action framing falls apart if the action can’t be retrospectively justified to a regulator or an internal audit function. Sun makes this point explicitly in the Tercera Q&A: action without accountability fails.

What’s unproven

Worth being honest about what we don’t know from the public material:

The 80% efficiency claim is vendor-cited. Auctor reports “up to 80% efficiency gains across phases like discovery and design.” The number comes from the company and the customers it has chosen to highlight; there’s no independent benchmark, and “efficiency gain” is doing a lot of definitional work. Take it as directional, not as a measured productivity figure.

The architectural details are not public. Everything above is reverse-engineered from product copy, founder interviews, case studies, and integration lists. We don’t have a public technical writeup describing the schema, the graph implementation, the retrieval strategy, or the agent loop. There may be — and probably are — significant differences between the architecture as described and the architecture as built.

Implementation work resists templating. The harder question for any “system of action” is whether the work it’s automating is genuinely templatable at scale. SoWs and user stories sit on a spectrum: the boilerplate scaffolding is highly templatable, the load-bearing scope language often isn’t. Auctor’s own framing — first drafts, with human approval — implicitly concedes this. The interesting test will be how much of the high-judgment work survives at the human layer five years from now. Sequoia’s framing of “intelligence vs. judgement” is the right map here.

Category competition is coming. “Agentic operating system for SI work” is a defensible position today partly because nobody else is positioned exactly there. That window won’t stay open. Several adjacent categories — meeting intelligence vendors, services automation tools, project management platforms — are within a roadmap or two of overlapping capability. The artifact graph is a real moat if it stays project-scoped and integration-rich, but it’s the kind of moat that needs to keep deepening.

What builders should learn

Three patterns are worth pulling into your own architecture, regardless of vertical:

Make lineage the primary data structure. If you’re building an agent system in any domain where decisions need to be defensible — legal, finance, healthcare, regulated B2B — design the artifact graph first and the generation pipeline second. Walking from any output back to the source it depends on should be a single graph traversal, not a forensic exercise. Most teams do this backward: they build the loop, ship a feature, then bolt on observability when a customer asks why the model said what it said.

Scope retrieval to the engagement, not the corpus. Cross-project learning is a different surface from in-project recall. Conflating them produces retrieval that’s almost-right in a hundred subtle ways and consistently wrong on questions like “what did this customer decide last Tuesday?” Project- or account-scoped repositories solve a real problem cheaply.

Bet on the harness. If the part of your system that depends on the current state of frontier models is more than a thin layer, your roadmap is exposed to the next model release. The durable engineering — the schemas, the scoping, the integrations, the templates, the lineage — is what compounds while the model layer keeps shifting underneath.

These aren’t novel patterns in isolation. The novel thing is treating them as load-bearing rather than as polish. In a domain that has resisted automation for thirty years, that decision is the architecture.

Have you seen this pattern — lineage-first, harness-bet — in production agent systems outside the SI space? Reply and tell me what you’re building. I read every response.

Further reading

• Auctor product overview — the integration topology and the three-layer framing in the company’s own words

• Will Sun’s Q&A with Tercera — primary-source view on the system-of-action concept and the founding traceability bet

• Julien Bek, “Services: The New Software” — the strategic frame Auctor was funded against; useful even if you’re not in services

• Sequoia’s partnership announcement — Bek’s investment thesis on Auctor specifically

• BCG, “Most Large-Scale Tech Programs Fail” — the independent base rate for project failure that the whole category is sized against

  Thanks for reading! Subscribe for free

TL;DR - Mintlify just raised $45M at a $500M valuation on the bet that documentation has stopped being something humans read and started being infrastructure that agents query. Their own traffic data backs the bet: across 30 days and roughly 790M requests on Mintlify-powered sites, AI coding agents accounted for 45.3% of traffic versus 45.8% for browsers, with Claude Code alone generating more requests than Chrome on Windows.

Underneath the bet sits a three-part architecture worth studying. The write agent runs inside ephemeral Daytona sandboxes with a headless OpenCode session driven by Opus 4.6, triggered by Slack mentions, dashboard prompts, API calls, or YAML-defined Workflows in your repo. The read assistant does the opposite — it skips real sandboxes entirely in favor of ChromaFs, a virtual filesystem layered over their existing Chroma database, taking session creation from roughly 46 seconds to about 100 milliseconds. The public surface auto-generates llms.txt, llms-full.txt, and skill.md at the root, serves clean Markdown when you append .md to a page URL, and hosts an MCP server for every docs site it powers.

The architectural lesson isn’t that they built a doc agent. It’s that they built two harnesses with deliberately asymmetric constraints — async writes get full sandboxes, sync reads get a virtual filesystem — and the asymmetry is what makes the system economical at over 23 million queries a month. If you’re wrapping a model around a code repository for any reason, this is the reference implementation to study.

The 45% problem

Start with the data, because the architecture only makes sense once you accept the premise.

In April 2026, Mintlify’s co-founder Han Wang published a Cloudflare-header analysis covering 30 days of traffic across all Mintlify-powered docs sites. The headline number: AI coding agents had reached 45.3% of total requests, narrowly behind 45.8% from browsers. The distribution was lopsided. Claude Code alone produced 199.4M requests, ahead of Chrome on Windows at 119.4M. Cursor produced 142.3M. Together those two tools accounted for roughly 96% of identified AI agent traffic. Mintlify itself notes the real share is likely higher, since Codex traffic is invisible to user-agent header analysis and disappears into generic HTTP requests.

Architecture Patterns

If half your readers are agents pulling context to generate code, the design pressure on documentation flips. Browsers want navigation chrome, syntax highlighting, expandable sections. Agents want clean Markdown, exact strings, and stable URLs. The same content has to render correctly to both audiences, and — critically — has to stay current as the underlying product ships at agent-swarm speed.

That second pressure is the one that produced the agent stack. As Mintlify’s other co-founder Hahnbee Lee frames it, when a chatbot gives a wrong answer it is usually a documentation failure rather than a model failure, because the corpus the model retrieved against is out of date. The gap between what your docs say and what your product does compounds quarter over quarter unless something automated keeps the two in sync. Their answer is two distinct agents with two distinct harnesses, plus a public surface that exposes the maintained corpus to every other agent in the ecosystem.

Two harnesses, two latency budgets. The write path optimizes for capability; the read path optimizes for cost-per-conversation.

Layer 1 — The write agent: a sandbox is the whole product

Most “AI doc writer” features on the market today are roughly one prompt, one model call, one diff. Mintlify’s write agent is structurally different. When you trigger it — by @mintlify-ing the bot in Slack, hitting Cmd+I in the dashboard, calling the agent API, or merging a PR that fires a Workflow — what runs on the other side is a headless OpenCode session driven by Opus 4.6, scoped to a fresh Daytona container that has the docs repo and any context repositories cloned in. The sandbox is the unit of work.

This decision is more load-bearing than it sounds. The Mintlify team is explicit about the reasoning: pointing a stateless model at a codebase produces, in their phrase, “chaos with a byline”. The agent needs a real environment to read code, plan changes, and edit files safely — not an API call decorated with retrieved chunks. So they gave it one. A trigger lands on a job queue, a worker provisions the container, and the result of the run is reported back through GitHub commit checks and the Mintlify dashboard. Inside the container, the agent runs through a fixed pipeline: it pulls in relevant material across the docs and the connected code repos, drafts a multi-step plan if the work calls for one, applies edits while honoring the project’s writing standards, runs a local Mintlify CLI build to confirm the docs still compile, and opens a pull request — direct commits to main are not on the menu.

Two design choices inside that loop are worth pulling out.

Slack-first, not terminal-first. The Mintlify agent originally shipped only in Slack and via API, with the dashboard surface added later in December 2025. The team’s stated reason: opening a terminal triggers a “mentally draining switch” that opening Slack does not, and documentation work is exactly the kind of task people procrastinate on. By living where the relevant context already lives — the PR thread that explained the change, the customer Slack message that surfaced the gap — the trigger surface matches the source of the work.

Behavior-as-code through AGENTS.md. The agent reads a config file at .mintlify/AGENTS.md in your repo, and appends its contents to its system prompt for every task it runs — whether the trigger comes from Slack, the dashboard, or the API. The path matters: Mintlify’s docs explicitly warn that placing the file at the project root exposes it as a public asset under /agents.md, since the .mintlify/ directory is not served on the docs site. What you put inside is style preferences, code standards, project-specific terminology — the kind of guidance a senior reviewer would otherwise repeat fifty times a year. It is the same pattern as Anthropic’s CLAUDE.md or the AGENTS.md spec emerging across the agent tooling space, and it makes agent behavior version-controlled and reviewable.

The most interesting trigger surface is Workflows, where the YAML config gets explicit. A workflow file lives in your repo. The schema looks roughly like this:

---
name: 'Update API reference on backend changes'
on:
  push:
    - repo: 'your-org/backend'
      branch: main
context:
  - repo: 'your-org/docs'
  - repo: 'your-org/openapi-specs'
automerge: false
---

When the backend repo merges a PR, scan the diff for changes to public API
endpoints, request/response schemas, or authentication behavior. Update the
matching API reference pages and code examples. Skip internal refactors.

The structure is a trigger (cron job or push event), a list of context repos to clone in, an automerge flag, and natural-language instructions in markdown. When the trigger fires, the agent evaluates the conditions, runs the task, and either commits directly or opens a PR depending on configuration, so cost stays predictable. Documentation maintenance becomes a downstream event of shipping, not a separate task someone has to remember.

The whole arrangement maps onto a pattern emerging across serious agent products: give the AI a sandbox, version-control the instructions, keep humans in the review loop, and let the model do the actual work inside well-defined guardrails. The reviewer-on-PRs analogy is doing real work here. The agent is treated like a junior contributor with full repo access — capable, but reviewed.

Layer 2 — The read assistant: when a real sandbox is the wrong answer

If the write agent shows what it looks like to spend latency to gain capability, the read assistant shows the opposite trade-off — and it is the more architecturally surprising of the two.

The read assistant is the chat widget your readers use on a Mintlify-powered docs site. It now serves over thirty thousand conversations a day across hundreds of thousands of users. The natural design — and the one Mintlify started with — was the same shape that powers the write agent: spin up a sandbox, clone the docs repo, let the model run real grep, cat, ls, and find against the filesystem.

That design hit two walls. First, latency: p90 session boot time, including the GitHub clone and other setup, came in around 46 seconds — fine for an async write task where someone fires a Slack message and walks to get coffee, fatal for a reader staring at a loading spinner on a docs page. Second, cost. At nearly a million conversations a month, even a minimal sandbox setup at 1 vCPU, 2 GiB RAM, and a five-minute lifetime would have run north of $70,000 a year on Daytona’s per-second pricing, with longer sessions doubling the bill.

So the team built ChromaFs — a virtual filesystem that gives the agent the illusion of a real shell, layered over the Chroma database that already stored the docs as embedded chunks. Session creation collapsed from tens of seconds to roughly 100 milliseconds, and because ChromaFs reuses infrastructure they were already paying for, the marginal compute cost per conversation dropped to zero. The implementation runs on top of just-bash, a TypeScript reimplementation of bash from Vercel Labs that exposes a pluggable IFileSystem interface. just-bash parses commands, pipes, and flags; ChromaFs translates each underlying filesystem call into a Chroma query.

The mechanics are worth dwelling on, because they reveal how thoughtful harness design beats brute-force sandboxing.

The directory tree is bootstrapped from a single gzipped JSON document called __path_tree__ stored inside the Chroma collection. On startup, the server fetches and decompresses it into two in-memory structures — a set of file paths and a map from directories to their children. After that, ls, cd, and find resolve in local memory with zero network calls, and the tree is cached so subsequent sessions for the same site skip the fetch entirely. Per-user access control happens at tree-build time: ChromaFs prunes paths the user can’t see and applies a matching filter to all subsequent Chroma queries, with the result that pruned paths cannot even be referenced by the agent. Reading a page is a chunk-reassembly operation — cat /auth/oauth.mdx fetches all chunks with the matching slug, sorts them by chunk_index, and joins them into the full page. Writes throw EROFS, making the system stateless by construction.

The most clever piece is grep. A naive recursive grep over a virtual filesystem would be agonizing — every file would round-trip to the database. ChromaFs intercepts the grep call, parses flags with yargs-parser, and translates them into a Chroma query ($contains for fixed strings, $regex for patterns) that acts as a coarse filter to identify which files might contain a hit. The matched chunks are bulk-prefetched into a Redis cache, and the rewritten grep is handed back to just-bash for in-memory fine filtering. Large recursive queries finish in milliseconds.

Sitting beneath ChromaFs in the read path is Trieve, the RAG infrastructure company Mintlify acquired in July 2025. Trieve had been Mintlify’s search backbone since before the team finished its Y Combinator batch, and the acquisition brought retrieval ownership in-house at a moment when the assistant was already serving more than 23 million queries a month. Trieve’s stack — dense vector search, re-ranker models, sub-sentence highlighting, and date recency biasing on a single endpoint — does the heavy lifting underneath ChromaFs’s UNIX-style interface. Trieve also moved to an MIT license as part of the acquisition, so the same retrieval kernel is inspectable on GitHub.

The pattern in the read assistant is the part most teams underweight. Mintlify’s team observed that agents are converging on filesystems as their primary interface, because grep, cat, ls, and find are sufficient primitives for an agent to reason over arbitrary structured content. Most builders take that observation and reach for a real sandbox. Mintlify took the same observation and asked whether the interface could be virtualized while keeping the primitives real. For their workload, the answer was yes — and the cost curve in their post (sandbox cost grows linearly with conversation duration; ChromaFs stays flat) is a clean argument for why.

Layer 3 — The public surface: content negotiation as the unification trick

The third layer is the cheapest to describe and the easiest to overlook.

Every Mintlify-hosted docs site automatically generates a set of agent-readable artifacts at the root: llms.txt, llms-full.txt, and skill.md. The first two are an emerging convention for telling LLMs what content lives on a site and giving them a parseable bulk dump. The third is more interesting. As Mintlify describes it, skill.md is the action-layer manifest — it enumerates not just what the documentation contains but what an agent can actually invoke against the product, with required inputs and operating constraints attached to each capability. It is, in other words, the difference between an agent that can find information and an agent that can take action. Mintlify also exposes the /.well-known/agent-skills and /.well-known/skills paths — so any agent that knows the convention can find capabilities without hard-coded paths.

The unification trick that ties everything together is content negotiation. The same URL serves rich HTML to browsers and clean Markdown to agents — appending .md to any page URL returns a Markdown view of the same content, with no separate agent-facing site to maintain. This avoids the failure mode where teams maintain a “human site” and a separate “AI site” that drift out of sync; there is only one content store, with two rendering targets selected by the request.

Finally, every Mintlify site auto-hosts an MCP server, which lets coding agents like Cursor, Claude Code, and Windsurf query current documentation while a task is running. Authentication is supported when the docs site itself is gated — the MCP server respects whatever auth protocol the docs already use. The architectural significance is that retrieval is no longer something only the docs site itself can do. Every external agent that supports MCP gets a structured handle into your corpus, on the same terms as Mintlify’s own assistant.

What the architecture teaches

A few patterns are general enough to lift out of Mintlify’s specific case and apply elsewhere.

First, the sandbox is the unit of work for write tasks, but the wrong unit for read tasks. Most builders default to one or the other. Mintlify’s own bill clarifies the trade-off: a sandbox that boots in tens of seconds and costs a fraction of a cent per session is fine for asynchronous PR drafting, and ruinous for a chat widget. If you’re building both surfaces, expect to want both harnesses.

Second, version-controlled, natural-language instructions are the right encoding for agent behavior. Workflows YAML and AGENTS.md are the same idea applied at different scopes — one configures a recurring task, the other configures the agent globally. Both live in the repo, both go through code review, both evolve with the project. This is what “config as code” looks like when the configured component is a model.

Third, virtualizing the agent’s interface, not its environment, is often the better move. ChromaFs is the cleanest example: a real grep, a real ls, a real cat — but resolved against a database, not a disk. The agent doesn’t need a sandbox, it needs the sandbox’s API. Once you internalize that, a lot of “we need a Daytona for this” becomes “we need an IFileSystem shim for this,” with two orders of magnitude less infrastructure.

Fourth, content negotiation is the right unification primitive when you’re serving humans and agents from the same corpus. Maintaining parallel “human docs” and “AI docs” is how you guarantee they drift. Same URL, different format, selected by the request — and the cost of supporting the agent surface drops to near-zero.

Finally, harnesses are not edge cases, they’re the product. If you remove ChromaFs from the read assistant, the bill blows up. If you remove the sandbox boundary from the write agent, you stop being able to safely run on customer codebases. If you remove the auto-generated llms.txt and MCP server, the 45.3% of agent traffic loses its grip on the corpus. The model is doing model work in the middle, but everything around it — the sandbox, the virtual filesystem, the YAML triggers, the public surface — is what makes the product trustworthy and economical.

What to do with this

Three concrete moves for practitioners building anything adjacent to this space.

If you operate a documentation site, run it through Mintlify’s free Agent Score tool, which checks twenty-nine signals of agent-readability and tells you where the gaps are. The data is right there: half your traffic is agents you cannot see, and most teams are still building only for browsers. If you’d rather audit on your own, start by checking whether curl -L https://yourdocs.com/some-page.md returns clean Markdown or a 404 — that one HTTP request tells you whether you’re on the agent map at all.

If you’re building any agent that needs to read or modify a code repository, start with the harness, not the prompt. Decide your latency budget before you decide your model. If the answer is “tens of seconds and the agent edits files,” the Mintlify write agent — sandbox, headless OpenCode, version-controlled config — is your reference. If the answer is “milliseconds and the agent only reads,” the ChromaFs pattern (virtualize the interface, not the environment) is your reference.

And if you’re shipping a product that other agents will need to understand — an API, an SDK, a developer tool — treat your documentation as a programmatic interface that happens to also be human-readable. Auto-generate llms.txt and skill.md, expose an MCP server, serve clean Markdown via content negotiation. The asymmetric world Mintlify is betting on already exists. The teams whose docs are agent-readable get evaluated. The teams whose docs aren’t get skipped.

TL;DR - In regulated verticals — healthcare, legal, insurance, finance — the most reliable way to make a deployed agent better is not a new model. It is a closed loop that turns production failures into harness updates: prompts, tools, sub-agents, memory files, judge rubrics, routing logic. Harvey ran this loop on twelve legal tasks and moved average success from 40.8% to 87.7% with model weights frozen, with complaint drafting going from 2% to 98% rubric coverage. Hippocratic AI vendor-published clinical accuracy improvements from ~80% pre-Polaris to 99.38% in Polaris 3.0 by feeding ~1.85M real patient calls and 307K clinician-reviewed test calls back into the system. Anterior (vendor-published) puts a reference-free LLM-as-judge in front of every prior auth decision, routes only the low-confidence ones to under ten clinicians, and reports 96% F1 at over 100K decisions/day. Microsoft’s Azure SRE Agent moved its Intent-Met score from 45% to 75% on novel incidents by letting the agent investigate its own bugs and submit PRs against its own codebase. The shared pattern is the same six nodes everywhere: trace → judge → cluster → mutate harness → gate → deploy. If you cannot run that loop, you are shipping a frozen artifact in a moving market. Start by instrumenting traces and writing one rubric. The judge and the mutation loop come after.

The frozen-agent problem

A vertical agent that ships at 90% accuracy and stays there is not a 90% accurate system. It is a 90% accurate system at the moment of deployment, decaying.

The decay has three sources. Distribution drift: real patients ramble, real lawyers redline contracts in non-canonical ways, real claims arrive with new denial codes. Policy drift: CMS coverage determinations change, EU AI Act provisions phase in on staggered enforcement timelines, insurer rulesets get rewritten quarterly. Long-tail surface area: the failure modes you didn’t see in eval are the ones production discovers, one in ten thousand at a time. At 100K medical decisions per day, a one-in-ten-thousand subtle hallucination — “suspicious for multiple sclerosis” when the patient has a confirmed MS diagnosis — fires ten times daily.

Agent Improvement

In low-stakes consumer apps you can absorb that. In a vertical where the cost of a single error is a denied surgery, a missed disclosure schedule, or a regulatory finding, you cannot. So the question that defines vertical agent engineering in 2026 is not “which model do we use” — it is “how does this agent get better next week than it is today, without a new base model release, and with the audit trail a regulator will demand.”

The answer that has emerged across legal, healthcare, insurance, and incident response is the same architecture, sometimes given different names. Anthropic’s engineering team and Viv Trivedy refer to it as harness engineering. Microsoft frames it as the agent investigating itself. NVIDIA borrows MAPE-K from autonomic computing and calls it a data flywheel. LangChain calls it the agent improvement loop powered by traces. The mechanics are the same.

The shape of the loop

The loop

Six nodes. Every component carries weight; every break in the chain causes silent degradation.

Production traces are the substrate. Without per-step tool calls, model inputs, model outputs, latency, token counts, and final outcomes, none of the downstream work is possible. LangChain’s formulation is the cleanest: traces come from staging environments, benchmark runs, local development, and especially from production, and they are the input to every subsequent step. The trace store doubles as the audit trail regulators ask for.

Evaluation and judging is where most teams over-rely on offline benchmarks. The shift in 2025–26 has been toward online evaluators that score every production trace — typically an LLM-as-judge augmented with deterministic checks (schema validation, citation existence, tool-call shape) and routed human review on a configurable sample. Anterior’s framing is sharper than most: their judge is reference-free, scoring outputs against guidelines and clinical reasoning rather than a held-out ground truth, because the volume — over 100K decisions a day — makes ground truth impossible to maintain.

Failure clustering is where the leverage is. A pile of low-scored traces is not actionable. Grouping them by failure pattern — “agent missed exhibit B in 30% of due diligence runs,” “agent emits ‘suspicious for X’ on confirmed-X patients,” “agent hits LLM 429s during streaming” — turns symptoms into hypotheses. LangChain runs parallel error-analysis subagents and synthesizes their findings into harness change proposals. Microsoft’s SRE Agent runs a daily monitoring task that searches the last 24 hours of errors, clusters the top hitters, traces each to its root cause, and submits a PR.

Harness mutation is the change itself. We will spend a section on the levers that actually move; for now: most of these changes never touch model weights. They edit the system prompt, add a skill or sub-agent, modify a tool definition, append to a memory file, tighten a routing threshold, or rewrite the judge’s rubric.

Validation gate is the hill-climbing safety. Every proposed harness change runs against a frozen eval set before it ships, and any regression — even on a task the change was not targeting — blocks the merge. Harvey runs this against twelve internal benchmark tasks per iteration; LangChain marks proposed changes that overfit as discarded runs in their iteration log. Without the gate, the loop generates regressions as fast as it generates improvements.

Deploy then closes the cycle. The new harness produces new traces; new traces feed new judges; new clusters drive new mutations. The model is the one piece of this picture that does not change between weekly cycles.

The non-obvious property of this loop is what compounds. As Anterior describes it, the loop creates a virtuous improvement cycle where the evaluator itself gets calibrated against human review, and confidence grades from that calibrated evaluator route which cases need humans next time. The judge improves. The clustering improves. The mutations get more targeted. The agent appears to learn — without a single weight changing.

Case 1: Harvey — autoresearch and the rubric ceiling

The cleanest published demonstration is Harvey’s recent autoresearch experiment, summarized externally by Artificial Lawyer. Niko Grupen, Head of Applied Research, ran twelve tasks from Harvey’s internal agent benchmark — commercial lease review, complaint drafting, tax memos, disclosure schedules, due diligence questionnaires — through a loop where an outer agent is allowed to edit the inner agent’s harness based on rubric-graded judge feedback.

The setup: each task ships with source documents, instructions, and a detailed grading rubric. After an attempt, an LLM judge scores against the rubric and produces written feedback on what the agent got right, what it missed, and where its reasoning was wrong. A coding agent reads the judge feedback, clusters the failures, forms a hypothesis about which harness components would help, edits or builds those components — skills, hooks, scripts, sub-agents, not model weights — and reruns.

The result: across all twelve tasks, average success rose from 40.8% to 87.7%. Five of the twelve started in the 2–7% range. After optimization, seven exceeded 90% and one hit 100%. The complaint drafting task is the most striking — it moved from 2% rubric coverage to 98% over a handful of iterations, producing a 164-paragraph complaint with a 33-exhibit list.

Two patterns from Grupen’s log are worth quoting on terms. First, the early iterations correct basic structural failures — wrong file types, missing deliverables, weak structure. Later iterations show domain-specific expertise emerging: cross-document issue spotting, risk classification, distinguishing genuinely problematic provisions from market-standard distractors. Second, the ceiling is the rubric. “When the rubric is high quality, the agent can hill-climb surprisingly far.” When it isn’t, the loop stalls.

This generalizes. The same auto-improvement pattern works in a generic coding domain: LangChain’s deepagents-cli moved from 52.8% to 66.5% on Terminal Bench 2.0 — a 13.7-point jump from harness changes alone, with the model fixed at GPT-5.2-Codex. The mechanism is the same trace analyzer skill, parallel error agents, and targeted prompt/tool/middleware changes per iteration.

The Harvey caveat is real and worth surfacing: this is a vendor-run experiment on twelve tasks; it does not yet generalize to all legal work, and it is bound by the quality of the rubrics Harvey wrote. But the directional finding — that harness-layer changes can deliver model-upgrade-sized improvements in a regulated domain — is now hard to dismiss.

Case 2: Hippocratic AI — clinicians as a learning signal at scale

Hippocratic AI’s Polaris is a different shape of the same loop, scaled to a 22-LLM constellation that handles over 10 million real patient calls and a network of 6,234 US-licensed clinicians who review production output.

The vendor-published trajectory across three model generations: pre-Polaris baseline ~80%, Polaris 1.0 at 96.79%, Polaris 2.0 at 98.75%, Polaris 3.0 at 99.38% clinical accuracy, validated under their Real-World Evaluation of Large Language Models in Healthcare framework. The framework leverages 6,234 US-licensed clinicians (5,969 nurses and 265 physicians) evaluating 307,038 unique calls through a three-tier review process: nurse review first, physician adjudication when needed, structured error categorization in between. Errors flagged at any tier feed back into the next iteration’s training and harness.

The subsystem-level numbers tell the more interesting story, because they show what specifically improved between Polaris 2.0 and 3.0 by listening to production:

• Health Risk Assessment documentation accuracy: 90.5% → 98.5%

• Explanation-of-Benefits policy quoting: 86.4% → 99.4%

• Complex appointment scheduling error rate: 8% → 0.5%

• Background-noise speech recognition error rate: 9.3% → 2.3%

• Clarification engine error rate (gracefully handling unclear patient speech): 16.3% → 2.0%

These aren’t random improvements. They’re the long-tail issues that surfaced once 1.85M patient calls had run through Polaris 1.0 and 2.0 and clinicians had flagged categorical failure modes. Speech recognition fails in noisy environments → train a dedicated background-noise engine. Patients answer HRAs in rambling, context-shifting ways → ship a “deep thinking” model that triple-checks documentation. Policy quotes occasionally drift from source documents → tighten the harness around source attribution.

The honest framing: these are vendor-self-published numbers, and there is no independent third party validating Hippocratic AI’s safety scores. What is independently verifiable is the architecture of the feedback loop — clinician review network, structured error categorization, real-world evidence accumulation across versions — which is now described in the underlying RWE-LLM paper on medRxiv and is replicable by anyone willing to invest in a comparable review apparatus.

Case 3: Anterior — judge first, route smartly, validate the validator

Anterior runs the same loop in healthcare prior authorization, but with two design choices that are worth studying separately because they generalize beyond healthcare.

First, reference-free real-time evaluation. Anterior’s primary system makes a coverage determination by reasoning across unstructured clinical documentation, payer rulesets, and clinical guidelines. A second LLM-as-judge then evaluates the determination against those same guidelines — without needing a held-out ground truth — and produces a confidence grade. Reference-free evaluation matters because at 100K+ decisions a day, no organization can maintain a labeled gold set that keeps up with policy drift.

Second, dynamic case prioritization. The confidence grade combines with contextual factors — procedure cost, bias risk, historical error rates for that procedure category — to decide which cases are sent to human clinicians for review. High-confidence cases auto-resolve; low-confidence and high-stakes cases route to a small clinical team. Anterior reports a team of fewer than ten clinical reviewers handling tens of thousands of cases, against a competitor reportedly employing 800+ nurses for comparable review volume. (Caveat: scope of work may differ. Take the comparison directionally.)

The third move is the one most teams miss. Anterior runs alignment metrics between the LLM-judge and the human reviewers on cases that get both, and uses that data to validate — and continuously recalibrate — the judge itself. They call this “validating the validator.” It is the missing piece in most LLM-judge deployments. Without it, the judge can drift, and you only learn about it when the harness has been mutating against bad signal for weeks.

Anterior’s vendor-reported numbers: 99.26% accuracy on automated approvals, against 86% baseline human accuracy, with 76% reduction in human review needed and 74% less time per escalated case. Cross-reference with Anterior’s own arXiv paper on fairness evaluation, which reports model error rates across 7,166 human-reviewed cases spanning 27 medical necessity guidelines. Independent validation remains an open need; the 96% F1 figure that has circulated comes from Anterior’s own talks, not a peer-reviewed audit.

The architectural lesson generalizes far past healthcare. Any vertical agent operating at scale where ground truth is expensive — fraud review, AML, KYC, contract triage, claims adjudication, security alert triage — can adopt the same three-part move: reference-free judge in line, dynamic routing on confidence and stakes, alignment metrics that validate the judge against the humans that exist.

Case 4: Azure SRE Agent — when the agent debugs itself

Microsoft’s Azure Site Reliability Engineering Agent handles tens of thousands of incidents weekly for internal Microsoft services and external teams. The team published a remarkably honest engineering retrospective in March 2026 about how they closed their improvement loop.

The starting point: incident resolution rates were climbing toward 50% on high-instrumented scenarios — but the high-performing scenarios all shared a trait. They had been built with heavy human scaffolding: custom response plans, hand-built sub-agents for known failure modes, pre-written log queries exposed as opaque tools. On any new incident class, the agent had nowhere to start. Engineers were reading 50 lower-scored threads a week against an agent handling 10,000 — debugging at human speed.

The inversion they made: stop pre-computing the answer space. Instead, give the agent a filesystem as its world (source code, runbooks, query schemas, past investigation notes — all files; no SearchCodebase API), context hooks that orient it on what it can access, and frugal context management that keeps long investigations sharp. Three architectural bets, in their words. The result: Intent-Met score on novel incidents — whether the agent’s investigation actually addressed the root cause as judged by the on-call engineer — rose from 45% to 75%.

The closing move is the one to study. They set up a daily monitoring task: the agent searches the last 24 hours for LLM errors — timeouts, 429s, mid-stream failures, malformed payloads — clusters the top hitters, traces each to its root cause in its own codebase, and submits a PR. Engineers review before merging. Over two weeks, errors dropped by more than 80%.

The agent, in other words, became its own debugger. The harness that runs the SRE agent is now updated by the SRE agent itself, gated by human PR review. The team’s framing is the title of their post: “The agent that investigates itself.” It is not a metaphor.

What actually changes (the levers)

The most under-appreciated property of these loops is what they mutate. Across every case study above, the changes that produced the gains were:

The system prompt and task instructions. ILWS, the “Instruction-Level Weight Shaping” framework, formalizes this: a session-level reflection engine proposes a structured edit to the system prompt — a knowledge delta — that is gated, accepted only if a sliding-window quality rating improves with statistical significance, and rolled back otherwise. Most production teams do this informally. Formalizing it gives you reversibility under governance, which regulators ask for.

Tool definitions and skills. LangChain’s improvement was largely middleware: a LocalContextMiddleware that maps the working directory and onboards the agent into its environment, a LoopDetectionMiddleware that intercepts repeated edits to the same file and forces a plan reconsideration, a PreCompletionChecklistMiddleware that blocks the agent from exiting before it runs a verification pass. None of these are model changes. All are tool-and-hook surface.

Memory and knowledge files. Microsoft replaced their RAG-over-past-sessions memory with structured Markdown files the agent reads and writes through its standard tool interface — overview.md, team.md, logs.md, debugging.md. The model navigates memory by following links, not by retrieving via embedding similarity. This is the “the repo is the schema” insight. Memory becomes a write-able artifact that future runs read.

Sub-agents and routing. Anterior routes by confidence × stakes. Azure SRE spawns parallel sub-agents per hypothesis when a single context is at risk of getting polluted. Hippocratic uses a 21-model supervisory constellation around a primary conversational model. None of these compositions require retraining the underlying weights; they require designing the orchestration layer.

Judge rubrics. The Harvey ceiling is the rubric ceiling. The Anterior calibration is the judge alignment with humans. The fastest leverage in most teams’ first improvement loop is not a fancier judge — it is a better-written rubric and a small humans-vs-judge alignment dataset.

Fine-tuning the small models in the harness. Sometimes weights do change, but on the components, not the primary model. NVIDIA NeMo’s case study on an enterprise data flywheel: a routing model fine-tuned from Llama 3.1 70B down to a Llama 3.1 8B variant achieved 96% accuracy with a 10× model size reduction and 70% latency improvement. The query rephrasal model gained 3.7% accuracy with a 40% latency cut. The orchestrating LLM was untouched.

The pattern is consistent: when you map “improvements shipped” against “components that changed” across these case studies, the primary reasoning model is the least common thing that gets edited. The harness layer carries the weight.

Where these loops break

Six failure modes show up repeatedly. None are theoretical; each one has burned at least one of the case studies above.

Overfitting to recent failures. Aggregate harness changes against last week’s top errors and you regress on tasks the change wasn’t targeting. LangChain’s iteration log explicitly marks these as discarded runs. Without a frozen eval set that the validation gate runs every mutation against, you’ll fix Monday’s bug and silently break Tuesday’s working flow.

Reward hacking against the rubric. When the agent edits its own harness against an LLM judge’s scoring, the judge’s scoring is the optimization target — including any blind spots in the rubric. Harvey caveats this directly: the improvements track the rubric, and the rubric is human-authored and incomplete. Periodic out-of-distribution evals from a separate judge with a separate rubric catch this.

Judge drift and validator fragility. Anterior’s validate-the-validator move exists because LLM-judges drift, and the drift is silent. If the judge is the substrate for routing, clustering, and mutation decisions, judge drift propagates everywhere. Alignment metrics against humans on a rolling sample of cases is the only known fix.

Memory staleness. Microsoft flagged this as their unsolved problem: when two sessions write conflicting patterns to debugging.md, the model has to reconcile them; when a service changes behavior, old memory entries become misleading. Timestamps and explicit deprecation help, but no production team has solved this systematically.

Privacy and regulatory constraints on production data. Healthcare and finance can’t freely route production traces into a learning loop the way a generic SaaS product can. The TikTok Pay ARIA paper handles this by having the agent self-identify uncertainty through structured self-dialogue and request targeted explanations from human experts at runtime, keeping learning at test time inside the regulatory boundary. Hippocratic uses synthetic test calls plus consented real-call evidence; Anterior keeps clinician review and AI determination in the same compliance perimeter.

Compounding errors when the validator itself fails. A bad judge calibrated against a small alignment set drifts. A bad alignment set lets the judge calibrate against itself. A bad clustering layer groups the wrong failures together. Each layer of the loop is a place errors can go undetected and propagate. The defense is treating every layer as an evaluable artifact — the judge has a precision/recall, the cluster labels have inter-rater agreement, the harness mutations have a regression budget.

The seventh failure mode, which is institutional rather than technical: nobody owns the loop. In every case study above, the loop is owned by a named team with a named lead — Grupen at Harvey, Mukherjee at Hippocratic, Mehta and team at Microsoft. Loops without owners decay quietly.

Build order

If you’re standing up a vertical agent and don’t yet have this loop, the build order is fixed and the order matters. None of the steps require the next-generation model.

Start with traces. Every tool call, every model input, every model output, every latency, every outcome, with a stable trace ID per session. If you can’t reconstruct what happened, none of the rest of the loop works. LangSmith, Arize Phoenix, Braintrust, and OpenTelemetry-based stacks all do this; pick one and instrument every call path before anything else.

Then write one rubric for one task. Not a benchmark suite. One task that matters, one rubric that an expert in your domain would sign off on. Score 50 production traces against it manually. The rubric you ship will be wrong in instructive ways; the act of writing and applying it surfaces the failure modes you didn’t know you had.

Add a judge against that rubric. Run it inline on a sample of production. Run it against the 50 you scored manually. Compute alignment. If alignment is below ~70%, the rubric is the problem, not the judge.

Add the clustering and mutation step last. Cluster the lowest-scored traces, propose one harness change, gate it against your offline eval, ship if it passes, measure the production effect. This is one cycle. Run it weekly.

The model upgrade question takes care of itself once the loop is running. When a better base model ships, you swap it in, rerun the validation gate, and observe whether your harness over-fits to the old model. (Different models reward different harnesses — Claude Opus 4.6 scored 59.6% with a harness tuned for GPT-5.2-Codex on Terminal Bench 2.0; the same Claude with its own harness moved several positions.) The harness tax of switching models is real, but it’s a calibration problem, not a foundational one.

The reason this matters now and not in twelve months is asymmetry. Vertical agent winners in 2026 will not be the teams with the best zero-shot model. They will be the teams whose deployed agents are quietly compounding skill every week the rest of the market sits frozen. The loop is the moat.

Build the trace store this week. Write the first rubric next week. The rest of it follows.

TL;DR - Rogo serves more than 35,000 professionals at over 250 institutions — Rothschild & Co, Jefferies, Lazard, Moelis, Nomura — with an AI agent called Felix that bankers email like a junior analyst and get back finished decks, models, and memos. The interesting part is not the model. Rogo’s own product team calls Felix their “agent harness” — a vertical scaffolding designed to be model-agnostic across GPT 5.5, Claude Opus 4.7, and Gemini. Felix is the playbook for vertical AI: the moat is the harness, the evals, the data integrations, and the deployment model — not which frontier LLM is wired in this quarter. If you are building a vertical agent, study how Rogo decomposed the problem before you pick a model.

What Rogo Actually Sells

A precision note first: when people say “banking” in this conversation, they don’t mean retail or commercial banking. Rogo sits inside high finance — investment banking, private equity, hedge funds, equity research, asset management. Rogo’s own product page explicitly calls out its three audiences: Banking, Private Markets, Public Markets. The workflows are deal-shaped: pitchbooks, comps, models, memos, CIMs, diligence trackers.

Rogo was founded by Gabriel Stengel and John Willett — both ex-investment-bankers (Lazard, J.P. Morgan, Barclays) — with Tumas Rackaitis. That founder profile matters because the company’s edge is not the LLM; it is the granular, painful familiarity with what a 2 AM CIM revision actually looks like.

Felix Architecture

Yesterday’s $160M Series D, led by Kleiner Perkins with participation from Sequoia, Thrive, Khosla, and J.P. Morgan Growth Equity Partners, brings total funding past $300M. The capital is going toward two things that tell you what they actually believe: deeper data integrations and more forward-deployed bankers embedded inside client institutions.

Felix Is a Harness, Not a Model

The single most useful sentence Rogo has published this year shows up in their GPT 5.5 release note: “we’ve begun incorporating GPT 5.5 into our agent harness, Felix.” Read that twice.

Felix is not a fine-tuned model. Felix is the harness — the orchestration scaffold, tool layer, citation system, output formatters, audit trail, and policy controls — into which Rogo plugs whichever frontier model performs best on their internal benchmark this week. They are explicit that they are model-agnostic across OpenAI, Google, and Anthropic, and TAMradar’s coverage notes the platform supports GPT 5.5 and Anthropic Opus 4.7 concurrently.

This separation is load-bearing. In the Model Reliability Engineering frame, the harness is one of the two reliability axes — the scaffolding you build around the model to make its behavior production-safe. The harness-vs-model split is the same separation MRE treats as one of its two reliability axes. Rogo's product team uses the word the same way. The implication for builders: when frontier labs ship a 4% improvement on your domain, you swap the engine; when they ship a 40% improvement two years from now, your harness is what survives.

Here is the rough shape of what’s inside Felix:

Detail belongs in the prose, not the diagram. Three components below carry the real weight.

The Email Interface Is the Real Interface

The product surface that ships with Felix is unusual: bankers send Felix an email the same way they would a colleague, get an acknowledgment in under a minute with an ETA, and receive PowerPoint, Excel, Word, and PDF deliverables back when ready. Iteration happens by replying to the email thread.

This is not a UX gimmick. It tells you something about how the team thinks about adoption. Investment bankers already live in Outlook. Asking them to adopt a new interface is a tax. Email-as-API removes the tax. It also imposes async semantics on the agent: a long-running task with intermediate status, observable state via the inbox, and a clean handoff back to the human reviewer. The harness has to absorb that asynchrony — request queuing, intermediate progress, partial results, source attribution surviving the round-trip — without leaking it back to the user.

The output substrate matters too. Felix returns work in Excel, PowerPoint, and Word formatted in the firm’s own templates and house style. A pitchbook that doesn’t match house formatting is not 90% done; it is 0% done. Vertical AI rises or falls on output substrate fidelity.

The Big Finance Benchmark: Vertical Evals Are the Moat

Rogo curates an internal evaluation set called the Big Finance Benchmark — real financial tasks designed by their ex-finance team. Tasks include valuing companies, benchmarking peers on specific metrics, and building theses across disparate documents. They are explicit that these come from real workflows, not synthetic prompts.

This is the unsexy infrastructure that compounds. When OpenAI ships GPT 5.6 next quarter, Rogo will know within a day whether it improves CIM drafting on real deals or just MMLU. That is the kind of judgment a horizontal benchmark cannot give you. Every serious vertical AI company will need its own version of this. If you are building one and you don’t have a domain-specific eval suite, you are flying without instruments.

Workflow Surface: What Felix Actually Does

The concrete capabilities Rogo has shipped span deal screening, CIM generation, buyer outreach, and data room diligence. Decomposed:

• Deal screening. Filtering thousands of potential targets against thesis criteria.

• CIM generation. Drafting Confidential Information Memoranda — the 50-to-100-page sell-side documents that anchor M&A processes.

• Buyer outreach. Generating personalized contact lists and initial communications.

• Data room diligence. Synthesizing across the document piles that buyers and bankers wade through.

• Comps and models. Building Excel spreadsheets with historical financials and forward forecasts.

• Pitchbooks and memos. Decks for a CEO meeting, memos for an investment committee.

SiliconANGLE’s coverage notes that Felix can also offer to keep a report current — for example, an analyst covering Apple can have the agent re-run the report each time the company reports earnings. Scheduled, recurring agent runs are part of the surface.

The data substrate behind these tasks is extensive. TAMradar lists integrations with PitchBook, LSEG, Cap IQ, FactSet, Fitch Solutions, and Third Bridge, plus internal CRM and SharePoint connectors. Auditable outputs are positioned for SOC 2, ISO 27001, GDPR, and EU AI Act compliance — the table-stakes regulatory surface for institutional finance.

Sisyphus: The Other Harness

The most under-covered part of Rogo’s stack is a second internal agent called Sisyphus — an autonomous offensive-security agent that pen-tests Rogo’s own infrastructure once or twice a day, calibrated to deployment cadence. It runs structured campaigns across authentication abuse, authorization bypass, injection, SSRF, and LLM-specific exploit categories, and it chains findings to validate exploitability rather than just flagging signals.

Two numbers from Rogo’s own writeup are worth remembering. One week after a third-party penetration test, Sisyphus identified 18 additional exploitable vulnerabilities in a single afternoon, most chained, all remediated within hours. And on calibration: high-confidence findings now carry a >95% true-positive rate after the team tuned the recon phase and compared the agent’s triage against their human security team.

This is the harness for the harness. If your vertical agent platform handles consequential workflows, “we get pen-tested twice a year” is not a posture; it is a vulnerability window. Sisyphus is what the security side of vertical AI starts to look like.

Forward-Deployed Bankers: The Human Harness

Rogo’s go-to-market is structured around an embedded role they call Forward Deployed Bankers — ex-bankers from top firms who sit inside client institutions and onboard teams from analyst to managing director. The new capital is funding expansion of this team from New York into London.

This is not professional services in disguise. It is closer to what Palantir built for defense and intelligence: domain-fluent humans who translate between the workflow and the platform, calibrate the agent’s outputs to firm-specific style, and surface workflow gaps that become product. They understand model formatting and how a positioning section actually reads. Without them, the harness loses ground truth on what “good” looks like inside each firm’s house style.

For builders: the lesson is that adoption inside regulated, high-status industries is bottlenecked on trust transfer, not feature parity. The forward-deployed model is expensive and it is a moat.

What’s Actually Being Transformed

Bankers do not get replaced; their pyramid does. Rogo’s Series D announcement is explicit that leading firms are “restructuring workflows, rethinking staffing pyramids, and deploying autonomous agents that work asynchronously across every transaction.” A managing director at one client described Felix as having tripled team output with no headcount additions. That is the shape of the transformation: same senior judgment layer, compressed junior layer, agent layer doing the asynchronous grunt work, forward-deployed bankers tuning the seams.

Rogo’s two recent acquisitions tell you where they are aiming next. Plux AI — a UK firm tracking complex financial market developments — adds European market coverage. Offset, an AI agent company whose tech automatically updates financial models when new information arrives, plugs directly into the live-model side of the harness.

Five Lessons If You Are Building a Vertical Agent

1. The harness is the moat, not the model. Build it so frontier-model upgrades are a config change, not a rewrite.

2. Domain-specific evals beat horizontal benchmarks. Curate real tasks from real practitioners. Run them every model release.

3. Output substrate must match the destination workflow. A correct answer in the wrong format is the wrong answer.

4. Forward deployment changes adoption math. Domain-fluent humans embedded in the customer org are a feature, not overhead.

5. Security needs its own harness. When agents do consequential work, periodic pen tests leave a window. Continuous adversarial testing is the new floor.

What to Do This Week

Pick one workflow you’ve watched a domain expert do that you suspect an agent could absorb. Don’t model it yet. Instead, write down four things: the data sources they pull from, the output format they hand back, the audit trail they leave, and the colleague they email when they get stuck. Those four are your harness specification. The model goes in the middle of that, and you can swap it out next quarter.

If your current agent prototype only handles one or two of those four, you have not built a harness yet. You have built a wrapper.