Skip to main content
Two things make an agent behave badly, and neither is length. The first is instructions that conflict or leave room for interpretation. The second is the agent inventing an answer because it had no good information to work from. Almost every piece of guidance below exists to prevent one of those two. This guide is the single reference for where each piece of information belongs, and how much detail each field deserves. It covers the fields you configure in the Agent Management Studio (AMS): Purpose, Policy, Additional information, Knowledge contexts and Tools.

​
The short version

Purpose is not a one-liner. This is the most common misconception. For an agent with tools, Purpose is where you write the operating manual: what each tool does, when to reach for it, and what a good answer looks like. A thin Purpose is one of the main reasons tool-using agents pick the wrong tool or give shallow answers.
The most common mistake is putting reference material into Policy or Additional information when it belongs in a Knowledge context. The second is leaving Purpose too thin for the job the agent has been given.

​
How the agent actually receives your configuration

Understanding this explains most of the guidance that follows. Your configuration isn’t handed to the agent as a form. Each field is compiled into one labelled block of instructions, assembled in a fixed order every time the agent runs:
Three things follow from this. Every field ends up in the same system prompt. The labels differ, and they’re written to signal intent — Policy arrives under “rules you must obey”, Additional information under a neutral heading. But there’s no separate priority channel and no guarantee that one section overrides another. Placement is about putting content where it reads clearly and consistently, not about buying it precedence. Fields you leave empty are dropped. An empty field doesn’t produce an empty heading — the section is omitted. There’s no cost to leaving a field blank and no benefit to padding it out. The one exception is Output formatting: leave it empty and the agent still receives a minimal default formatting instruction. Knowledge contexts are not in this list. Contexts aren’t loaded into these instructions at all. The agent searches them per question and pulls back only the passages that match. This is the key difference between Additional information and a Knowledge context, and it’s covered in detail below.

​
Does order matter?

This is the most common question, and the answer differs by field.

​
Inside the Policy box: no

You can’t promote a rule by putting it at the top of the Policy box. The Policy block is compiled in a fixed order:
1

Enabled policy options come first

Each toggle you switch on contributes one pre-written rule, in the fixed order the options appear in the AMS — not the order you enabled them.
2

Your Additional policy rules text comes last

Whatever you type into Additional policy rules is appended at the end, as a single bullet, regardless of what it says.
So the order you type things in has no effect on precedence. Within your own free text the wording stays as you wrote it, but the whole block sits at the end either way.
If a rule isn’t being followed, the fix is to make it clearer, narrower, or fewer — not to move it higher up the box.

​
Across fields: not in the way people expect

It’s a common assumption that Policy outranks Purpose, or that moving an instruction into Policy will force the agent to follow it. That isn’t how it works. Purpose, Policy and Additional information all end up in the same system prompt, and none of them carries a guaranteed priority over the others. What actually determines whether an instruction is followed is how clearly it’s written and whether anything else contradicts it. Moving a stubborn instruction between fields rarely fixes it. Removing the contradiction, or wording it more precisely, usually does.
The two biggest causes of an agent behaving badly are conflicting or ambiguous instructions, and the agent inventing an answer because it had no good information to work from. Both are content problems, not placement problems. If an agent is misbehaving and you can’t find a contradiction, raise it with support rather than reshuffling fields.

​
For tools: yes, explicitly

Tools are the one place with real, mechanical priority. The agent is told plainly that tools higher in the list take precedence over lower ones, and that it should call at most one tool per turn. That ordering comes from the tool configuration itself, not from anything you write in Policy.

​
Purpose

Purpose is where the real work goes. It’s a required field — an agent can’t be saved without one — and you’ll find it under Settings → General. Think of Purpose as the operating manual you’d hand a new analyst on their first day: what your job is, what systems you have access to, when to use each one, how to approach the work, and what a good piece of output looks like. For anything beyond a simple question-and-answer agent, that runs to several hundred words, and it should.

​
Scale the detail to the job

​
Tie Purpose to the actual tools

