When to use Alloy

Alloy is strongest on the busy work around an engineering question: when the answer is spread across many runs, or needs your most senior engineer to dig it out. It is weakest when the question is about one file that you can already open, or when the data to answer it was never recorded.

The rule of thumb

If the answer needs more than one log, or a question to your most experienced engineer, give it to Alloy.

If you can answer it in two minutes with one file in a log viewer, you do not need Alloy for that question.

Good fits

• Support requests from the field. A robot stopped, an operator reports a fault, a ticket lands. The agent reads the recent runs for that robot and replies with what happened and what to do. See Field support.
• Questions across many runs. "Has this happened before?", "Which robots show it?", "Did it start after a release?" Manual review of one log at a time does not scale to these questions.
• Test campaigns and release checks. You run the same analysis after every test and compare versions. The agent runs your steps on each new run and writes the comparison. See Validation.
• Recurring review. You want every run reviewed, but nobody has time to open each one. See Fleet Monitoring.
• Causes that cross systems. The fault shows in the recording, but the explanation is in the code, a metric or an old ticket. See Root Cause Analysis.
• Knowledge that lives in a few heads. New support staff or junior engineers need to answer questions that today go to one person.

Alloy helps most for teams with robots in production, a growing number of tickets or test runs, and engineers who lose days to log review.

Where another tool is the better choice

• One robot and a few logs. If one engineer can review every run by hand in minutes, a log viewer and your own scripts are enough.
• Real-time control or in-flight alerts. That is the job of your autonomy stack and your safety system. Alloy works on recordings after they upload.
• Replies to your end customers. Your helpdesk owns that conversation. The support agent works with your own team (support staff, field technicians, engineers), and your team decides what to tell the customer. On Jira Service Management its replies are internal notes unless a person asks it to post publicly. In Slack it answers anyone in a channel it is in, so think before you add it to a channel shared with customers.
• Training-data work. Use a labelling or dataset tool to label data, curate training sets or evaluate learned policies.

Strict security or data-location rules? That is not a reason to look elsewhere. Alloy runs as a cloud service by default, and we work with you on a setup that fits your requirements, including a dedicated environment. Talk to us.

Where Alloy stops

This is the one place where these docs state Alloy's boundaries. Other pages link here.

• Alloy works on what your robots record, after it uploads. It does not watch a run live and it does not stop a fault in progress. It is not a safety system.
• It finds what the data shows and the patterns you describe. The agent and scenarios can miss a fault the robot did not record, or one nobody described. If a topic, a log level or a ticket detail is missing, the agent says what it could not see. It does not invent it.
• Your engineers make the call. The agent can be wrong, stop short of the cause, or generalise from too few runs. It marks what it has not confirmed, and each finding links to its evidence so your team can check it before acting.

Compared with what teams use today

Most teams already have something. Here is what each option does well and what remains for your team to do.

Alloy is not a replacement for your coding agent. Many teams use both: the coding agent writes the fix, and Alloy supplies what the robot actually did and checks the next runs for a recurrence. See MCP.

Side-by-side guides

Honest comparisons, including when the other tool is the better choice:

• Robotics data platforms: Alloy vs Foxglove, Alloy vs Roboto
• AI assistants and coding agents: Alloy vs ChatGPT, Alloy vs Cursor, Alloy vs Codex

All guides: How Alloy compares.

Before you ask: a short checklist

The agent does better work with the same context you would give a colleague.

• Which robot, or which group of robots.
• About when. "Around 9 this morning" is enough. The agent finds the exact moment.
• What normal looks like. "It should resume within 10 seconds", "battery should not drop below 30% on this route".
• Which version, if a release is involved.
• Where else to look, if you know: a ticket, a dashboard, a file in the repository.

One good request

More pairs, for releases, scenarios, recurring reports and support questions, are in Getting good results.

After the answer

• Open the evidence. Click the cited moment and check that the recording shows what the agent says.
• Push back. If the agent stopped short, ask it to go further or to check another source. It keeps the context of the thread.
• Keep what works. Save a useful check as a scenario or a report automation, so the next run gets it.

Prove it on your own work

Pick one job from this page, not five. Take a baseline from records you already have, then compare once the agent has worked on enough of that job to judge it.

Build the full business case, and count the result, with What changes for your team.