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, the API trigger and an incoming webhook for starting runs on demand.
• Outputs: results are always stored as run history, and you can add email, a webhook, or an item in one of your collections.
• 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, 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. Schedules are in UTC, so convert your local time when you set one. (Collection rules are different: they use your workspace's time zone.)
• 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, a webhook, or a new item in a collection).
• 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.

Every unattended run gets the check: scheduled runs, runs started from a webhook or the API, by an email, after a call, or by another agent. Each check comes out one of three ways:

• Achieved. The goal was met and the run finishes.
• Impossible. The goal can't be done with the tools the agent has, and the agent said so. The run stops early, and the agent's reason becomes the reason shown on the run.
• Not met. The agent is sent back to keep working. If it is sent back eight times in a row without using a tool in between, the run stops there as not met.

If the check itself fails, or takes longer than 30 seconds, the run ends on the agent's last reply. It is recorded as not met, and the reason says the completion check failed. Every verdict is saved with the run, so its conversation shows why it carried on or stopped.

The check is on for every Autonomous Agent. To skip it, turn off Completion check under Planning & quality on the Agent tab. The run then ends as soon as the agent replies.

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 there is no completion check unless you give the chat a goal: 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.

In the conversation the checklist starts closed, so it doesn't take over the screen. The closed row still tells you the step the agent is on, how many are done, and how far along it is. Click it to see every step.

Goals for one conversation

An Autonomous Agent's goal is its standing task, the thing every run works toward. A /goal is something else: a finish line you set for one conversation while you're in it. The two are easy to mix up, so here is how they compare.

Setting a goal

In a chat with an Autonomous Agent, in the console or in the Hania Code terminal, type /goal followed by what done looks like, for example /goal every product in the spring range has a price and a photo. The condition can be up to 4,000 characters. The agent starts on it straight away, with your condition as the message, and a goal can start a new chat too.

After each reply a check decides whether the goal is met. If it isn't yet, the agent is told what's missing and keeps going. If it can't be done, the agent says why.

• /goal on its own shows the goal: what it is, how it's going, how many checks so far, and what it has used.
• /goal clear removes it. stop, off, reset, none and cancel work too.
• A new /goal replaces the one before.

In the console, a ◎ /goal chip above the message box shows whether the goal is active, paused or done, and how long it has been going. Click it for the details. Each verdict appears in the conversation as a short line. Team chats can't have a goal.

How a goal ends

• Achieved. A check finds the goal met.
• Can't be done. The agent shows the goal is impossible, and the chat says why.
• Handed back to you. After eight checks in a row with no tool used in between, the agent stops and hands the conversation back to you. The goal stays set, and your next message is checked again.
• Cleared. You clear it, or start a new conversation.

When something goes wrong

• Something only you can fix. The workspace is out of credit, your ChatGPT sign-in needs attention, the conversation has grown too long even after Hania shortened it, or the agent's model can't be found. The goal is cleared and the chat says why. Fix the cause, then run /goal again.
• A passing problem. When a reply fails because a service is busy or a connection dropped, Hania tries again about half a minute later, up to three times. The chat shows Retrying after an error. If it still fails, the goal pauses.
• A rate or usage limit. The goal pauses.

A paused goal carries on from your next message. Any other error leaves the goal set.

Background work

While a command the agent started in the background, or a background run of another agent started from the chat, is still going, the check waits for it. The result arrives as a new reply. If the goal is kept waiting, Hania asks the agent to check on that work after 30 minutes, after an hour, and then every two hours, three times at most between your messages. The chat shows Checking in on background work each time.

Planning & quality

Longer runs sometimes drift off course or hand back an answer in the wrong shape. A few settings on the Agent tab help a run stay on track. Apart from the completion check, which is on, 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 if it still cannot, the output is delivered as written and the run's conversation is marked Output invalid. 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. If the agent's previous run is still going or waiting on a person when a scheduled time comes, that time is skipped and no run appears for it.

When you start a run by hand, the Run now dialog has a box for instructions. 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 fails before the agent says anything, for example because the workspace is out of credit, its conversation still shows what the run was asked to do and a message explaining why it stopped.

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.

Starting runs from another service

A service you already use, such as your helpdesk, can start the agent when something happens there. Set it up in the Incoming webhook card on the agent's Agent tab:

1. Copy the Webhook URL and paste it into the other service as the address it sends to.
2. Have that service generate a signing secret and paste it into Signing secret exactly as the service shows it. In LeanDesk, for example, that's Settings → Mailboxes → Outgoing Webhook → Generate.
3. Under Event types, list the events that should start the agent, separated by commas, or leave * for every event. Then choose Save webhook.

Once saved, the secret isn't shown again. To change only the event types, leave the secret box empty. To switch to a new secret, paste it in and save. The old one keeps working for 24 hours, which gives the other service time to catch up. Remove turns the webhook off, and anything the service sends after that is refused.

Each event starts one run, with the event added to the agent's goal. The agent treats the event as information about what happened, not as instructions, and sticks to its own goal. Events of a type you didn't list are skipped, and so is the same event sent twice. If you're writing the sending code yourself, the details are in the API reference.

To start runs from your own code instead, use the API trigger with an API key.

Handing work to other agents

An Autonomous Agent doesn't have to do everything itself. Turn on Agent delegation on its Agent tab, tick the agents it may call on, and it can pass part of a job to one of them and use the answer in its own work. A research agent can ask your writer for a draft. A support agent can check a detail with your billing agent. It can call the agents you tick, each of which has to be another active Autonomous Agent in your workspace, and if it belongs to a team, every member of that team as well.

You can watch it happen. Where the agent hands something off, its conversation shows a Delegated to card with the other agent's name and a live count of its steps. Expand the card to follow those steps, or choose Open its conversation to read the whole exchange: the task it was given and the answer it sent back. That conversation links back to where the task came from, so any piece of work can be traced to the agent that asked for it.

• Several at once. Hand work to different agents in the same step and they work in parallel instead of waiting for each other.
• A person can still step in. If a delegated agent needs an approval or an answer, the request goes to the Review queue and its card reads waiting on a person. The agent that asked waits as well, then carries on by itself the moment you respond.
• Up to three levels. A delegated agent can pass work on again, up to three levels deep.
• Not on phone calls. Delegation works in chats and runs. An agent on a voice call handles the call by itself.

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.

You set a tool's classification on its configuration, under Show advanced at the bottom of the form. The closed row shows the current setting, for example Safety: read-only, so you can check it without opening anything. Each tool's own page says what a new configuration starts with.

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, each one labelled. Long text, such as an article the agent wants to publish, appears formatted the way it reads, with its details (title, slug, status and so on) in a small table above it. Switch to Raw to see the exact text that will be sent. 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. Use Edit on the argument you want to change, and Reset to undo it.
• 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.

Approvals from collection rules wait in the same Review queue, listed above the requests from agents.