# AI Agent > Hand one step of a workflow to an AI that works out its own approach, while the rest of the workflow runs by your rules. The AI Agent step handles work that needs judgement rather than a rule, and that takes more than one move. You give it a goal and the accounts it may use, and it works out the steps itself. That covers reading a company's website, deciding how urgent a message is, or making sense of input nobody formatted. For a single call with no tools (classify this, summarise that) the [AI Prompt](/build/ai-features/ai-prompt) step is simpler and faster. ![The AI Agent step selected on the canvas, with its settings open: the identity it has been given and its primary goals.](/images/docs/ai/ai-agent-step.webp) *The agent's identity and goals are the whole brief. It knows nothing you do not write into these two fields.* The rest of your workflow does not change. Everything before and after the agent still runs by your rules, in the order you drew. The agent is one step where the answer is worked out rather than looked up. Two things define what it can do: 1. **Primary goals**: what you want it to achieve. 2. **Tools**: the accounts it is allowed to act through. It can use nothing else. The AI Agent works in a loop: it reads the goal, picks a tool, reads the result, and repeats until it can answer. ## Setting it up ### Choose the model Open the **Brain (model)** dropdown and pick the model that will drive the agent. It runs on Glow's managed infrastructure, so there is **no API key to configure**. See [Models](/build/ai-features/supported-models) for how to choose. ### Write the Primary goals Say what the agent is for. This can be static text, data from earlier steps, or both. _Example:_ "Research the company that just filled out our lead form, find their most recent product launch, and draft a personalised outreach email." > **The agent sees only the text you put in these fields.** It has no view of > the workflow around it. A reference to an earlier step must be written into > the prompt as a placeholder, such as `{{ 3.ret.company }}`, for the agent to > know that value at all. Nothing arrives implicitly. ### Give it an Identity **Identity** says what the agent _is_, where Primary goals says what it should _do_. For example: "a customer support assistant for an accounting product", or "a research assistant that never speculates". It is optional, and worth filling in whenever the same goal would be handled differently by different kinds of assistant. ### Equip Tools Open **Tools** and switch on the accounts the agent may act through. Each one you turn on becomes a set of actions it can call. A Slack account lets it post messages, and a HubSpot account lets it read and update records. ![The Tools list in the AI Agent's settings, with a toggle beside each connected account.](/images/docs/ai/ai-agent-tools.webp) *Every account is off until you turn it on. The agent can act through the ones switched on here and nothing else.* The model may pick the wrong tool, or reach for one it should leave alone. **Tool Instructions** under Optional Props is where you tell it when to use which. > **The agent cannot reach anything you have not listed here.** It acts through > the same connections the rest of your workflow uses. It cannot create, delete, > or re-authorise one. Tools has two halves: the accounts you switch on here, and the workflows you have already built, listed below them under **Workflows**. Three tools come with every agent as well, whether or not you connect an account: - **Search the web** for something it does not know. - **Run code** to calculate, reshape or check a value. - **Read a URL you give it** — a web page, and also a PDF, an image, or a CSV or JSON file. The address has to be publicly reachable: a link behind a login or inside your private storage returns nothing, so pass the contents in through the prompt instead. ### Hand it a workflow you already built Below the accounts, the Tools panel has a second section headed **Workflows**. It lists the reusable workflows in your workspace that the agent is allowed to run, and each one is switched on with the same toggle. Each workflow you turn on gets its own free-text box, **When should the Agent use this?**, which tells the model when to reach for it. It arrives filled in with `Use this tool to run {name} and return its result.` Replace that with the actual trigger: "Use this when the customer asks about a refund and you need their order history." This is the strongest way to constrain an agent. The judgement stays with the model, and the steps stay yours — drawn on a canvas, tested, and unchanged by whatever the agent decides. Where a rule is fixed, put it in a workflow rather than describing it in the prompt and hoping. ### Shape the behaviour Everything else sits under **Optional Props**. Click **Show more** to see the full set. All of it is prompt material: what you write here reaches the model, and nothing else does. | Field | What it does | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Background information** | Context the agent should assume: your product, your customers, anything it cannot infer. | | **Dos and Don'ts** | Behaviour it must always or never exhibit. | | **Tool Instructions** | When to reach for which tool, rather than leaving the choice entirely to the model. | | **Safety Constraints** | Hard limits it must not cross. | | **Error Handling** | How to behave when it hits an error or something unexpected. | | **Output Format** | The shape the answer should take. | | **Style** | Tone, voice and register. | | **Examples** | Sample inputs and the outputs you want for them. | | **Step by Step** | A reasoning process to follow, when the order of work matters. | | **Memory Enabled** | Off by default. Turn it on to carry context across runs. Reveals **Memory Instructions**, where you say what is worth remembering. | | **Think Tool Enabled** | A dedicated reasoning pass before answering. **On unless you switch it off.** Better on ambiguous tasks, slower everywhere: turn it off for a narrow, well-specified agent running at volume. | > **Memory belongs to the workflow, not to you.** Every run of this step reads > and writes the same memory, whoever started it. A colleague who runs the > workflow picks up what the agent already learned, and anything it learns on > their run is there on yours. That is the point: an agent that forgot > everything each time somebody else ran it would never get better at the job. > > Two workflows never share memory, even in the same workspace and even when one > is a copy of the other. So a second agent built for a different job starts > clean, and you can keep a sensitive workflow's memory away from the rest. > > Memory belongs to a saved workflow, so a run that is not attached to one — a > step tried out on its own before the workflow exists — remembers nothing and > leaves nothing behind. Save the workflow first if you are testing what the > agent learns. > **Running one workflow for several clients?** The memory follows the workflow, > so every client's runs read and write the same store. That is what you want > for one client's own automation, and not what you want for a workflow you > operate across an entire book of business. > > Give each client their own copy of the workflow, and their agents keep their own > memory. Where a single shared workflow is the right shape, leave **Memory > Enabled** off and pass the context in through the step's fields instead: what a > run needs is then explicit, and nothing carries between clients. #### Output Format and Examples earn their keep These two are what make an agent usable by the rest of your workflow. An agent whose answer is free prose forces the next step to pick it apart. Tell it instead to return `{"decision": "approve"|"reject", "reason": "..."}`, and show it an example of exactly that. You then have something a [Condition](/build/action-steps/conditions) can route on. If you find yourself building fragile text-matching after an agent, the fix is usually these two fields rather than a cleverer step downstream. ## What it passes on The agent hands back two values on the step: | Reference | What it holds | | ------------------ | -------------------------------------------------- | | `{{ N.result }}` | The answer itself | | `{{ N.thoughts }}` | Its reasoning along the way, useful when debugging | Give it an Output Format that asks for JSON and you can reach inside the answer directly: `{{ N.result.urgency }}`. Run the step once and check the Executions tab to confirm the shape before you build on it. > **Run the step once and read the Executions tab before wiring the next one.** > A reference that finds nothing stops the run and names itself in the message, > whether the step number is wrong or the path after it is. Checking the real > path against a run catches both before they cost you a run. ## How the agent reaches your accounts Every account you switch on opens its own connection when the step runs, acting as the same person who authorised it, and closes again when the step finishes. An agent can never reach further than the account you gave it. The agent then asks each connection what it can do, rather than working from a list we ship. Two useful things follow from that. **New actions arrive on their own.** When an app gains an action, your agent can use it. Nothing to update, nothing to re-connect. **The choice is made during the run.** Which action the agent reaches for is decided as it works, not fixed in the settings beforehand. That is what **Tool Instructions** is for: it is where you say which to prefer. You configure none of this. Switching the account on is the whole setup. ## Getting the same fields every time The agent carries the same **Response shape** option as AI Prompt. You will find it in the main form, directly below Primary goals. Describe the structure you want and the agent's answer holds that shape on every run, so a later step can read `{{ 4.result.status }}` and know it is always there. See [Getting the same fields every time](/build/ai-features/ai-prompt#getting-the-same-fields-every-time). ## Approving what the agent does Some actions cannot be taken back: an email to a customer, a refund, a record deleted. Put a [Human Review](/build/action-steps/user-approval) step between the agent and the action. The run pauses, someone approves it from the canvas, and only then does it go ahead. Worth doing whenever being wrong costs more than waiting. ## Recovering from a failed run An account may not connect, a service may be down, or the data may not be there. The agent then stops with an error rather than guessing. You handle a failed agent like any other failed step. Draw an **Error Path** from the step to a fallback, such as a manual review task. The mechanics are ordinary [Error Handling](/build/core-concepts/error-handling); nothing about the agent changes them. > This bounds what happens when the agent's *tools* fail. It does not guarantee > the model's reasoning is correct. For decisions with consequences, put a > [Human Review](/build/action-steps/user-approval) step between the agent and > the irreversible action, as above. ## Limits A workflow the agent calls has two minutes to answer. Keep a called workflow short, or move slow work behind its own trigger so the agent starts it and does not wait for it. See [Calling Another Workflow](/build/action-steps/trigger-workflow) for how subflows are built and what they return. ## Examples to copy Use these configurations as starting points, then adapt the goals, constraints, and output to your workflow. ### Blueprint 1: B2B Company & Prospect Research Equip the agent with the built-in **Search the web** and **Read a URL you give it** tools to perform deep prospect research before a sales outreach. **Identity** ``` A meticulous B2B market intelligence researcher that extracts verified company information and never hallucinates facts. ``` **Primary goals** ``` Research the company with domain "{{ 1.email | extract_domain }}" using web search. Find their primary value proposition, target customer profile, estimated headcount, and any notable product announcement from the last 90 days. Email: {{ 1.email }} Lead Name: {{ 1.name | title_case }} ``` **Output Format** ```json { "company_name": "string", "industry": "string", "value_proposition": "one clear sentence", "target_market": "SMB | Mid-Market | Enterprise", "recent_news": "string or null", "recommended_outreach_angle": "string" } ``` **Dos and Don'ts** ``` Do check the official company website before secondary directories. Don't speculate on revenue or headcount if not publicly stated. If unknown, return null. ``` --- ### Blueprint 2: Customer Support Triage & Sentiment Router Triage incoming customer tickets, verify account tier using your connected CRM, and output clean JSON for downstream [Switch](/build/action-steps/switch) steps. **Identity** ``` A technical customer support triage specialist for a SaaS platform. ``` **Primary goals** ``` Analyze the customer's message: Customer: {{ 1.name }} ({{ 1.email | lower }}) Message: {{ 1.message | strip_html | trim }} 1. Look up the customer's domain ({{ 1.email | extract_domain }}) in HubSpot to verify their tier. 2. Determine urgency and issue classification. 3. Draft a resolution based on the issue description. ``` **Output Format** ```json { "urgency": "Critical | Normal | Low", "category": "Billing | Authentication | Bug | Feature Request | How-To", "tier": "Enterprise | Standard | Free", "sentiment": "Frustrated | Neutral | Delighted", "draft_reply": "string", "requires_human_review": true } ``` **Safety Constraints** ``` Never promise feature timelines, SLA credits, or custom contractual terms. If the customer threatens legal action or churn, set urgency to "Critical" and requires_human_review to true. ``` --- ### Blueprint 3: DevOps Incident & Log Analyzer Equip the agent with your connected **GitHub** and **Jira** accounts to analyze error logs from production webhooks. **Identity** ``` A Site Reliability Engineering (SRE) assistant that diagnoses stack traces and assigns bug severity. ``` **Primary goals** ``` Analyze the following error payload from our APM monitoring webhook: Service: {{ 1.service_name }} Error: {{ 1.error_message }} Stack Trace: {{ 1.stack_trace | truncate:2000 }} 1. Identify the root cause module. 2. Search GitHub for open issues matching the error signature. 3. If an existing issue exists, provide the issue number; otherwise draft a Jira bug summary. ``` **Output Format** ```json { "severity": "P1 | P2 | P3", "root_cause_module": "string", "is_known_bug": true, "jira_summary": "string", "jira_description": "string", "recommended_fix": "string" } ``` --- ## What's Next? - 👉 **[Connect an App →](/manage/apps-and-integrations/connecting-an-app)**: connect the accounts the agent can use as tools. - **[Human Review](/build/action-steps/user-approval)**: require approval before an irreversible action. - **[AI Data Transform](/build/ai-features/ai-transform)**: reshape the agent's answer for later Steps.