> ## Documentation Index
> Fetch the complete documentation index at: https://docs.profy.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Runtime

> The brain of every Expert — core mechanisms of the AI reasoning engine

Agent Runtime is the "brain" of every Expert. When a user sends a message, the Runtime builds the complete conversation context, invokes the LLM for reasoning, executes tool operations, manages multi-turn interactions, and streams the entire process to the user in real time.

## Agent Loop: The Core Reasoning Cycle

Every Expert response is driven by a sophisticated reasoning loop:

```mermaid theme={null}
sequenceDiagram
    participant User as User
    participant Core as Core API
    participant RT as Agent Runtime
    participant LLM as LLM
    participant SB as Sandbox
    participant Tools as Tools

    User->>Core: Send message
    Core->>RT: Build runtime payload
    RT->>RT: Assemble context<br/>(history+memory+skills+tools)
    RT->>LLM: Streaming inference request

    loop Tool call loop
        LLM-->>RT: Text + tool calls
        RT-->>User: SSE: text stream
        RT->>Tools: Execute tool
        Tools->>SB: Sandbox operation
        SB-->>Tools: Execution result
        Tools-->>RT: Tool return value
        RT->>LLM: Continue reasoning with result
    end

    LLM-->>RT: Final response
    RT-->>User: SSE: complete
    RT->>RT: Background self-evolution (optional)
```

## Context Construction

Before each inference, the Runtime carefully assembles context for the Expert — this determines what the AI "knows" and what it "can do":

<Steps>
  <Step title="System persona injection">
    The Expert's core persona (mental models, decision heuristics, expression style) is injected as system instructions, defining the AI's "soul."
  </Step>

  <Step title="History loading">
    Relevant messages are loaded from conversation history. When history gets too long, context compaction is automatically triggered (see [Context Engine](/en/documentation/how-it-works/context-engine)).
  </Step>

  <Step title="Memory retrieval">
    Long-term memories relevant to the current conversation are retrieved from the Expert's memory graph, allowing the AI to remember user preferences and historical context.
  </Step>

  <Step title="Skill loading">
    Relevant skills are dynamically activated based on the conversation scenario — skills give the Expert specialized operational workflows for specific domains.
  </Step>

  <Step title="Tool declaration">
    Based on the Expert's capability configuration and current mode, available tools are declared (code execution, file operations, web search, creative generation, etc.).
  </Step>
</Steps>

## Streaming Output: Real-Time Interaction

Profy uses the Server-Sent Events (SSE) protocol for real-time streaming output. Users don't need to wait for the AI to finish thinking — every token, every tool call, every intermediate state is pushed in real time:

| Event Type      | Meaning                    | User Experience                                     |
| --------------- | -------------------------- | --------------------------------------------------- |
| Text chunk      | AI is generating text      | Typewriter effect, appearing character by character |
| Thinking state  | AI is reasoning internally | "Thinking..." indicator                             |
| Tool call       | AI decided to use a tool   | Shows tool name and arguments                       |
| Tool result     | Tool execution completed   | Displays result card                                |
| Complete signal | Full turn finished         | Enables input box                                   |

<Tip>
  The benefits of streaming go beyond user experience — it also means that even when the AI generates a very long response, users can interrupt at any time via the "Stop" button, saving unnecessary token consumption.
</Tip>

## Multi-Turn Tool Execution

The power of an Expert lies in its ability to "get things done" like a human. In a single response, the AI may need to invoke multiple tools in sequence:

```mermaid theme={null}
graph TD
    A[User: Create a React project and deploy it] --> B[AI thinking]
    B --> C[Tool: Initialize project]
    C --> D[Tool: Install dependencies]
    D --> E[Tool: Write component code]
    E --> F[Tool: Start preview server]
    F --> G[AI: Project is ready, preview URL is...]
```

After each tool call, the AI examines the result and decides the next step: continue executing, fix an error, or report back to the user. This "observe-decide-act" loop is the fundamental difference between an Agent and an ordinary chatbot.

## HITL: Human-in-the-Loop Confirmation

For sensitive operations (such as file deletion, external API calls, or payment operations), the Expert does not execute directly. It first presents the plan to the user and requests confirmation:

