Introducing Alloy

Ask why a robot failed. Get the moment, the likely cause and the evidence.

Why Alloy

Alloy is the AI Robotics Engineer. Robotics moves as fast as its teams can learn from their robots. Alloy does that investigation work across your whole fleet: it finds the runs, reads the logs and the systems around them, and answers with the evidence. Your fleet can grow without your team growing with it.

Like any great engineer, Alloy gets better the longer it is on your team. Every investigation, fix and correction becomes context it uses on the next one. And it works around the clock, so your team wakes up to answers.

Building robots that work in the real world is frontier engineering, and the hard problems are yours. Around them sits a lot of busy, boring work: find the right log, find the moment, line up the runs, check the ticket and the code, write it up for someone else. Today your best engineers do that by hand. Alloy takes it, so they get back to building robots.

The context behind each failure is scattered across logs, images, time series, tickets, code and one engineer's memory. Teams rebuild it by hand after every failure. When the same issue comes back six months later, much of the work starts again. Alloy keeps that context together, so every run makes the next one better.

Across the robot's life

• Development: find out why a change broke something, from the logs and the code.
• Validation: get a report on every test run, and compare builds across many runs.
• Deployed fleets: check every run, and see only the robots that need a person.
• Field support: answer field issues from the robot's data, where the question arrives.

Each investigation, test and support case adds context for the next one. That is the unfair advantage: a team whose engineers spend their week on the robot moves faster than one that spends it on logs.

You stay in control

Your team works with the agent in the Alloy app, in Slack, in Jira and from coding agents such as Claude Code and Codex. Each finding names the run, the moment in the recording, and the chart or query behind it.

Your engineers and your robots stay in control. The agent investigates, reports and answers. It does not drive your robots. Changes to a Jira ticket beyond its own replies wait for a person to agree.

What it does

The rule of thumb: if the answer needs more than one log, or a question to your most experienced engineer, give it to Alloy. See When to use Alloy.

What makes Alloy different

• It is fast. A question that takes an engineer a day of log pulling gets an answer with evidence in minutes.
• It investigates. It does not only display. Log viewers show you one recording in detail. The agent reads across all your runs and comes back with the moment, the count and a likely cause.
• It looks past the robot. A fault shows in the recording, but the explanation is often in a ticket, a metric or the code. The agent reads those too, when you connect them.
• Your checks run on every new run. Set up a review or a pattern check once. Each new run gets it after processing, and your team hears about the runs that fail it.
• It works on many things at once. Every chat, Slack thread and ticket gets its own investigation, at the same time. Your team's capacity is no longer one engineer, one log at a time.
• It works where your team already works. The same agent, with the same knowledge, in the app, in Slack threads, on Jira tickets and inside your coding agent.
• Your own agents can use it. Claude Code, Codex and other AI tools connect over MCP and work under the signed-in person's access. See Alloy for AI agents.
• It gets better as models do. We test new models on robotics tasks and move each job to the model that tests best. Your team changes nothing. See Model testing.
• It builds up context on your team. Notes you ask it to remember, your saved scripts, your documents and its record of past cases stay in your workspace. It says when it uses one, so a known issue gets a known answer, and what one engineer works out helps the next person who asks.
• It works while you are away. The agent runs on servers, not on a laptop, around the clock. Start an investigation, close the tab, and Alloy tells you when the answer is ready.

What teams have seen

• Validation. "We used to spend a full day after every field test just doing analysis. Now with Alloy, that's just ten minutes, and the conversation has completely shifted." Jai Castle, Product Validation Manager, in How Advanced Navigation cut validation analysis from a full day to ten minutes with Alloy.
• Support. A senior autonomy engineer estimates that a year ago he spent a day or more on support investigations, and that today it is usually less than an hour. From How SwarmFarm is scaling its robot fleet without hiring more support engineers.

See What changes for your team.

Worked example

Fictional example: the vehicles, places and numbers are invented.

A field engineer posts in Slack: "AUV-03 aborted its dive at Harbour East around 14:30. Third abort this month. What happened?"