This is the single highest-value thing you can do for a tool-using agent. Don’t just connect the tools and hope — write out what each one is for and when the agent should reach for it. A well-built Purpose for a tool-using agent typically has these parts:
1

Role and mission

Who the agent is and what it’s for, stated with some edge. “Provide deep, opinionated analysis of sales calls — not summaries, but actionable intelligence” tells the agent far more than “help with sales calls”.
2

Capabilities, tool by tool

Group the tools and give each one a line: what it returns and when to start there. For example: “list_calls — find calls by date range. Always start here when the user asks about recent activity.”
3

How to do the work

The method. Which tools to combine, in what order, and what never to skip. “Always pull both the call record and the transcript. Never give a surface-level summary from metadata alone.”
4

The shape of a good answer

If the output has a standard structure, lay out the sections. This is what turns a vague assistant into something that produces consistent, usable work.
5

Important notes and gotchas

Real constraints the agent can’t infer: data that lags by 30 minutes, a date format that must be ISO 8601, an ID that has to be resolved before another tool will accept it, a rate limit that rewards batching.
The gotchas step is the one people skip and the one that pays off most. An agent can’t discover that calls take 30 minutes to appear, or that it must resolve a name to an ID first. Tell it, and a whole class of failure disappears.

​
What still doesn’t belong in Purpose

Detail is welcome; misplaced content isn’t. Keep these out:
  • Tone and voice → Personality
  • Answer formatting (bullets, length, markdown) → Output formatting
  • Guardrails, refusals and scope limits → Policy, usually as a toggle
  • Bodies of reference data (price lists, opening times, policy documents) → a Knowledge context
So this is too thin for an agent with tools:
Be a helpful assistant for our staff.
And this is the wrong kind of detail — four fields’ worth of content in one box:
Help employees with HR questions. Always be friendly and professional. Never give legal advice. Our office hours are 9am to 5:30pm Monday to Friday and we close on bank holidays. Use bullet points.
The tone belongs in Personality, the legal-advice restriction is a Policy toggle, the opening hours belong in a Knowledge context, and the formatting belongs in Output formatting. Strip those out and write what’s left properly: what the agent does, how it works, and how it uses what it’s connected to.

​
Policy

Policy is for hard rules — what the agent must not do, must refuse, or must escalate. It is not for background, reference material, or descriptions of the agent’s capabilities.

​
Start with the toggles, not the text box

Policy has a set of pre-written options as toggles. These are written and tested by us, and they cover the rules most agents need. Reach for a toggle before you write anything in the free-text box.
Focus and Scope is the highest-value toggle for most agents. It’s also the one whose extra field is mandatory — if you enable it without describing the scope, the form won’t save.
Always fill in the extra field for any toggle that has one. Non-Context Segment Message and Deflect Safeguarding and Sensitive Issues don’t force you to, but if you enable them and leave the field blank, the agent receives the unfilled placeholder text instead of your value. Check the compiled result under Preview before publishing.
Grounding answers in the agent’s knowledge is enforced by the platform for AMS agents rather than by prompt text, so Knowledge Limits and Apologies shapes the agent’s behaviour without adding a written rule to the policy block. You don’t need to restate “only answer from the knowledge base” in the free-text box.

​
Use the free-text box only for what the toggles don’t cover

Additional policy rules is for organisation-specific rules with no equivalent toggle. Good candidates:
  • Escalation routes: “If the user asks about an open grievance, tell them to contact their HR business partner directly and do not attempt to advise.”
  • Named refusals: “Never confirm or discuss an individual employee’s salary, even if the user claims it’s their own.”
  • Hard boundaries the toggles don’t express.
Write each rule as a single, testable instruction. If you can’t tell whether the agent followed it, it isn’t a rule — it’s a preference, and it probably belongs in Personality or Purpose.

​
How long should Policy be?

