Skip to content

How It Works

This page explains what happens under the hood when your agent receives a task and responds — so you understand why it behaves the way it does and how to get the best results.


Every interaction with an agent follows this lifecycle:

  1. Receives your message — from the console, your app, a flow trigger, or a deployed channel
  2. Plans — decides what information it needs and what steps to take
  3. Searches its knowledge — if you’ve connected one, it retrieves relevant context
  4. Uses tools — takes real actions: reads from GitHub, sends a Slack message, queries a database
  5. Reasons and responds — synthesizes everything into a clear, grounded answer or output
  6. Streams back to you — you see the response as it’s generated, not after a long wait

Auteryn runs each task in Auto, Fast, or Deep mode:

Mode Best for Speed
Auto Internal agents — SmartRouter picks Fast or Deep per task Varies
Fast Quick questions, lookups, chat, customer-facing agents Seconds
Deep Complex reasoning, multi-step tasks, research, code generation Minutes (up to ~2 hours per run)
  • Customer-facing agents always use Fast mode
  • Internal agents default to Auto (SmartRouter chooses Fast or Deep)
  • You can override to Fast or Deep in Agent → Settings → Execution Mode

Auteryn isn’t locked to a single AI vendor. When you create an agent, you choose which model provider powers it:

Provider Good for
Gemini A strong, well-rounded default — fast, capable, great value across most tasks
Claude Careful reasoning, coding, and following nuanced instructions
GPT Broad general-purpose capability across writing and analysis
Forge Select An Auteryn-managed option optimized for speed and cost

Every provider works with the same capabilities, integrations, knowledge, and skills — switching providers doesn’t change what your agent can do, only the underlying model that reasons about it. Each provider automatically uses a lighter or more powerful model depending on whether the task runs in Fast or Deep mode.


When the agent needs to take an action, it calls a tool. Here’s what that looks like in practice:

Example task: “Review the open PRs in our repo and flag anything that’s been waiting more than 3 days.”

  1. Agent calls the GitHub tool → fetches open pull requests
  2. Agent filters PRs older than 3 days
  3. Agent calls the Slack tool → posts a summary to the designated channel
  4. Agent returns a response confirming what it did

Each tool call is logged and visible in the Run History tab on your agent page — so you always know exactly what the agent did.


When your agent has a knowledge, it doesn’t load all the documents every time. Instead:

  1. Your message is converted into a semantic search query
  2. The most relevant chunks are retrieved from your knowledge
  3. Those chunks are injected into the agent’s context before it responds
  4. The agent answers based on your content — citing the source document

This means the agent only “sees” what’s relevant to the current task — you can have very large knowledge collections without performance issues.


When you enable the Browser capability, your agent can use browser automation and Computer Use (vision-based UI control) inside an isolated sandbox:

  1. Agent acquires or reuses a sandbox session (one per agent in your org)
  2. Navigates to the target website
  3. Takes a screenshot and identifies UI elements
  4. Clicks, types, scrolls, or extracts data via Computer Use when needed
  5. Reports back with results and optionally a screenshot

The browser runs in a completely isolated container. It cannot access your local machine. See Computer Use → for setup and use cases.


All agent responses are streamed in real time — you see the agent’s thinking and actions as they happen, not a single response after a long wait. This is especially useful for long-running tasks where you want to monitor progress.

In the Test panel, responses stream word by word. Tool calls appear inline as they happen.