How AI agents decide, mapped from their code

When the approval policy calls for it, the agent pauses before an action until the app approves or rejects it. If you send a new message instead, and the app then runs the conversation again without rejecting, the waiting action is attempted as if you had approved it. A message saying "wait, not that" does not by itself cancel the action.

With the goal feature, a judge model is asked for a short structured reply that includes a "complete" field. The code turns that field into yes or no with a Python conversion (bool) that counts any non-empty text as yes, including the word "false". So if the judge writes "false" as text in that field, the goal is marked complete.

You can register secrets, such as service access keys, so they are masked in text replies that contain no request to use a tool. When the model puts a registered secret into a request to use a tool, such as a shell command, the details of that request are written to the conversation record without masking, and when the model gives no summary of the request, the automatic summary repeats them. Anyone who can read that record can read the key.

On the command line, a shell command the agent runs is stopped after 30 seconds by default and the agent is told it timed out, so a long build, test run or install can be stopped partway. Cline's tracker has two open reports about this limit.

File edits are given a time limit, but reaching it only tells the model the edit failed; the edit itself is not stopped. So the model can be told an edit timed out while the change still lands in the file.

When the history is shortened, the model's summary replaces the older messages. If the summary was cut off before the model finished it, code still puts it in place; only an empty summary is skipped.

A program reads the success flag in the model's done call at the end of a run. If the model leaves the flag out, code records success. When the developer asks for a structured result, that field is hidden from the model, so such a run normally reads as successful unless the model sets it anyway. An open pull request in browser-use's tracker proposes a fix.

A whole step gets 180 seconds by default. If it runs over, it is cut off, the record of which of the step's actions finished is dropped, and the step's result is only a timeout error. If the run takes another step, the model sees the page as it now is, which may show some effects, but it is not told which of its actions already ran. We found no report of this in browser-use's tracker.

On Mac and Linux, pressing Ctrl+C pauses the run and prints "Press [Enter] to resume or [Ctrl+C] again to quit". Pressing Enter does not resume it; only code that calls agent.resume() does, so a person at the terminal can quit with a second Ctrl+C but cannot continue the run from there. We found no report of this in browser-use's tracker.

When a session has no model of its own and the model its agent is set up with is not among the available models, code uses the default model instead. Nothing tells you the agent is running on a different model from the one it was configured with.

For the models that edit files through patches (some GPT models), each change is placed at the first spot, searching from the end of the previous change, where its lines match, trying looser matches (ignoring spaces at the ends of lines, then at both ends) when there is no exact match. If the same lines appear more than once, the change goes to the first of them; the edit tool that other models use returns that case to the model as a failure unless it was asked to replace every match.

By default an agent has no step limit, and the map found no check in the current core for a model that keeps making the same tool calls, so a run whose repeated calls keep succeeding has no built-in limit and can go on until you stop it. opencode's tracker has an open discussion of this (#59339) and an open pull request that proposes loop detection.

In a one-shot run, pi joins piped input, the text of @file arguments and the first message into one prompt with no separator between them, so the end of one part runs straight into the start of the next. pi's maintainers closed the report about this as not planned.

When you run a command yourself with !, pi keeps only the tail of a long output. After older output has been dropped, the flag that says the output was cut can still read false.

When a request fails, pi recognizes that it overflowed the model's context by matching the error text against a list of known provider messages. Wording the list does not know is treated as an ordinary error, so pi does not compact the history and retry. pi's tracker has an open report about one such message.

The run ends as soon as the model replies without asking for a tool, and the shared run loop does not look at why the model stopped (some provider adapters only log a warning). So an answer cut short by the output-token limit, or refused, comes back as the answer with the run marked completed, and the caller cannot tell it from a finished one. An open pull request proposes reporting the provider's stop reason.

When the developer asks for a structured answer and the model's text cannot be turned into it, agno keeps the raw text, logs a warning, and still marks the run completed. Code that expects the structured object gets plain text instead unless it checks the type itself. An open pull request proposes an opt-in way to report the failure.

From the second step of a workflow on, an agent or team step receives only the previous step's output, not what the user first asked; the original request reaches it only when the previous step produced nothing. The function's own description says it combines the two, so a step can end up working without the user's question in front of it.

On the shared OpenAI-compatible tool-calling path, if the model asks for more than one tool in a single reply, only the first is run and the others are dropped without the model being told. A request that needs several lookups or actions can come back with part of the work left undone unless the model notices and asks again.

A workspace's chat history setting decides how much earlier conversation plain chat sends (20 when it is unset or zero). The agent does not read it: it always starts with the newest 20 saved exchanges, so a workspace set to send less, or more, gets 20 in agent mode.

Every 3 hours by default, a background job reads a person's recent chats to pick out facts worth remembering. Once a group of chats passes the first two checks it is marked processed whatever happened, so if the model call fails or no model is set up, the job does not come back to those chats on its next run. Only the latest 20 are read, so in a larger group the older chats are marked processed without being read.