Length is the wrong question. A long policy isn’t penalised for being long, and a short one isn’t reliable for being short. What matters is whether the rules are unambiguous and whether any of them fight each other. So write as many rules as the agent genuinely needs — and then read them as a set, looking for the two failure modes: Ambiguity. “Be careful with sensitive topics” gives the agent nothing to act on. “If a user discloses a safeguarding concern, express empathy and direct them to safeguarding@example.com” does. If you can’t tell from the outside whether the agent followed a rule, it isn’t a rule yet. Contradiction. This is the real cost of an unmanaged policy. “Always offer more than one option” alongside “give the single best recommendation” will produce inconsistent behaviour forever, and no amount of rewording either rule in isolation will fix it. Conflicts also creep in between Policy and Purpose — a scope limit in one and a broader remit in the other.
Contradictions fail quietly. The agent doesn’t announce that two rules disagree — it follows one sometimes and the other sometimes, so the agent looks unreliable rather than misconfigured. Whenever you add a policy rule, re-read the whole set and Purpose alongside it.
As a working guide:
  • Prefer toggles to prose — they’re pre-written and don’t conflict with each other.
  • One rule per line, each one stated so you could test it.
  • Read the full set after every addition, looking for conflicts.
  • If a rule has never changed an answer in testing, delete it — it’s surface area for a future conflict.
  • If Policy is filling up with facts rather than rules, that content belongs in a Knowledge context.

​
Additional information vs a knowledge context

This is the decision that causes the most confusion. Additional information is sent to the agent on every single turn, as part of its standing instructions. A knowledge context is searched per question, and only the matching passages come back. That difference gives you a clean rule:
1

Is it small and needed on almost every turn?

Put it in Additional information. A support email address, the company’s trading name, the current product tier names.
2

Is it a body of reference material the agent looks things up in?

Put it in a Knowledge context — even if it feels short. Opening times across regions, a price list, an escalation matrix, a policy document, a product catalogue.

​
Why a big block of text doesn’t belong in Additional information

A knowledge context isn’t read whole. Files are split into passages of around 250 words and indexed by meaning. When someone asks a question, the agent searches that index and pulls back just the handful of passages that match, then answers from them — with citations back to the source. That’s the behaviour you want for reference material. The agent sees the opening times when someone asks about opening times, and doesn’t carry them around the rest of the time. Paste that same block into Additional information and you lose all of that. It can’t be cited, so users can’t check where an answer came from. It can’t be updated without editing the agent. And it’s carried on every turn whether or not it’s relevant.
The real danger is drift into contradiction. Reference data pasted into a field is a second copy, and second copies go stale. Once the opening times in Additional information disagree with the opening times in your context, the agent has two conflicting sources and will sometimes use each — which reads as an unreliable agent rather than a stale field. Keep one copy, in a context.
For how to organise contexts once you’ve decided that’s where content belongs, see Structuring your knowledge contexts and Choosing data for your agents.

​
”When to use it” instructions belong in Purpose

If you have a body of reference material and guidance on when to consult it, those are two different things and they go in two different places:
  • The material itself → a Knowledge context.
  • The instruction to go and check it → Purpose, as part of the method.
For example, put the full regional opening-times table in a context, and put this in Purpose:
When a user asks whether we’re open, always check the regional opening times before answering, and state which region your answer applies to. Never answer from memory — hours differ by region and change on public holidays.
That’s method, so it sits with the rest of the method in Purpose. It would only belong in Policy if it were a refusal or a hard boundary — for example, “never state opening hours for a region the user hasn’t specified.”

​
Tool calls: where they go and whether to name them

Connect tools under Tools or MCP Servers. Explain them in Purpose. Don’t put them in Policy. Connecting a tool does give the agent a basic description of it, generated from the tool’s own configuration. That’s enough for the agent to know the tool exists. It is usually not enough for the agent to use it well — to know which tool to start with, which two to combine, or which one is the primary source of truth when several could answer. That judgement is what you write in Purpose.

​
Yes, name the tools — by name

Name them explicitly, and say when each should be used. This is the difference between an agent that has tools and an agent that knows how to work:
list_calls — find calls by date range. Always start here when the user asks about recent activity, a specific person’s calls, or what’s been happening. get_call_transcript — full transcript with speaker names and timestamps. This is your primary analysis tool. Always pull the transcript when analysing a call.
Note what those lines do beyond naming: they establish a starting point and a primary tool. Neither can be inferred from a tool description in isolation, and both are exactly what an agent gets wrong when Purpose is thin. Where tools overlap, say which wins:
For anything about delivery dates, use the order-tracking tool rather than the knowledge base.

