PulseFlow Tecnologia
← Insights
·7 min read·technical-guide·system-prompt·copilot-studio·agent-security
PulseFlow Tecnologia

How to design an enterprise system prompt for AI agents

Microsoft documented, in detail, how agents using "generative orchestration" in Copilot Studio actually use the instructions they're given: to decide which tool or knowledge source to call, to fill that tool's parameters, and to generate the final response. That gives a concrete - not theoretical - basis for how to structure an enterprise system prompt.

Instructions don't replace configuration

The first point in Microsoft's documentation is also the easiest to forget: "agents can't act on instructions to use tools or knowledge sources if the agent doesn't have those tools or knowledge sources configured." A system prompt doesn't create capability - it only directs a capability that already exists. That changes the starting point: before writing the instruction, make sure tools and knowledge sources are correctly named and described, because it's each one's name and description - not the prompt text - that the agent uses to decide what to call.

Three control layers, not one

The most applicable part of the documentation is the three-layer decision structure Microsoft recommends for any production agent:

  1. Deterministic layer - irreversible or critical actions (payment, record deletion) run on fixed logic, with no AI interpretation
  2. Hybrid (intercept) layer - the agent acts, but with checkpoints for human approval (e.g., approve alone up to a certain value; escalate above it)
  3. AI orchestrator layer - fully generative, for low-risk queries (questions, information lookups), within policies the agent can't violate

Microsoft's practical rule: "if something must happen exactly as specified, handle it deterministically" - never let AI decide alone what's irreversible.

What to put in the instruction (and what not to)

The documentation lists specific vocabulary for instructions - verbs like Get and Use for data retrieval, From and With for acting on results - and recommends numbering or listing instructions when order matters. But the most counterintuitive point is: you don't need to list every available tool in the instruction - the agent already sees them through their configured name and description. The instruction should focus on disambiguating cases where the right choice isn't obvious, for example: "Use the FAQ documents only if the question is not relevant to Hours, Appointments, or Billing."

Jailbreak protection via triggers

One point any enterprise system prompt guide should cover, and often doesn't: automatic triggers (which fire the agent without a user message) are vulnerable to attacks where someone injects instructions into the trigger payload itself - for example, asking the agent to email sensitive information to the attacker. The recommended defense is explicit: limit which tools the agent can use when fired from a trigger, and limit which parameters it can fill (for example, restricting email recipients to a predefined list).

Testing isn't optional

Microsoft recommends a specific test cycle: use the "activity map" (a real-time view of the plan the agent decided to execute) to inspect which tool was called, in what order, and whether the follow-up question made sense; review real production conversation transcripts; and change one thing at a time, observing the effect before the next change.

A reference structure

Combining Microsoft's documentation with market practice, an enterprise system prompt covers, in practice:

  1. Agent role
  2. Agent goal
  3. Scope of action (what to answer, what to decline)
  4. Knowledge sources (described generically, not cited literally)
  5. Allowed tools (named exactly - names carry more weight than descriptions)
  6. Tools forbidden or restricted by context/trigger
  7. Security rules (scope limits on automatic triggers, against jailbreak)
  8. Response format criteria (table, list, tone)
  9. Human escalation criteria (hybrid layer: when to approve before acting)
  10. Logs and traceability (activity map, transcripts, fallback metrics)

Sources