1. The agent opens the run and finds the abort at 14:32:18. For 2.1 seconds before it, the depth sensor repeated the same reading while the vehicle kept descending. The depth controller treated the frozen value as a fault and started the abort, as designed.
2. It checks the other two aborts this month. Both show the same frozen depth reading before the abort.
3. It searches every dive you have uploaded, on all vehicles. It finds 6 more short freezes that did not cause an abort, on AUV-03 and AUV-05. All of them happened after depth-sensor firmware 1.4 was installed on those two vehicles. Vehicles still on 1.3 show none.
4. It answers in the thread: "Likely cause: the depth sensor freezes for about 2 seconds on firmware 1.4, and the controller aborts when a freeze happens during descent. Evidence: 9 freezes on 2 vehicles, all on 1.4, links below. Not confirmed: whether the firmware or the connector is at fault. Suggested next step: roll AUV-03 back to sensor firmware 1.3 for the next dives and compare."
5. The engineer asks it to watch for the pattern. The agent creates a scenario, and each new dive from any vehicle is now checked for a frozen depth reading.

The engineer who reads the thread starts from a cause with evidence, not from a raw log. The engineering decision (roll back, replace the sensor, change the controller) stays with the team.

The agent did the digging. The engineer did the engineering.

The same pattern, at Andromeda. Speaker volume on Andromeda's humanoid robots was dropping at random across the fleet, with nothing obvious in the logs. Their AI engineering lead asked Alloy. It pulled the telemetry from across the fleet, checked signals he had not thought to look at, and found where a gain output was failing. He would otherwise have spent about two days building a dashboard first. It took ten minutes. Read the story

How it shows its work

You can check every answer.

• It cites the evidence. Each finding names the run and the time, and links to the moment in the recording, the chart or the query it used.
• It separates what the data shows from what it infers. The agent states its conclusion and marks what it has not confirmed.
• It works from your data. It reads the recordings you upload and the systems you connect. It does not answer from general knowledge about robots in place of your logs.
• Reports keep a history. You can see what changed in a report and restore an earlier version.

Treat each answer as a first investigation that your team checks. See Where Alloy stops.

Where it works

The same agent, with the same knowledge of your team, works in four places.

Some steps stay with a person by design: sign-up, SDK and SQL API keys, consent to connect an integration, billing, and deleting recordings, missions and reports. See Alloy for AI agents for what agents can do, and for the steps that run only in the app.

What it reads

• Robot recordings that you upload from the browser, from your S3 or Google Cloud Storage bucket, or from robots running Alloy Edge when your organisation also has Mesh Storage. Alloy reads MCAP (including ROS 2 recorded to MCAP), ROS 1 bags and common flight-log formats.
• Your engineering systems, when you connect them: Slack, Jira, Confluence, GitHub, Grafana and ClickHouse.
• Your team's context, kept in your workspace:
  • Notes you ask it to remember, for you or for your whole organisation.
  • Your scripts and documents, from the Scripts library. It uses your methods and says when it does.
  • Past cases: each support request and its outcome.
  • Past reports and comments on missions.

If your organisation also has Mesh Storage, Alloy's robot data lake, recordings that reach it through Alloy Edge, the Python SDK or a Mesh Storage upload can be queried directly with SQL or Python.

Who uses it

• Support and field service teams get an answer from robot data in the support thread, without a wait for engineering.
• Test and validation engineers get a result on the day the test ends, and the same check on every build.
• Autonomy and software engineers start an investigation from a cause and evidence, skip the log hunt, and get back to building.
• Engineering leads see which issues recur, how often, and on which robots, without a request for a manual report.
• Your coding agent reads what the robot did while it fixes the code.

Use cases

Getting access

Self-serve sign-up gives you Mesh Storage. Alloy engineers switch on the Agent Platform with you during onboarding: your data sources, your Slack and Jira, and your first checks. New Agent Platform workspaces start with a sample mission, and new members get a guided first conversation, so you can see an investigation before your own data arrives.

To use the agent on your own data, talk to us. The first call is about your team: where engineers lose time today, and which job to prove first. We then scope a pilot on that one workflow, with a baseline, an owner and success criteria agreed before it starts. To see the agent first, try it on sample robot data at Try Alloy.

Already have access? Upload your first mission and get a report on it.