Constrain agent behavior beyond its persona

Learning objective

Define agent personas, responsibilities, scopes, behavioral contracts, and autonomy levels.

Core idea

When you specify an agent, a persona describes how it presents its expertise. A responsibility describes what result it owns. Scope describes which tasks, data, and actions it may handle. A behavioral contract describes how it must act and return results. An autonomy level describes which decisions it can make without approval.

These dimensions must agree, but they are not substitutes for one another. “You are a careful financial analyst” says little about whether the agent can retrieve invoices, recommend adjustments, or execute payments. Specify those boundaries independently so the application can enforce them.

Microsoft Agent Framework exposes agent name, description, instructions, and tools in its Python examples. Use these mechanisms deliberately: identify the participant, describe its capability for selection, express its behavioral rules, and provide its callable operations. None of these fields alone establishes business authorization.

How it works

Give the persona an operational purpose

Choose a persona that supports the task: a billing analyst explains discrepancies using records; a customer-support writer explains the accepted decision in plain language. Include audience and communication expectations where they affect the deliverable, rather than filling the prompt with personality traits.

Use name for a stable participant label and description for a concise capability summary. Agent Framework’s Magentic examples give specialists distinct descriptions and instructions, such as research versus code-based data analysis. That separation helps coordination identify an appropriate participant.

A persona is not a professional credential or a guarantee of correctness. Do not treat “expert” in a prompt as evidence that its conclusions satisfy policy. The application still checks inputs, supporting records, and accepted outputs. Expertise language can guide behavior, but it cannot grant a permission or certify a result.

Define responsibility and scope explicitly

A responsibility needs an observable deliverable. “Analyze pricing” is weaker than “return the applicable contract clause, the supported interpretation, and unresolved conflicts.” State who consumes the result and whether the agent owns a finding, a proposal, or the final business response.

Scope limits the work that can contribute to that deliverable. Define permitted document types, case identifiers, tools, and action categories. Also define out-of-scope outcomes. If an agent receives a request to approve a payment but owns only evidence gathering, it returns an escalation outcome instead of interpreting the request as expanded authority.

The agent’s tools provide a concrete callable surface. A research agent with read tools has a different operating scope from one with write tools. Restrict supplied tools to its responsibility, and enforce access and argument rules inside the tool implementation. Prompt wording is not a substitute for those checks.

Responsibility does not automatically transfer when another agent contributes. If this agent is a subagent, its parent owns integration and final acceptance; see 1.1.3. If the conversation is handed off, make the ownership change explicit rather than leaving two agents with incompatible final-response duties.

Turn instructions into a behavioral contract

Use instructions to state evidence requirements, result shape, uncertainty handling, tool-use expectations, and escalation behavior. Define what happens when required information is missing or contradictory. A requirement to answer every request can conflict with a requirement to use verified evidence; resolve that conflict in the contract.

For a contract-analysis agent, require references to supplied records, distinction between findings and assumptions, and an explicit unresolved outcome when the material does not support a conclusion. These are application-defined obligations. Validate the returned evidence identifiers and required fields outside the model.

Keep instructions consistent with actual capabilities. An instruction to issue a refund is invalid for an agent with no refund tool. An instruction to never issue refunds is a fragile boundary if you nevertheless expose an unrestricted refund operation. Align instructions, tool availability, and workflow routing.

Assign autonomy by action category

Define a business autonomy scheme that separates recommendation, bounded investigation, and execution after approval. State which actions fall into each category. Separately configure the framework’s continuation behavior: freedom to keep working does not grant authority to perform every operation.

An agent may autonomously choose among read tools for an investigation while needing approval for a financial write. That is more precise than calling the whole agent “fully autonomous” or “human supervised.” The relevant boundary is the decision or operation, not a slogan attached to the participant.

Handoff orchestration is interactive by default: an agent that responds without handing off returns control to the user. Python’s experimental with_autonomous_mode(agents=[...], turn_limits={name: n}) lets selected participants continue without user input, with per-agent turn limits. The .NET form is WithAutonomousMode(agents: [...], turnLimit: n); its documented default is 50 autonomous turns per agent. Participants outside the selected set return control after a response. Scope this continuation dial to handoff orchestration, rather than assuming it is a universal autonomy setting for all agents.

For a bounded investigation, select the read-only participant and set an explicit turn budget, such as the documented Python example’s three turns. That limit bounds continuation without changing its tool permissions or removing business approval requirements. See 1.1.5 for termination predicates and loop outcomes.

Use @tool(approval_mode="always_require") as the per-operation approval gate for a local Python function; see 1.1.6 for the .NET wrapper, provider scope, and approval handling.

Key distinctions and trade-offs

Persona versus responsibility: Persona influences presentation and task framing. Responsibility assigns a deliverable and an owner. A convincing persona can still return an unusable result.

Instruction versus enforcement: Instructions express intended behavior. Restricted tools, application validation, and approval gates enforce consequential boundaries. Use instructions to explain the boundary, then implement it where the action happens.

Scope versus autonomy: Scope defines the allowed domain. Autonomy defines discretion within that domain. An agent can operate in a narrow domain yet require approval for every write.

Detailed contract versus adaptability: Clear obligations reduce ambiguity and simplify evaluation. Excessively prescriptive reasoning steps can obstruct useful investigation. Specify accepted results and forbidden behavior while leaving safe investigative choices available.

Architecture / decision scenario

A purchasing system contains a contract analyst and a procurement coordinator. The analyst’s persona is a precise reviewer for purchasing staff. Its responsibility is a supported interpretation of supplied clauses; its scope is the identified contract and read-only evidence tools.

Its description advertises contract interpretation, and its instructions require clause identifiers, unresolved-conflict reporting, and a finding rather than a purchase decision. It can choose which supplied clauses to inspect without asking permission each time. An application validator checks that returned identifiers exist in the allowed evidence set.

The coordinator owns the purchasing proposal. Its contract requires it to integrate the analyst’s finding with deterministic budget rules. It can draft a recommendation but cannot treat an analyst’s confident answer as authorization to place an order. The purchase function is separately exposed with approval_mode="always_require".

If the analyst is asked to place the order, it returns an out-of-scope result. If the coordinator changes the order after approval, the application treats the changed action as a separate authorization decision. The design defines personas, deliverables, scopes, behavior, and autonomy for both participants without making either prompt the security boundary.

Common exam traps

• Treating a persona as a permission model or a correctness guarantee.
• Using description and instructions interchangeably without a selection contract.
• Giving mutation tools to a read-only specialist and relying on prompt restraint.
• Describing autonomy only at the agent level instead of per operation.
• Assuming local function-tool approval governs all service-side hosted tools.

What to remember

Specify persona, responsibility, scope, behavior, and autonomy as separate dimensions. Use name, description, instructions, and tools to express the agent contract, then enforce consequential actions with application checks and scoped approval mechanisms.

Knowledge check

References

• Microsoft, Workflows orchestrations — Magentic
• Microsoft, Using function tools with human in the loop approvals
• Microsoft, Tools overview
• Microsoft, Workflows orchestrations — Handoff