> ## Documentation Index > Fetch the complete documentation index at: https://80x.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Let AI own a stage > An AI agent owns one stage of your funnel, reads but never writes, runs only on records that pass a free filter, and you prove its cost on a sample first. An AI agent owns one stage of your funnel, reads but never writes, runs only on records that pass a free filter, and you prove its cost on a sample first. In the earlier paths, a workflow helped a person do the work. In this path, the workflow does the research and qualification for a whole stage on its own. Three rules keep it safe. The agent only reads, never writes. It only runs on records that clear a bar you set. And you know what a run costs before you publish. This is a guided path. It teaches the approach, then walks you through the matching [Guides](/guides) builds in order. Come here to learn the sequence; go straight to [Guides](/guides) when you just need one build. **Prerequisites:** finish [Capture and qualify](/learn/capture-and-qualify), then read [Permissions & workflow access](/explanation/permissions-and-access) and [Infinite loops and safety](/explanation/infinite-loops-and-safety). **By the end you can:** stand up a read-only research-and-qualification agent that owns a funnel segment, and reason about its permissions, credit cost, and loop safety before you publish. This path is written for the solo Attio consultant, or the technical RevOps lead, who reuses agent patterns across client workspaces. In that work, a surprise credit bill can get you fired. So every pattern here defaults to read-only access and spend you can see in advance. ## The shift this path makes An owned stage hands a slice of the funnel to an agent block instead of a rep. An agent is an AI block that can research a record and the web, then answer questions about it. The agent reads the record under the [**Run as**](/explanation/permissions-and-access) permission model, which sets the identity and tools it runs with. It decides fit and writes its conclusion to a field that later blocks route on. A free [**Filter**](/reference/conditions/filter) sits in front of the agent. A filter is a block that stops a run when a record does not meet your conditions. It lets the agent spend only on records that deserve the look. Cost control is the whole game here. AI blocks charge by the token, which means they bill for how much text they read and write. So you cannot know the price up front. You sample a few runs before you trust the pattern. The read-only setup is what makes it safe to hand a stage to an agent. An agent's tool access is read-only, gated by the **Run as** model. Run it as the workflow itself, with the fewest read tools turned on. Run it as a member only when the task truly needs one person's private context. Pair that with a guard filter, and the worst case is wasted reads, not corrupted data or a runaway loop. ## Build the owned stage These steps stand up the pattern on a Companies funnel. Treat the [**AI ICP-fit research and routing**](/guides/signals-and-ai/inbound-lead-research) recipe as the full, field-level build. The steps below are the reasoning you apply to any owned stage. Wire the workflow to [**Record command**](/reference/triggers/record-command) first, so a person clicks **Run workflow** on a record to fire it. Manual runs keep spend tied to human intent while you prove the pattern. Swap in an automatic trigger such as [**Record added to list**](/reference/triggers/record-added-to-list) only after the credit math holds. Put a [**Filter**](/reference/conditions/filter) immediately before the agent. Let only records that clear your ideal customer profile (ICP) threshold continue. ICP is your definition of a good-fit customer. The filter uses no credits, so a stopped run costs nothing. This one block keeps the token-priced agent away from low-fit records, so you never pay to research them. Add a [**Web agent**](/reference/agents/web-agent) or [**Custom agent**](/reference/agents/custom-agent) and give it a read-only **Run as** identity. It can then read records and the web, but it cannot write. Ask two to four specific qualification questions. Tell the agent to answer `unknown` when it cannot verify a claim. Turn on web access only when the task really needs it. Text on an outside page can sway how the agent behaves, so keep that door closed unless you need it. Feed the agent's answer into [**Classify record**](/reference/ai/classify-record). This turns the agent's free text into a single `A`, `B`, or `C` fit band on the record. A band is one clean value that later blocks can branch on. The agent's free text is not, so it cannot route on its own. The band keeps routing predictable, even though the research behind it is a judgment call. Agent outputs are not saved automatically. So follow the agent with [**Update record**](/reference/records/update-record) and map the summary into a long-text attribute such as `icp_research`. Route only the qualified bands onward: assign an owner, post to `#revenue`, and create a first-touch task. Let the `C` band stop. Writing the band to a source field also acts as an idempotency stamp. That is a marker the workflow can check, so it never runs the same record twice. This stamp is part of how you keep the workflow from looping on itself. Run the workflow manually on about ten representative records. Read the per-run cost in run history before you wire it to a live trigger. AI blocks are variable, so you measure the cost rather than estimate it. When the sampled cost holds against your expected monthly volume, swap **Record command** for the automatic trigger. For client work, keep it on a command so spend stays explicit. Say the agent reads a record, then writes back to an attribute the trigger watches. That write can fire the workflow again, against the same record. Three guards stop this. Scope the trigger to one attribute. Never write the attribute the trigger watches. And add an early filter on `Updated by` → Type → is not → Workflow. See [Infinite loops and safety](/explanation/infinite-loops-and-safety) for the full guard set. ## What a run costs A run's cost is the agent's token-based charge plus 1 credit for each write the workflow makes. The filter, the trigger, and any branching logic are free. Per-workflow credit caps were removed in the new engine. So nothing caps your spend now. The filter and your ten-record sample are what keep it in check. For the full cost model, plan allowances, and how token-based AI pricing works, see [Credits & pricing explained](/reference/credits-and-pricing). ## Where this goes next The Challenge for this path is the [**AI ICP-fit research and routing**](/guides/signals-and-ai/inbound-lead-research) recipe. Gate a read-only agent behind a filter so it runs only on records that clear your bar. Classify fit, write the summary to source fields, and route only the qualified records. Prove the credit math on a ten-record sample before the live trigger. For client work, fire it from a command so spend is always explicit. ## See also * [AI ICP-fit research and routing](/guides/signals-and-ai/inbound-lead-research) * [Funding-signal outbound that beats competitors to a fresh raise](/guides/signals-and-ai/funding-signal-outbound) * [AI agents playbook](/guides/signals-and-ai/ai-agents-playbook) * [HTTP and JSON patterns](/guides/platform-patterns/http-json-patterns) * [Credits & pricing explained](/reference/credits-and-pricing) *** *Source: [Attio Workflows block library](https://attio.com/help/reference/automations/workflows/workflows-block-library) and [managing access to objects](https://attio.com/help/reference/managing-your-data/objects/manage-access-to-objects). Last reviewed against the Attio Help Center, June 2026.* This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.