# How Endue works
> What actually happens between the moment you send a message and the moment an agent hands you a result.
When you ask an Endue agent to do something, it does not answer in one shot. It works in a loop: decide, act, look at what came back, decide again. Understanding that loop is what turns a frustrating agent into a useful one, because almost every question about behavior — why it did that, why it stopped, why it asked you something — is a question about the loop.
## The loop
A **run** is one pass through this cycle, repeated until the agent has an answer or needs you.
1. **Read the context.** Before anything else the agent assembles what it knows: its system prompt, the conversation so far, relevant memories, and the project it is working in.
2. **Decide.** It picks the next action — call a tool, ask you a question, or answer.
3. **Act.** If it chose a tool, the tool runs. You see the call and its result as it happens.
4. **Look at the result.** The tool's output goes back into the context. A failed call is information too: the agent sees the error and can try something else.
5. **Repeat.** Back to step 2 with more information than before.
The agent exits the loop when it has what it needs, when it needs something from you, or when it hits a limit.
## What the agent can see
An agent is not omniscient about your account, and this is deliberate. At the start of a run its context contains:
| Included | Not included |
| --- | --- |
| Its system prompt, at the current revision | Other agents' conversations |
| This conversation's history | Conversations you had with this agent elsewhere, unless in the same thread |
| Memories it saved that are relevant now | Everything it ever remembered — memory is selected, not dumped |
| The project's context, if the conversation is in one | Data from services you have not connected |
| The tools it is allowed to use | Tools bound to other agents |
This is why binding matters. Connecting Gmail to your account does not put your inbox in every agent's context — you bind the connection to the agents that need it, and only those agents can see it.
## Why runs pause
A run stops mid-flight for exactly three reasons. Each one looks different in the conversation.
**It needs information only you have.** The agent asks a question — a choice between options, some free text, or a set of preferences — and waits. Answering resumes the work.
**It wants to do something irreversible.** Sending an email, posting a message, deleting data. The run pauses and shows you the exact action with the exact arguments. This gate is not configurable.
**It wants an ability it does not have.** If a skill would help but is not bound to it, the agent can ask for it rather than failing. You grant or decline in the conversation.
## Where the work happens
Runs execute on Endue's servers, not in your browser tab. That has one consequence worth knowing: **closing the app does not stop the work.**
Start a long task, close the tab, and come back later — the run kept going, and the result is waiting. This is also what makes routines possible: a scheduled run does not need anyone to be watching.
If you want the opposite — work that happens on your own machine, with access to your local files — that is what the desktop app's local runtime is for. See [Surfaces](/docs/get-started/surfaces/).
## What this means in practice
Three habits follow directly from how the loop works:
**Give the agent a way to check itself.** The loop is only as good as the feedback in step 4. A task where the agent can verify its own work — search and confirm, write and re-read — goes better than one where it has to get it right blind.
**Be specific about the goal, not the steps.** The agent picks its own actions in step 2. Telling it *what a good result looks like* gives it something to aim at; scripting each step fights the loop.
**Correct early.** You can steer a run while it is going. A correction at step 3 costs one step; the same correction after the run finishes costs the whole run.
## What to read next