<Steps>
  <Step title="AI proposes an action plan">
    The Expert recognizes that the upcoming operation may have irreversible effects, proactively pauses, and describes the plan.
  </Step>

  <Step title="User confirms or modifies">
    The user sees a confirmation card and can approve, modify parameters, or reject the operation.
  </Step>

  <Step title="Proceeds based on decision">
    Continues execution upon approval; switches to an alternative approach if rejected.
  </Step>
</Steps>

The HITL mechanism ensures a balance between AI autonomy and user control — the Expert is smart enough to work independently but won't overstep at critical moments.

## Token Budget Control

Each session has a token budget cap to prevent runaway inference consumption:

* **Input budget**: Automatically triggers context compaction to stay within the model's window
* **Output budget**: Automatically recovers and continues writing when a single response exceeds the limit (up to 3 times)
* **Session total budget**: Gracefully stops when cumulative consumption reaches the cap, rather than cutting off abruptly

```mermaid theme={null}
graph LR
    subgraph Budget Allocation
        Total[Session Total Budget] --> Input[Input Budget<br/>Context compaction control]
        Total --> Output[Output Budget<br/>Truncation auto-recovery]
        Total --> Tools[Tool Budget<br/>Result compression control]
    end
```

<Note>
  The goal of budget control is not to "limit" the Expert's capabilities, but to ensure predictable resource usage. When the budget is nearly exhausted, the Expert automatically switches to more concise response mode, ensuring every token counts.
</Note>

## Plugin-Based Tool System

The Runtime's tool system is driven by declarative Manifests rather than hardcoded logic:

<CardGroup cols={2}>
  <Card title="Sandbox Tools" icon="terminal">
    Code execution (bash), file read/write (read/write/edit), full-text search (grep/glob) — all running in isolated containers.
  </Card>

  <Card title="Creative Tools" icon="palette">
    Image generation, video generation, music creation, speech synthesis — calling specialized model APIs.
  </Card>

  <Card title="Knowledge Tools" icon="book">
    Web search, webpage reading, external knowledge base connectors (Feishu/DingTalk/Yuque, etc.).
  </Card>

  <Card title="Memory Tools" icon="brain">
    Memory storage and retrieval — Experts can proactively remember important information and recall it in future conversations.
  </Card>
</CardGroup>

Each tool is registered via a Plugin Manifest that declares its activation conditions and capabilities. Expert creators can enable or disable specific tool categories as needed, precisely controlling the AI's behavioral boundaries.

## Delegated Execution: Cross-Expert Collaboration

One Expert can delegate specific subtasks to other Experts — like division of labor within a team:

```mermaid theme={null}
graph TD
    Main[Main Expert<br/>Project Manager] --> |Delegate design| Design[Design Expert]
    Main --> |Delegate code| Code[Dev Expert]
    Main --> |Delegate testing| Test[Testing Expert]
    Design --> |Return designs| Main
    Code --> |Return code| Main
    Test --> |Return report| Main
```

Delegated tasks execute asynchronously in the background without blocking the main conversation flow. Users see real-time task progress updates.

## Security Safeguards

The Runtime has multiple built-in security mechanisms to protect Expert creators' intellectual property:

* **Prompt leak detection**: Real-time monitoring of AI output; if system prompt fragments are detected leaking, they are automatically intercepted and replaced
* **Skill content sanitization**: Raw skill text returned by tools is replaced with safe summaries before being sent to the frontend
* **Canary tokens**: Invisible markers embedded in the system prompt make any copying behavior traceable

<Tip>
  Security is not an afterthought — it's the Runtime's first design principle. From context construction to final output, every step has corresponding security checkpoints.
</Tip>

## Performance Characteristics

| Metric                  | Typical Value         | Description                                     |
| ----------------------- | --------------------- | ----------------------------------------------- |
| Time to first token     | \< 1s                 | From receiving request to first token delivered |
| Tool execution latency  | \< 3s                 | Average command execution time in sandbox       |
| Context compaction      | \< 2s                 | Additional latency when compaction is triggered |
| Max concurrent sessions | Horizontally scalable | Each Pod processes independently, stateless     |

The Runtime is a stateless service — all session state is stored externally (database + Redis), meaning it can scale horizontally to any concurrency level. If any Pod goes down, no user conversations are lost.