Workflows

Nothing in an agent runs on its own; every run starts with a request. A call to execAgent from your systems is how agents run without anyone typing.

Scheduled and event-driven runs

A scheduler or a webhook receiver that calls execAgent turns any agent into a scheduled job or an event handler: a morning digest, a handler for a new ticket, a check that runs every hour. Where the result should go — mail, chat, a ticket — is one more api command at the end of the agent. Run these as a dedicated user, so the reports show what the schedule did.

Fan-out over a list

parallel runs a fixed set of functions, and invoke may not sit inside a loop. So “run the triage agent for each of these forty tickets” is written with the api command calling execAgent on the agent server itself, once per item. The calls go in a for loop. Each call is an ordinary agent run: recorded, reported and traced like any other.

Waiting on someone else

ask pauses a conversation for the user who started the conversation. An approval by a different person takes two agents and a table. The requester’s agent writes the request with db and ends. The approver’s agent — opened from search, or run by a scheduled call — reads what is pending, asks the approver with ask, and records the decision. The requester’s next request, or a scheduled run, picks the decision up.

Agents inside your applications

The API is the API the bundled GUI uses, so an agent can sit behind a button in your own application, in a chat integration, or in a pipeline step. With the search endpoint an application offers the same “type what you need” experience without the bundled GUI. Runs started this way appear in the same reports as runs from the search box.