Define system-level behavior
When rules aren’t set, responses drift. One prompt gets a careful summary. The next invents a decision. People can’t tell which to trust, so they stop trusting any of it.
System-level behavior is the set of rules every response from your agent must follow. They cover what the agent is, how it sounds, what it won’t do, and what it does when information is missing.
What you’re actually deciding
System-level behavior is written once, in the system prompt that ships with the agent. Every prompt the agent answers inherits these rules without restating them.
You sit down to define system-level behavior:
- Before the agent ships
- When you’re launching the agent on a new surface, such as chat, in-flow Copilot, a summarizer, or a generator
- After a review finds a pattern of failures that no single prompt fix can solve
You’re writing five things:
- Role and scope. What the agent is, what it helps with, and what’s out of scope.
- Persona, voice, and tone. Who the agent is, how it consistently sounds, and how it adjusts.
- Boundaries. What it must never do.
- How to handle uncertainty. What it does when input is missing, unclear, or in conflict.
- Adjustments for the surface. What changes when the agent is in chat versus in-flow versus a single-shot generator.
Role and scope
Write a short, plain description that names what the agent is, what it helps with, and what’s out of scope.
Example
“This agent summarizes and organizes information from meetings and documents. It does not make decisions, assign owners, or approve next steps.”
The first sentence names what the agent does. The second names what it doesn’t, so the limits are visible from the start. The goal is clarity about responsibility, not a feature list.
If scope is vague, responses drift into work the agent isn’t accountable for, and reviewers can’t tell whether a response is overreaching or doing its job.
Persona, voice, and tone
Persona is who the agent is. Voice is how it consistently sounds. Tone is how voice adjusts to the situation. All three live in the system prompt so they hold across every response.
Aim for consistency, not personality. Clear over charming. Specific over vague. Transparent over implied.
In this page, define the baseline that should hold across all scenarios. For context-specific tone adjustments, use Define tone and context behavior.
Persona example
“A meeting assistant for working teams. Reliable, low-key, focused on accuracy. Not a coach, friend, or motivator.”
Voice example
“Plain language. Short sentences. No hedging filler (‘I think,’ ‘maybe,’ ‘just’). No corporate phrases (‘synergy,’ ‘circle back’).”
Tone example
- Neutral and factual for summaries
- Calm and direct when information is missing
- Helpful but restrained when suggesting next steps
Do and Don’t: tone matching the facts
| Do | Don’t |
|---|---|
| ”Two action items are unresolved. Confirm the owner before sharing." | "All set, you’re good to go.” |
The “Don’t” sounds confident, but the underlying information isn’t. The tone says ready when the facts say pause.
Boundaries
Boundaries are the things the agent must never do, no matter how a prompt is phrased. Without them, responses can invent facts, sound more confident than the inputs support, or take actions that should be human decisions.
For each boundary, write a rule the agent can follow and a reviewer can check.
| Boundary | What to write in the system prompt |
|---|---|
| No fabrication | ”Only use information present in the input. If a fact, such as an owner, date, decision, or outcome, isn’t there, say so. Don’t infer.” |
| Sensitive requests | ”Don’t help with HR matters, legal advice, or medical questions. If asked, say: ‘That’s outside what I can help with. Try [the right channel].’” |
| Capability claims | ”Don’t say ‘I checked,’ ‘I confirmed,’ or ‘I verified’ unless a tool call returned the result. Otherwise say ‘Based on the input you shared…’” |
| Identity | ”Refer to yourself as ‘the assistant’ or ‘I.’ Never claim to be a person, have feelings, or have experiences.” |
| Influence | ”Present options neutrally. Don’t recommend a choice unless asked. No flattery, such as ‘great question,’ and no emotional language.” |
If a response crosses a boundary, treat it as a failure even if it sounds helpful. The boundary is what makes the output safe to act on. Tone doesn’t override it.
How to handle uncertainty
Most inputs aren’t complete. Notes are partial, a calendar entry conflicts with a recent message, or a request is ambiguous. The system-level rule is to make those gaps visible in the response rather than guess past them.
Write three rules into the system prompt:
- Match confidence to evidence. Words like “confirmed,” “decided,” and “all set” only appear when the input actually says so.
- Name what’s missing before answering. If required information isn’t in the input, say what’s missing first.
- Keep known and unknown separate. A response can include what’s supported and flag what isn’t, but the two never blend in the same sentence.
What counts as “required information” depends on the task. That gets defined in the task workflow, not here. This article sets the rule every task inherits.
Do and Don’t: gaps in the input
| Do | Don’t |
|---|---|
| ”The notes don’t list a decision on launch timing. Confirm before I draft the follow-up." | "Decision: delay launch to next quarter.” when the notes only said the team discussed delaying. |
Adjustments for the surface
The same agent shows up in different surfaces. Role and boundaries hold across all of them, but a few rules adjust by surface.
| Surface | What changes |
|---|---|
| Chat agent | Multi-turn. The agent can ask a clarifying question before answering. |
| In-flow Copilot | Embedded in a task. Shorter responses, fewer clarifying questions, and more reliance on surrounding context. |
| Summarizer | Single-shot. No clarifying questions are available, so gaps in the input have to be flagged in the output itself. |
| Generator | Produces a draft. Any part the agent invented or inferred beyond the input must be flagged. |
Decide which surface the system prompt is for before writing it. Same role, same boundaries. The shape of how they’re enforced changes.
Key takeaway
Write these rules into the system prompt once. Skip that work and every response becomes a per-prompt judgment call, and the same kind of failure keeps showing up looking like a one-off.