Agents

How the agent runs (workflow & stop reasons)

The Temporal workflow loop

Every agent conversation runs as a long-lived Temporal workflow. When you send a message, the workflow spins up (or resumes) and the agent enters an iterative loop:

  1. Reason - the LLM decides which tool to call next (or whether to reply to you).
  2. Act - execute the chosen tool (write code, run tests, search the web, etc.).
  3. Observe - collect the tool result and append it to the conversation context.
  4. Repeat - loop back to step 1 until a stop condition is met.

This architecture lets the agent chain dozens of actions autonomously - committing files, spinning up preview servers, invoking subagents - without requiring your approval at every step.

Temporal resilience

Because the workflow state persists in Temporal, the agent can survive transient infrastructure failures and resume exactly where it left off.

Stop reasons

The loop terminates when any of these conditions is true:

Stop reasonMeaning
context_overflow
The conversation history exceeded the model's context window; the agent cannot fit the next turn.
max_iterations
The agent hit the per-turn iteration cap (10,000 steps) to prevent runaway loops.
insufficient_credits
Your account balance dropped below the cost of the next tool call.
end_turn
The agent finished the task naturally.
handoff
The agent handed control to another agent.
error
An unrecoverable workflow error occurred (rare; usually retried automatically).

When the loop stops, you'll see a status indicator in the chat. An

end_turn
stop is normal and means the agent has completed your request. A
handoff
stop means the task has been passed to another agent.
context_overflow
or
max_iterations
usually signals the task grew too large for a single turn; break it into smaller requests or start a fresh conversation.

Context overflow

If you hit

context_overflow
frequently, try asking the agent to summarize progress before starting a new subtask, or split the work across multiple chat threads.

Iteration and time caps

To keep costs predictable and prevent infinite loops:

  • Iteration cap: 10,000 tool calls per user message (adjustable in the future for enterprise plans).
  • Time cap: workflows time out after 4 hours of wall-clock time, though most tasks complete in seconds to minutes.

The agent tracks its own loop count and will gracefully hand off as it approaches the iteration limit, summarizing what it accomplished and what remains.

Agent tools & their credit cost

The agent has access to a rich built-in toolset via the sandbox MCP server:

  • File operations - read, write, edit, list, move, delete files in your project.
  • Shell execution - run
    npm
    ,
    pnpm
    , framework CLIs, git commands.
  • Preview server - spin up development servers and capture screenshots.
  • Codex code review - Codex reviews GitHub PRs via its workflow (linting, security scans, style checks).
  • Testing agent - writes and executes unit/integration/E2E tests in a separate subagent.
  • Design agent - generates UI mockups and design assets.

Free sandbox tools

Most MCP sandbox tools (file I/O, shell, Codex) have no additional credit cost beyond the base LLM inference. You pay only for the model's input/output tokens.

Some server-side tools do incur extra charges:

  • Web search - ~$0.01-0.014 per request (approximately 0.05-0.07 credits per query, varies by provider).

  • Media generation (images, videos) - cost depends on resolution and model; typically 5-20 credits per asset.

When the agent calls one of these tools, the credit deduction happens immediately. If your balance is too low, the workflow stops with

insufficient_credits
and prompts you to recharge.

E-1, E-2, and E-3 agents

Emergent offers three distinct agents, selectable from the agent dropdown when creating a job:

  1. E-1 - the default step-by-step builder; runs a structured, incremental workflow.

  2. E-2 - an intermediate agent with a different workflow balance between autonomy and oversight.

  3. E-3 - an opt-in autonomous agent that runs end-to-end, using E-1 as a sub-agent internally; only finishes or hands off when the task is complete.

E-1 is the default agent. E-3 is opt-in for those who want fully autonomous runs. Agents cannot be switched mid-conversation (forking keeps the selected agent).

Tip

E-3 is ideal for iterative development (bug fixes, feature additions) where you want minimal interruptions. For major refactors or schema changes, E-1's step-by-step approach gives you more visibility.

Subagents and specialization

Complex tasks often spawn subagents - ephemeral worker agents with narrow mandates:

  • Testing subagent - writes test cases, runs them, reports coverage. Invoked via the

    run_tests
    tool.

  • Design subagent - generates wireframes, color palettes, component designs. Invoked via

    generate_design
    .

  • Review subagent (Codex) - performs linting, security scans, style checks. Codex reviews GitHub PRs via its workflow.

Subagents run in parallel Temporal workflows and report results back to the parent agent. Their credit usage rolls up into your main conversation's total. This division of labor keeps context focused: the main agent handles orchestration, subagents handle depth.

Auto-HITL (human-in-the-loop)

In autonomous runs, when the agent encounters a question it needs answered, Auto-HITL automatically generates the answer so the workflow is not blocked. This means autonomous runs can continue without pausing for your input on routine clarifications.

Auto-HITL engages when:

  • It encounters an ambiguous requirement ("Should the button be primary or secondary?").
  • A tool fails multiple times and the agent can't auto-recover.
  • The task requires a decision outside its training scope (legal compliance, branding choices).

In autonomous runs, Auto-HITL auto-answers the agent's ask_human (assuming a sensible default and continuing) so the run is never blocked; it does not pause for the user.

Note

Auto-HITL keeps autonomous runs unblocked by auto-answering the agent's questions. The iteration and time caps continue running during autonomous operation.

Monitoring workflow health

The workspace UI displays:

  • Current step count - how many iterations the agent has consumed this turn.
  • Estimated credits remaining - live balance update as tools execute.
  • Subagent activity - spinner badges when parallel workers are running.

If a workflow stalls or you suspect an infinite loop, you can cancel it from the chat overflow menu. The agent will gracefully shut down and hand off with a summary of partial progress.

For a deeper explore workspace controls, see A tour of the workspace.

Was this page helpful?

Related pages