​
Why not Policy?

Policy is for guardrails — what the agent must not do, must refuse, or must escalate. Tool guidance is method, not restriction. Splitting method across Purpose and Policy gives you two places to maintain and, sooner or later, two instructions that disagree. That contradiction is the thing most likely to make the agent behave inconsistently. The exception is a genuine guardrail about a tool: “Never call the refund tool without explicit confirmation from the user.” That’s a rule, so it belongs in Policy.

​
Two behaviours worth knowing

  • One tool per turn. The agent is instructed to call at most one tool in a single turn. If a task genuinely needs several calls in sequence, guide it through them in Purpose, or build it as a Plan. See Using tools in Plans.
  • Higher in the list wins. Tools earlier in the list are prioritised over later ones. That ordering comes from the tool configuration, not from anything you write in Policy.
For connecting tools and MCP servers, see Setting up MCP servers in the AMS and Tools.

​
Personality and output formatting

Two fields that often collect content belonging elsewhere. Personality is tone and voice only — warm, concise, formal. There are four pre-written personalities that cover most needs; use a custom one only when they genuinely don’t fit. Rules about what the agent may or may not do are Policy, not Personality, even when they’re phrased politely. Output formatting is the shape of the answer — bullets or prose, length, whether to include links. Keep it to shape. “Always cite the policy document” is a rule; “use bullet points for multi-step answers” is formatting. See Personality for both fields.

​
A worked example

A billing support agent with an order-lookup MCP server connected. Note the balance: Purpose carries most of the words, Policy carries the guardrails, and the reference data sits in contexts. Purpose — the long field, structured:
You are a billing support specialist for a software company, with access to our order system via MCP tools. Your job is to resolve billing and subscription issues completely, not to hand the customer a link and hope. Your tools
  • lookup_account — resolve a customer’s email to their account and current plan. Start here for any question about a specific customer’s billing.
  • list_invoices — invoices for an account by date range. Use after lookup_account, since it needs the account ID.
  • get_invoice — full line-item detail for one invoice. Pull this before explaining any charge; never explain a charge from the summary alone.
How to handle a billing query
  1. Resolve the account first. Never guess which account the customer means — if the email doesn’t match one, ask.
  2. Pull the specific invoice before discussing a charge, and quote the line items you’re referring to.
  3. If the amount still looks wrong after you’ve read the line items, hand over to a human rather than speculating.
Important notes
  • Invoices appear in the system up to an hour after payment, so a very recent charge may not be visible yet. Say so rather than telling the customer it doesn’t exist.
  • Plan names changed in 2025. If an invoice shows a legacy plan name, check the tier comparison before explaining what the customer is on.
Everything else, kept lean: Two things to notice. The tools are named and sequenced in Purpose, including the constraint that one tool needs an ID from another — the agent can’t work that out alone. And Policy holds only the two things that are genuinely refusals; it doesn’t restate any of the method.

​
Before you go live

  • Purpose explains the job, the method, and every tool the agent has — not just a one-line mission.
  • Tool guidance names the tools, says where to start, and flags any tool that depends on another.
  • Real-world gotchas are written down: data lag, formats, IDs, legacy naming.
  • Every rule that could be a toggle is a toggle.
  • Toggles with an extra field have that field filled in.
  • Policy holds guardrails only, and no rule contradicts another or contradicts Purpose.
  • Additional information holds only small, always-relevant facts.
  • Every body of reference material is in a Knowledge context, not pasted into a field.
  • You’ve tested with real user questions, not just questions you invented.
The highest-value test is a contradiction hunt. Read Purpose and Policy end to end as one document, as the agent receives them, and look for any two lines that could pull in different directions. That’s where inconsistent behaviour comes from.
For the full walkthrough of creating an agent, see Creating Agents and the AMS Quick Start Walkthrough.