How Endue works
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
Section titled “The loop”A run is one pass through this cycle, repeated until the agent has an answer or needs you.
-
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.
-
Decide. It picks the next action — call a tool, ask you a question, or answer.
-
Act. If it chose a tool, the tool runs. You see the call and its result as it happens.
-
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.
-
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
Section titled “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
Section titled “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
Section titled “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.
What this means in practice
Section titled “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.