Most AI at work waits for someone to type. You open a chat, ask, read, ask again, and when you close the laptop the work stops.
A lot of the work that matters happens when nobody is typing. A fridge full of stock starts warming at 3am. Supplier emails pile up overnight. The weekly stock report is due on Monday whether or not anyone remembers to ask for it. This is how we build agents on Cruq AI that start on their own, do the work, stop at the points where a person should decide, and leave a record you can check in the morning.
What starts an agent
An agent on Cruq AI doesn't need someone to open a chat. It can start from:
- A schedule. Hourly, daily or weekly, in your own timezone.
- A message. WhatsApp, Telegram, Slack, Microsoft Teams, or an email to a Gmail or Outlook inbox.
- An API call from your own systems, such as an ERP event or a form submission.
- Another AI tool. Claude, ChatGPT, Cursor or any MCP client can run your agents through mcp.cruq.ai.
The same agent can have several of these at once. A support agent might answer WhatsApp all day and also run a nightly summary of what it couldn't resolve.
An example: the 3am fridge
To test this properly we built a simulated cold chain: warehouses, fridges and trucks, with sensors that drift and fail. Three agents look after it.
The Watch agent runs every hour. It reads the sensors through a tool, checks them against the company's own procedures, which live in a knowledge base, and decides whether anything needs action. Most hours, nothing does, and the run ends in a few seconds.
When a compressor fails, the run looks different. The agent opens a ticket, pages the technician, and puts the orders stored in that fridge on hold. Quarantining the fridge, which locks it and stops anyone picking stock from it, is a real decision with a cost, so the agent doesn't do it alone. It asks the duty manager and the run pauses. The manager sees the question, with the readings and the procedure the agent is following, and approves it. The run picks up exactly where it stopped and quarantines the fridge.
The Dispatch agent and a Field Assistant that technicians use on their phones handle the rest. The point isn't the cold chain. It's the shape: a trigger, work done against your own data and procedures, and a person at the one step that needs a person.
Where a person decides
An agent you can't stop is not one you'll let near real systems. These are the controls we rely on:
- Ask a person. Any agent can pause and ask someone a question. The run's state is saved, so it can wait minutes or hours for an answer from the dashboard.
- Decisions as explicit steps. Key choices, like "is this lead qualified?" or "does this need a technician?", can be a yes-or-no step in the agent's graph, each with a fallback branch that sends unclear cases to a person.
- Guardrails on what goes in and what comes out. Rules catch personal data, credentials, attempts to override the agent's instructions, and off-topic requests, and block or flag them before they reach the model or the customer.
- A browser on a short leash. Agents that use a web browser can be limited to a list of allowed sites.
- Spend limits. API keys can carry a spend limit and an expiry date, so a runaway loop stops at a number you chose.
Every run leaves a record
When an agent works at night, the morning review has to be fast. Every run on Cruq AI records each step: the model calls, the tool calls with their inputs and outputs, any questions asked and who answered, and the tokens, cost and time for each. Browser steps keep screenshots. You can follow a run live, or open it the next day and see exactly what happened and why.
That record is also how you find problems early. If an agent's cost per run creeps up, or it starts asking for help more often, you see it in the numbers before anyone complains.
Knowing the agent is still good
Before an agent goes live, and after every change, we test it against real cases. An evaluation on Cruq AI is a set of inputs with a way to score each answer:
- Exact checks for anything with a right answer: the reply contains a value, matches a pattern or a JSON schema, or calls the right tool with the right arguments.
- A model judge with a rubric written in plain language, for answers a person would judge by reading.
- A decision scorer that grades an answer against ordered levels, from worst to best.
For the cold-chain agents we wrote eight tabletop cases, things like a door left open, a truck stuck in traffic or a power cut. Claude Haiku 4.5 scored 0.97, GPT-4.1 mini 0.94 and GPT-4o mini 0.75. That told us which model to run, and it's the same suite we run again whenever the procedures change.
Next, we're scoring live runs against the same rubric, so quality shows up next to cost on every agent, every day, and not only before a release.
Building one
You don't have to wire this up by hand. On the Builder page you describe the job in plain words, for example "check new orders against stock and tell me which ones we can't fill this week". A team of agents designs the agent, builds it and tests it, and asks before it creates anything. Then you give it a schedule or a channel, and it starts working without you.
On your models, in your building
All of this runs on your own model provider keys, or on open-weight models you host yourself. For companies whose data can't leave the country, the whole platform runs on their own servers. The agents, their runs and what they learn stay with the business that owns the work.
If there's a job in your company that should happen while everyone is asleep, tell us about it.
