At a drone-racing desk, the first useful object is not the drone.
It is the rig beside it: a practice world where the code can crash, overshoot a gate, misread the camera, and leave behind enough evidence for a human to understand what happened.
Elodin recently open-sourced a practice simulator for Anduril's AI Grand Prix, a $500,000 autonomous drone-racing competition. The official qualifier simulator had not arrived yet, so Elodin gave contestants a place to start writing autopilot code anyway.
That release is more useful as an operating lesson than as a racing story.
When autonomy gets serious, teams stop judging it by how clever it sounds in a demo. They give it a world with constraints. They decide what the agent may touch. They run the loop at the speed the real system expects. They capture telemetry. Then they replay the mistakes.
Most business AI projects still skip that step.
A support agent gets tested on a handful of prompts. A sales assistant gets asked to summarize a CRM account. A publishing agent drafts a page in a sandbox. Everyone nods because the output looks plausible. Then the same agent gets connected to real customers, real records, real money, or real production systems, and the team discovers that a prompt demo is not a proving ground.
The better operator question is simple: what is the simulator for the first workflow you want an AI agent to run?
What Elodin released
Elodin's AI Grand Prix race sim harness is a practice rig for contestants writing autonomous drone-racing code. The project README describes it as an open-source, Elodin-based practice simulator for Anduril's AI Grand Prix, "built so contestants can iterate on perception, planning, and control code today."
The harness includes high-fidelity 6-DOF physics from Elodin, deterministic GPU-rendered multi-rate sensors, Betaflight SITL running in lockstep with physics, an FPV camera matching the competition's technical specs, a three-gate course, and a clean solver/ package where contestants write their code.
That last part is easy to miss. The contestant does not get to reshape the whole world. The edit surface is narrow. The harness decides what the world looks like, how fast the physics runs, how the camera behaves, how the flight controller receives data, and where the contestant's function sits in the loop.
The Hacker News post for the project makes the timing problem visible. Dan from Elodin wrote that the harness "runs against real Betaflight," and that Betaflight "requires at least 1000 sensor samples per second to run real-time correctly."
That is the shape of a serious test: a real controller at its native cadence, physics, sensors, camera, contestant code in the middle, and enough determinism to make a failed run worth studying.
Elodin's broader simulation and flight software monorepo helps explain why the harness looks this way. The project describes simulation and flight software built around pieces such as elodin-db, a time-series database and message bus; nox-py, the Python SDK; and an editor for visualizing simulation and flight data. Monte Carlo runs, GPU acceleration, and deterministic replays fit naturally inside that architecture.
Strip away the drones and the operator pattern remains.
Before the autonomous system gets the real world, it gets a representative world.
A demo is not a harness
Business teams often test AI agents in the easiest possible environment: a prompt window.
Ask the agent to handle a refund request. Ask it to classify a lead. Ask it to draft a response to an angry customer. Ask it to update a project plan. If the response is polished, the test feels successful.
The messy parts of a workflow rarely live in the prompt. They live in the trigger, the half-filled form, the stale CRM field, the edge case buried in a policy note, the customer who writes one thing and means another, the integration that times out, and the manager who approves only after seeing the evidence.
An agent demo tests language. A workflow harness tests behavior.
For a small business, that difference shows up quickly. An AI assistant that writes a good support reply may still choose the wrong refund path. A sales agent may summarize an account correctly and still update the wrong field. A finance workflow may classify an invoice cleanly until a vendor changes its format. A website publishing assistant may produce good copy and still miss the sandbox contract that keeps agent-written code away from production.
BaristaLabs has written separately about why agent evals should test workflow receipts and why agent-written code needs a sandbox contract. The same principle applies here: the artifact you test must resemble the work you plan to trust.
The business version of a simulation harness
A business simulation harness is a safe, repeatable version of one workflow.
It gives the agent enough of the real job to expose bad decisions, but not enough authority to hurt the business. The agent can perceive inputs, choose actions, call allowed tools, hit fake or read-only systems, produce evidence, fail in controlled ways, and leave a replayable trail.
For a CRM workflow, the harness might contain copied or synthetic account records, a fake write API, a policy file, sample emails, and a reviewer screen that shows proposed changes before anything touches the live CRM.
For a support workflow, it might include historical tickets, canned customer states, simulated order data, allowed response actions, escalation rules, and a queue where a human can approve, edit, or reject the proposed reply.
For an operations workflow, it might include inventory snapshots, supplier messages, constraint rules, approval thresholds, and telemetry that records why the agent recommended a purchase order change.
The point is not to build a digital twin of the whole company. That is usually too much. The first useful harness is narrower: one trigger, one workflow lane, one tool surface, one set of success criteria, and a clear promotion gate before production access.
What to put in the harness
Start with the trigger. The agent should not wake up because someone typed a clever prompt. It should wake up the way the real workflow wakes up: a new ticket, a stale lead, an invoice upload, a failed QA check, a low inventory signal, or a draft waiting for review.
Then define the inputs. Use real examples where privacy and policy allow it. Use synthetic examples where they do not. Keep the awkward cases: the bad scan, the customer with two accounts, the supplier email that changes terms in the second paragraph, the lead that looks qualified until the budget field appears.
Draw the fake/live boundary early. Which systems are simulated? Which are read-only? Which actions can the agent propose but not execute? Which actions stay blocked until a human changes the gate?
Constrain the tool surface. A contestant in Elodin's harness writes inside solver/; the rest of the rig controls the world around it. A business agent needs the same discipline. Give it the tools it needs for the workflow, not a general-purpose browser with permission to improvise.
Define success in workflow terms. Did the support agent choose the right policy path? Did it preserve the customer's facts? Did it show the reviewer the evidence? Did it avoid fields it was not allowed to edit? Did it escalate when confidence dropped?
Add failure cases on purpose. A harness with only happy paths trains everyone to trust the demo. Include stale data, contradictory instructions, missing attachments, permission conflicts, ambiguous customer intent, malformed records, and tool failures.
Capture telemetry. Record inputs, retrieved context, tool calls, proposed actions, reviewer decisions, errors, latency, and final outcomes. The goal is not surveillance for its own sake. The goal is to make a miss inspectable.
Make replay normal. When an agent fails, the team should be able to rerun the same case after changing the prompt, policy, tool contract, model, or approval rule. Without replay, every failure becomes an anecdote. With replay, it becomes an eval case.
Set a promotion gate. Decide what evidence earns more access. Maybe the agent can draft but not send. Then it can propose low-risk updates. Then it can execute a narrow action under review. Each step should be tied to observed performance in the harness, not enthusiasm after a demo.
A lightweight AI workflow controls plan can make those gates explicit. An approval queue gives reviewers a place to see proposed actions, evidence, and exceptions before the agent reaches the live workflow.
Map one workflow before adding autonomy
The first simulation harness should be boring enough to finish.
Pick one workflow where the upside is real and the blast radius is manageable: a support triage lane, a CRM cleanup task, a weekly reporting workflow, a content QA pass before publishing, or a finance review step where the agent proposes classifications but a person approves the result.
Then map the harness before mapping the agent.
What triggers the run? What does the agent see? Which systems are fake, read-only, or live? What actions may it propose? What proof does the reviewer need? What counts as a pass? What gets replayed after a miss? What evidence would let the agent move from shadow mode to supervised production?
That map is often more valuable than the first prompt. It shows where the workflow is unclear, where policy lives only in someone's head, where the data is too messy, and where the approval boundary needs to exist.
BaristaLabs helps teams do this in a practical first pass through process automation: choose one workflow, define the boundary, design the review surface, and decide what evidence would justify more autonomy.
If you are considering an AI agent for customer operations, sales, finance, publishing, or field work, start with the simulator question before the production question.
What is the test world where this agent can fail safely?
Next step
Map one AI workflow into a simulation-harness review.
BaristaLabs can help you define the trigger, inputs, fake/live boundary, allowed tool surface, success criteria, telemetry, replay evidence, and promotion gate before the agent touches production systems.
Review one workflow
Map one workflow before giving an agent real access
BaristaLabs helps teams define the trigger, inputs, fake/live boundary, tool surface, approval queue, telemetry, replay evidence, and promotion gate for AI workflows.
Best fit when an AI demo works, but the team has not yet proven the workflow can fail safely.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.