Scheduled agents

Not every agent waits to be messaged. An Autonomous Agent has a goal and runs on its own, on a schedule or on demand, using its tools and knowledge to do work and report back. Nobody is watching those runs, so Hania does not take the agent's word for it: before a run counts as complete, its work is checked against what the tools actually returned.

The agent type

An Autonomous Agent does everything an Agent does, and adds the ability to act by itself. It still replies live when someone talks to it; what it gains is a goal it can pursue on its own when a schedule, a trigger, or Run now fires. The goal is the input to those runs and is never read during a live chat.

Pick the type on the agent's General tab, and switch either way whenever you want. Everything else about the agent is unchanged by the choice: the same prompt, model, tools, knowledge, memory, widget, channels, and voice.

What only Autonomous Agents have

Choosing the type adds an Agent tab and, with it, everything to do with running by itself:

• Goal, the required input for every run.
• Schedule, plus Run now and the webhook trigger for starting runs on demand.
• Outputs: results are always stored as run history, and you can add email or a webhook.
• Persistent conversation, deciding whether runs share one thread.
• Allow destructive actions in autonomous runs, and run reflection.
• The Review queue, where a run waits when it pauses to ask a human.

The tuning on the same tab - iteration budget, timeouts, token budget, re-plan interval, goal-check model, delegation, and output schema - governs how the agent works through a task with its tools. That applies to its live chats as well as its runs, not to runs alone.

What you configure

• Goal (agent_goal): what the agent should accomplish on each run.
• Schedule (schedule): when it runs; the editor previews the upcoming run times, and next_run_at / last_run_at track its cadence.
• Iteration budget (max_iterations) and a per-run timeout (timeout_seconds): bounds on how long and how hard it works.
• Output (output_config): where its result goes (for example, email or a webhook tool).
• Persistent conversation (persistent_conversation): whether runs share context. Off by default: each run starts a fresh conversation (best for unrelated tasks like article generation). On: all runs share one ongoing conversation, so each run sees the previous run's context (best for recurring work like monitoring).

These are fields on the agent. Set them in the editor or via the Bots API.

How a run knows it's done

An agent working unattended has to decide for itself when the job is finished, and a model asked whether it is done will nearly always say yes. Most agent frameworks leave that judgement to the developer, and many agent systems simply trust the model's own report that a task is complete. Hania checks the work instead.

When a run reaches what looks like the end, a separate step reads what the tools actually returned during the run, not the summary the agent wrote about itself, and confirms that every part of the goal really happened. Work that was described but never confirmed by a tool result does not count: the agent is sent back to finish the job. Verifying against evidence rather than self-report is a well-established practice for agent reliability, and it is the difference between a run that claims success and one that produced it.

The check is bounded, so a run always ends rather than circling while it chases perfection. It is also honest about impossibility. An agent that truthfully reports the goal cannot be done with the tools it has is treated as finished, not pushed to keep hunting, so you get a clear "this could not be done, and here is why" instead of an agent that burns its whole budget proving it.

None of this is a black box. Turn on Agent tracing and every Goal Completion Check shows up in the run trace with its verdict, in line with each other step, so you can read what was checked and what it concluded.

Live conversations work the other way on purpose. When you are in the chat the check is deliberately light: once your question is answered the turn is over, so the agent replies and stops rather than grinding on, and when it asks you something it waits for you. Verification belongs where nobody is watching. Responsiveness belongs where someone is.

Progress checklists

A goal with several steps is tracked as a live checklist while the run works, so you can follow progress instead of guessing at it. The checklist is a view for you, not the thing that decides the outcome. Completion is settled by the evidence check above, which means an agent that forgets to tick something off cannot stall a run that is genuinely finished, and one that ticks everything off early cannot skip a step it never did.

Planning & quality

Longer runs sometimes drift off course or hand back an answer in the wrong shape. A few optional settings on the Agent tab help a run stay on track. They are all off by default, so turn one on only when a plain run needs a steadier hand.

• Re-plan every few steps. Have the agent stop and rethink its plan at a set interval, so a long run does not wander. Leave it off for short, direct tasks.
• Goal-check model. Have the completion check above run on a separate, usually stronger model instead of the agent's own. Useful when finishing early would be costly.
• Output schema. Describe the exact shape the final result should take, written as JSON. The agent tries to make its output fit, and the run is flagged if it still cannot. Reach for this when the result feeds a spreadsheet or another system that expects fixed fields.
• Run reflection. After each run the agent writes itself a short note about what it learned and opens the next run with it, so recurring work gets better over time.

