A Squad never talks to a customer. It wakes up on schedule, reads its own context, queries your systems through their APIs, decides what is worth doing and hands the instruction — in plain language — to the agents that handle WhatsApp and webchat. Then it writes the report, publishes the document and sends it by email.
Waking up is not an order to act. Checking the situation and concluding that nothing needed to be done is a successful run.
Available through the public API as well: trigger a run, follow the logs and read the outcome the Squad declared.
A master agent with no channel of its own, a schedule and a set of tools.
Channel agents talk to your customers. The Squad talks to the channel agents — and to your systems.
A Squad is the platform's orchestrating agent. It has no WhatsApp number, no webchat and never receives a customer message. Its job is different: to carry an entire business routine from start to finish, without anyone having to remember to pull the trigger.
You give it three things — the context of the process, the knowledge of the operation and the tools (the endpoints of your ERP, your medical records system, your order system, plus MCP servers). From there, there is no decision tree to draw: at every turn the Squad chooses what to do, including concluding that there is nothing to do.
This is how a Squad shows up to whoever runs the operation: one card per routine, telling you when it last ran, when it runs again and how many channel agents it can give orders to.
Three Squads in the same list. In Exam Confirmation, the lit strip is run #47 happening right now: 2m14s in, 18 dispatches so far, the simulation-mode notice and a stop button always in sight. Daily Billing is active, Monday to Friday at 08:00 and 14:00, with a cap of 200 dispatches per run; Inventory Round was created yesterday, has never run and stays disabled.
Every card repeats the same line: last run, next run, how many channel agents that Squad can call on, and whether the fan of subagents is switched on.
One glance at the list answers what today gets answered by asking somebody: which routine ran overnight, which one comes back at 14:00, which one is stopped and since when. Nobody has to remember to pull the trigger, and nobody has to open a run to find out it ever happened.
The dispatch cap and simulation mode are spelled out on the card too, before a single message goes out — the limit of what that routine is allowed to do is visible without opening the settings.
The Inventory Round card was created yesterday and is still being tuned — tuning the manager does by talking to the Squad itself, not by drawing a flow on a screen. He describes the routine, asks the Squad to read the source’s documentation and implement the endpoints as tools, and settles on a time. The Squad also schedules tasks for itself.
A flow automation only exists once somebody knows how to build the flow. Here the routine starts as a conversation in plain English.
Nine moments in a scheduled run, from waking up to the declared outcome.
The schedule belongs to the Squad. Nobody opens the platform, nobody clicks. At the defined time the run begins — overnight, first thing in the morning, several times a day, whatever the process calls for.
Before anything else, it retrieves the main context of the process, the attached knowledge and the memory of previous runs. It knows what has already been done, what is still pending and what is not worth repeating.
It calls the REST endpoints you registered — ERP, medical records, order system — using your operation's authentication headers, along with MCP servers. The data comes straight from the source, at the moment of the run.
With the real picture in hand, it makes the call: which cases deserve action now, which can wait, which have already been resolved some other way. Waking up is not an order to act.
For anything that requires human contact, the Squad writes an instruction in plain language to the channel agent — not a payload, not a trigger. The WhatsApp or webchat agent handles the one-to-one conversation with its own personality.
This is not fire and forget. The channel agent reports what it did, what it did not do and why — and that answer feeds back into the Squad's reasoning before the report is written.
The Squad writes an analytical document with sections, tables built by reference to the data returned by the API, and charts rendered by the server. It comes out in HTML and PDF, complete, with nothing trailing off.
Delivery goes only to previously authorized recipients on a closed list, checked twice before anything leaves. The Squad does not choose who receives it, and it does not edit the list.
The run ends with a written outcome: what was checked, what was acted on, what was set aside and why. It stays in the auditable history, run by run.
From the inside, a run is not a black box: it is a time-stamped log, the fan of subagents that got recruited, the dialogue with each channel agent and a declared outcome at the end.
| # | Trigger | Outcome | Dispatches | Start |
|---|---|---|---|---|
| 47 | via schedule | Running sim. | 18 | today 06:00 |
| 46 | via button | Acted | 31 | yesterday 14:00 |
| 45 | via schedule | Checked · no action | 0 | yesterday 06:00 |
| 44 | self-scheduled | Nothing was due | 0 | Aug 22, 06:00 |
| 43 | via Hal-AI API | Failed | 0 | Aug 21, 14:00 |
| Period total | 49 | |||
The console at the top is run #47 in progress, fired by the 06:00 schedule and already in its third round. Every line carries the time: the call to the appointments API, the reading that 24 cases were unconfirmed, the opening of the fan of subagents into four parallel batches, the publication of the report, the warning that three contacts are outside the 24-hour window, and even a failed call with an automatic retry.
Below it, the dialogue shows up on both levels: the four subagents recruited, with the number of rounds and the read-only tools each one called, and the conversation with the channel agents — the WhatsApp one started nine conversations and reported back that three patients had already confirmed yesterday; the webchat one answered “not dispatched”, because those contacts can only be approached with an approved template.
The table closes the argument. Five runs in seven days, each with the trigger that started it and a written outcome: Acted, Checked · no action, Nothing was due and Failed are different results, and the platform does not treat a run that decided not to act as if it were an error.
Look again at the channel agent’s answer: three had already confirmed yesterday. Nobody programmed that exception. The agent remembers the conversation because the memory is its own — vectorized history, episodic facts about the customer and a sense of time, the same technology on WhatsApp, on webchat and on voice. It is the subject of the patent filed with the USPTO in 2025.
A flow automation starts from scratch every morning and sends again because it remembers nothing.
The instruction goes out in plain language. The answer comes back in plain language. And that answer may well be “I didn't, and here's why”.
Between the orchestrator and the agent on the front line there is no rigid message format. The Squad describes the mission the way a manager would describe it to an employee, and the channel agent answers the way an employee would: with the result and with the exceptions.
That changes behavior in practice. The agent on the front line knows that customer's history — because the memory is its own — and can therefore refuse an action that makes no sense, instead of carrying it out because a rule said so.
Dialogue between a Squad and a channel agent.
Case-by-case analysis, in parallel — instead of a statistical summary of the batch.
When a Squad has to look closely at many cases, it opens a fan: dozens of simultaneous readings, one per case, each with its own reasoning. Patient by patient. Order by order. Contract by contract.
Each subagent receives one case and only that case. It reads the evidence, checks what is being claimed and reaches a conclusion about that record — without diluting the hard case into the average of the batch.
The shape of the answer is declared up front as a JSON Schema. What comes back is checked against it — and goes straight into the report's table, with no model retyping a single number along the way.
In a subagent's world there is no writing, no sending email, no firing off messages. Those tools are simply not there. Analyzing is all it can do.
The readings are dispatched at the same time. That is what makes it feasible to analyze a large batch inside the window of a scheduled run, instead of sweeping case by case for hours.
It is an optional capability, set on each Squad. Simple verification routines do not need it; clinical, tax and credit analysis routines usually do.
The platform warns you right on the screen, before you switch it on. Dozens of parallel lines of reasoning consume far more than a single reading — and consumption is broken down by agent and by module in the dashboard.
Here is what an open fan looks like from the inside: dozens of cases dispatched at the same instant, one subagent per case, every card carrying the conclusion for that record — and, alongside them, the batch counter.
A single run with the fan open: 42 cases, one card per subagent, each with the case it was handed, the state — Delivered or Analyzing — and the conclusion for that record in one line. On the left, the batch counter follows it batch by batch: 24 of 24, 8 of 8, 6 of 10 and 0 of 4 still queued.
Below the grid sit the two guarantees: the 31 delivered answers were checked against the schema declared up front, and the tool list shows in green only the read-only ones — writing, adding a note and sending email appear grayed out.
The hard case does not disappear into the average of the batch. The expired doctor's order, the missing insurance authorization and the contact outside the 24-hour window become three separate conclusions, each with its reason — instead of one aggregate number saying that “5 cases need attention”.
Because the shape of the answer is checked against a schema, every conclusion goes straight into the report's table, with nobody retyping anything along the way.
Look at what is grayed out in the tool list: in a subagent's world there is no writing, no sending a message and no sending email — those tools were simply never inherited. Analyzing is all it can do.
What to do with the conclusions is the Squad's call, and whoever talks to a person is still the channel agent.
Talking to the manager, it reconfigures itself. Running on its own, it refuses to be reconfigured.
The manager opens a conversation with the Squad and adjusts the process by talking. There is no flow canvas to draw.
Self-configuration unlocked: the person speaking here is an authenticated user from your company.
In a scheduled routine, the Squad operates on data that came from outside — API responses, customer messages, document content.
That is the difference between an agent that takes instructions from the manager and an agent that would take instructions from any text it happened to read.
It is not a spreadsheet export with a paragraph on top. It is an analytical document written by the Squad about what it has just found.
The document has structure: context for the period, what was checked, the cases that required action, the exceptions and the conclusion. It comes out whole, with no cuts and no “…” in the middle of a table.
Rows point back to the data returned by the API. The model does not retype numbers: it references the source. That is what keeps a value from quietly changing between the query and the report.
Nine chart types are rendered server-side from the data — they are not images invented by the model. If a chart still has arithmetic left to do, the document is rejected instead of going out wrong.
The PDF is generated on the server and sent to the closed list of recipients, checked twice before it goes out. Every number that appears in the body of the email exists in the document.
Autonomy with no brakes is not a product. What holds a Squad in check is exactly what makes it acceptable in production.
Every run keeps what was queried, what was decided, what was acted on and the outcome declared. You can open a run from two weeks ago and follow the decision.
Anchored to the occurrence, not to the template name. If that customer already received that message for that reason, the Squad does not push again — and records that it did not.
The run executes in full and shows what it would have done, without talking to anyone and without sending anything. That is how a new Squad goes into production without surprises.
A run in progress can be interrupted by the manager. There is no routine that ends only when it feels like it.
The agent does not write free-form queries against the database. It uses parameterized, curated queries with a positive allowlist of what can be done — whatever is not explicitly permitted does not exist for it.
A document with no content, or with arithmetic left undone in a chart, is rejected — not quietly cleaned up to look like it worked.
No. They are different, complementary roles. The channel agent is the one talking to the customer, with its own personality, memory and tools. The Squad has no channel: it coordinates the routine, queries the systems, decides what needs human contact and asks the channel agent to make that contact — then collects the answer and writes the report.
It succeeded. Waking up is not an order to act. A run that queried the systems, weighed the cases and concluded there was nothing to do is a successful run — and it ends with that outcome declared in writing in the history, for whoever supervises to review later.
In layers. In an automatic run, self-configuration is locked and incoming data is treated as untrusted. The Squad can only reach previously authorized tools, the resend lock is anchored to the occurrence, and email delivery only reaches a closed list of recipients. Before going live you run it in simulation mode; once it is live, the stop button is still there.
Yes. The Hal-AI public API is versioned, authenticated by key, with per-resource scopes and an idempotency key on sends. Through it you can trigger a Squad run, follow its progress, read the logs and retrieve the declared outcome. The details are in Integrations and API.
Bring us the process. We design the Squad with you: which systems it queries, what it decides on its own, which agents it talks to and who receives the report.