Runs & results

Each run executes as a conversation you can read and trace, so you can see exactly what the agent did: the steps it took and the tools it called. Trigger a run on its schedule, or start one on demand from the dashboard. By default every run is its own fresh conversation. Turn on Persistent conversation to have all runs continue one shared thread instead.

When you start a run by hand, the Run now dialog includes an optional instructions box. Whatever you type there becomes the input for that one run, so you can point the agent at something specific - revise this, check that - without touching its standing goal or prompt. Leave it blank and the run behaves exactly as a scheduled one would. Instructions apply to that run only; nothing is saved to the agent. The same dialog appears whether you trigger from the agent's editor or from its conversation view.

When the agent uses a model that shows its thinking, you can watch it reason in real time. A thinking panel streams open while the model works and folds up to a short summary once the answer begins, and you can reopen it any time to read the full reasoning. Wherever the agent used a tool, you can also see a short note on why it chose that one. This lets you follow the agent's reasoning without guessing at it.

If a run is cut short by a restart, it shows as Interrupted in Conversations and can pick up where it left off. This is a pause, not a failure, and the transcript up to that point is kept.

Safety in autonomous runs

A scheduled or triggered run is autonomous, so no person is watching it. To limit the blast radius of a mistake or a prompt injection, Hania gates two kinds of tool in autonomous runs. Interactive chat and live runs are never gated; a tool that works when you're present may still be blocked when the same agent runs on a schedule.

• Destructive tools are blocked. A tool classified destructive (delete, cancel, refund, wipe, run shell commands…) is blocked in autonomous runs, by classification, not by what the specific call would do. The bot doesn't crash; it receives the block as a tool result and adapts. Lift it per-bot with Allow destructive actions in autonomous runs (on the Agent tab), which lifts the block for all of that bot's destructive tools at once.
• External sends must name the destination. A tool that sends data externally (email, an outbound API) is blocked in autonomous runs unless the destination is named in the agent goal, so a recipient can't be slipped in through injected instructions.

Approvals and the review queue

An agent does not have to guess on a judgement call. It can pause and ask you first, then pick up the same run the moment you answer. This happens in two ways.

Asking a question

Give the agent the Ask User tool, a credential-free built-in that you assign like any other tool, with no setup. (It used to be called Ask a Human.) When the run reaches a decision it should not make on its own, it stops gracefully and queues a question instead of guessing.

Questions land in the Review queue, under Operate in the sidebar, where the nav item shows a badge with the number of pending requests. Each request shows the agent's questions, any context it attached, and the choices it offered. Pick an answer for each one, type your own in your own words, or leave a question for the agent to decide, since the choices are only suggestions. The moment you respond, the agent resumes from where it paused, with full context intact, and finishes the work.

Approving a tool before it runs

You decide which tools need a sign-off when you assign them to the agent. Each assigned tool has an Approval setting with three choices: Never (the default, where the tool just runs), Always (every use waits for you), and When destructive (it waits only for tools that delete data or send it somewhere external). Set it on the tools you want to keep a hand on and leave the rest on Never.

When a tool set to pause comes up in a run, the agent stops right before it and asks you to sign off on the exact action. The request shows the tool it wants to use and the arguments it plans to send, laid out so you can read them. You have three choices:

• Approve to let it run exactly as shown.
• Approve with edits after correcting an argument, for example fixing a recipient address or trimming a number, so the agent runs your corrected version instead.
• Deny with a short reason, which the agent reads and then works around.

For an autonomous run, the approval waits in the Review queue alongside questions. For an interactive agent you are chatting with, the same approve, edit, or deny card appears right in the conversation, and the agent continues as soon as you decide.

How the queue behaves

• One request at a time. While a request is pending, that agent's schedule is paused too, so requests never stack up.
• 72-hour window. A request left unanswered for 72 hours expires and can no longer be answered. An automated run is closed as expired, so answer before the countdown runs out. A web chat stays open and simply carries on with your next message.
• Anyone on the team can answer. The queue is shared across your workspace, with no per-request assignment.

A paused run also shows as Paused, awaiting input in Conversations until it is answered, or Expired if the window lapses. Live conversations on the web console do not use the queue for questions; the agent asks you in the conversation, the same place a tool approval card appears, and every agent can do that without the Ask User tool. See questions in the chat.