Designing a Microsoft Copilot Studio Agent from a Natural-Language Specification

Introduction

One of the most interesting ways to start building an Agent in Microsoft Copilot Studio is to avoid configuring every component manually from the beginning.

Instead of immediately editing Name, Description, Instructions, Knowledge, Topics, and Tools individually, Copilot Studio provides a natural-language creation experience where the maker can start with:

Start building by describing what your agent needs to do

At first glance, this looks like a simple prompt box.

Architecturally, however, it represents something much more interesting.

The maker can describe the desired Agent in natural language: its purpose, domain, audience, expected behavior, limitations, preferred information sources, and even capabilities that should or should not exist initially.

Copilot Studio then interprets this description and uses it to generate an initial Agent configuration.

This introduces a different authoring philosophy:

Describe the desired Agent first. Inspect and refine the generated configuration afterward.

Rather than treating the creation experience merely as a shortcut, we can think of it as a lightweight form of declarative Agent authoring.

1. The Basic Idea

A traditional approach to creating an Agent might look like this:

Create Agent
    ↓
Configure Name
    ↓
Configure Description
    ↓
Write Instructions
    ↓
Configure Knowledge
    ↓
Configure Topics
    ↓
Configure Tools
    ↓
Test

The natural-language creation approach begins differently:

Describe the Agent
        ↓
Copilot Studio interprets the specification
        ↓
Initial Agent configuration is generated
        ↓
Maker inspects the result
        ↓
Maker refines individual components
        ↓
Test

The important difference is that the first input is not a collection of individual configuration values.

It is a semantic description of the desired system.

2. The Creation Prompt Is Not the Same as Agent Instructions

This distinction is fundamental.

The text entered into:

Start building by describing what your agent needs to do

should not automatically be considered equivalent to the final Instructions of the Agent.

There are effectively two layers.

Maker
  |
  | Natural-language creation specification
  v
Copilot Studio Builder
  |
  | Generates and proposes configuration
  v
Agent
  |
  | Runtime Instructions
  v
User

The first text is primarily a request to the builder.

The final Instructions field controls the behavior of the Agent at runtime.

For example, the creation specification could contain:

Create an Agent named WristWatchBuildingCompanion.
The Agent should be an educational companion specialized in
wristwatches and horology.
It should focus primarily on the 20th and 21st centuries.
Prefer official manufacturer information when web access is available.
Do not create Tools or Actions yet.
Knowledge Sources will be configured separately.

Copilot Studio can interpret this description and generate an initial configuration.

After creation, however, we should inspect the actual:

• Name
• Description
• Instructions
• Knowledge
• Web Search
• Topics
• Tools

The generated configuration becomes the real object that we need to understand, test, and govern.

3. Thinking of the Prompt as an Agent Requirements Document

A useful mental model is to treat the initial prompt as a small Agent Requirements Document.

Instead of simply saying:

Create a watch Agent.

we can describe several dimensions of the desired Agent.

For example:

Identity
Purpose
Domain
Audience
Behavior
Important subjects
Preferred sources
Limitations
Uncertainty handling
Initial architecture
Future architecture

A more structured specification could therefore look conceptually like this:

IDENTITY
Create an Agent named WristWatchBuildingCompanion.
PURPOSE
Create an educational Agent for learning about wristwatches and horology.
DOMAIN
Focus primarily on wristwatch history, movements, manufacturers,
technologies, models, design, and watch culture from the 20th and
21st centuries.
BEHAVIOR
Teach progressively.
Explain technical terminology.
Provide historical context.
Distinguish verified information from uncertainty.
SOURCES
Prefer official manufacturer information when web access is available.
LIMITATIONS
Do not invent calibers, references, specifications, or historical facts.
INITIAL ARCHITECTURE
Do not create custom Tools or Actions yet.
FUTURE ARCHITECTURE
Knowledge Sources and structured Topics will be configured later.

This is substantially more expressive than filling in a single Description field.

4. Declarative Agent Authoring

This approach can be viewed as a form of declarative authoring.

Traditional UI configuration is relatively imperative:

Open this screen.
Click this button.
Set this property.
Add this source.
Configure this option.

Natural-language creation instead says:

This is the Agent I want.

The builder then attempts to translate that desired state into actual Copilot Studio configuration.

Conceptually:

Desired Agent
     ↓
Natural-language specification
     ↓
Builder interpretation
     ↓
Copilot Studio configuration

This resembles patterns developers already encounter elsewhere.

For example, Infrastructure as Code frequently focuses on declaring the desired state rather than manually executing every operation required to reach that state.

Copilot Studio natural-language authoring is obviously not Infrastructure as Code, but the conceptual similarity is useful:

Describe the desired state first; inspect the implementation afterward.

5. The Builder Is an Interpreter, Not a Compiler

This distinction is extremely important.

A compiler receives input expressed according to a formal grammar and produces relatively deterministic output.

Natural language does not work that way.

The Copilot Studio builder must interpret what the maker means.

Therefore:

Natural-language specification
             ↓
       AI interpretation
             ↓
     Proposed configuration

This means we should never assume:

I wrote X
therefore
Copilot Studio configured exactly X

Instead, we should think:

I expressed intention X
        ↓
The builder interpreted X
        ↓
Now I inspect what it actually produced

This leads to a much safer engineering workflow.

Specify
   ↓
Generate
   ↓
Inspect
   ↓
Correct
   ↓
Test
   ↓
Refine

Not:

Specify
   ↓
Generate
   ↓
Publish

6. A Practical Example: WristWatchBuildingCompanion

Our laboratory provides a useful real-world example.

We asked the builder to create:

WristWatchBuildingCompanion

The Agent should specialize in:

• wristwatch history
• horology
• mechanical movements
• automatic movements
• quartz technology
• digital watches
• solar watches
• radio-controlled watches
• GPS watches
• manufacturers
• important models
• industrial design
• watch culture
• collecting
• 20th-century history
• 21st-century developments

We also mentioned important manufacturers such as:

• Seiko
• Casio
• Citizen
• Rolex

Most importantly, we included official URLs.

Seiko
https://www.seikowatches.com/
Casio
https://www.casio.com/
Citizen
https://www.citizenwatch-global.com/
Rolex
https://www.rolex.com/

This produced an especially interesting result.

7. URLs Inside the Creation Specification

We deliberately placed manufacturer URLs inside the natural-language specification.

This was partly an experiment.

Conceptually, writing:

Prefer information from:
https://www.seikowatches.com/

does not inherently mean:

Configure this URL as a Knowledge Source.

These are different concepts.

The text is an instruction or preference expressed to the builder.

A configured Knowledge Source is an actual Copilot Studio resource.

This distinction matters enormously.

8. What Copilot Studio Actually Did

After the Agent was created, the Copilot Studio interface displayed the four URLs under Knowledge.

However, they were displayed as:

Suggestion

Each URL had:

• Add
• Dismiss

For example:

Suggestion
https://www.seikowatches.com/
[ Add ] [ Dismiss ]

The same occurred for Casio, Citizen, and Rolex.

This is an excellent practical demonstration of how the builder interprets natural language.

Our creation specification contained URLs.

The builder recognized that those URLs were potentially useful as Knowledge.

But instead of silently converting them into configured Knowledge Sources, the interface proposed them to the maker.

Conceptually:

Creation Prompt
      |
      | contains URL
      v
Builder recognizes possible information source
      |
      v
Knowledge Suggestion
      |
      +---- Add
      |
      +---- Dismiss

This preserves an important human decision point.

9. Suggestion Is Not Configuration

This leads to a useful rule:

A Knowledge suggestion is not necessarily an active Knowledge Source.

The UI itself makes this visible.

If the URL is displayed as a Suggestion with an Add option, the maker still has a decision to make.

This distinction becomes particularly important in enterprise environments.

Imagine that the creation prompt contains:

Use our Human Resources portal:
https://contoso.sharepoint.com/sites/hr

We should not assume that mentioning this location automatically means that it has been connected, indexed, authorized, secured, or made available to every Agent user.

Configuration and security must still be examined separately.

10. Instructions and Knowledge Are Different Layers

Our experiment also reinforces one of the most important concepts in Copilot Studio.

Instructions

Instructions define behavior.

Examples:

Explain concepts progressively.
Prefer authoritative sources.
Do not invent technical specifications.
Clearly indicate uncertainty.

Knowledge

Knowledge provides information that the Agent may retrieve.

Examples could include:

SharePoint sites
Documents
Public websites
Dataverse
Other supported Knowledge Sources

Therefore:

Instructions
    |
    | define behavior
    v
Agent

while:

Knowledge
    |
    | provides information
    v
Retrieval

They interact, but they are not interchangeable.

11. Knowledge → Retrieval → Grounding → Answer

This leads directly to the information pipeline we are using throughout the laboratory.

Knowledge
    ↓
Retrieval
    ↓
Grounding
    ↓
Answer

Knowledge

The information sources available to the Agent.

Retrieval

The process of finding information relevant to the user’s current request.

Grounding

The process of using retrieved information as evidence or context for generation.

Answer

The final natural-language response produced for the user.

A simplified conceptual model is:

User Prompt
     |
     v
Orchestration
     |
     v
Retrieval
     |
     +----------> Knowledge Sources
     |                 |
     <-----------------+
     |
     v
Relevant Context
     |
     v
Grounding
     |
     v
Language Model
     |
     v
Answer

This is very different from simply putting a URL inside Instructions.

12. The Interesting Role of Web Search

Our generated Agent also showed:

Web Search → Enabled

This creates another important distinction.

We now potentially have three separate concepts:

Instructions
Knowledge Sources
Web Search

They should not be collapsed into one idea.

Conceptually:

Instructions
    ↓
How should the Agent behave?
Knowledge
    ↓
What configured information can the Agent retrieve?
Web Search
    ↓
Can the Agent search public web information?

The fact that an official manufacturer URL appears in Instructions does not by itself make it Knowledge.

The fact that Web Search is enabled does not mean every website has become a configured Knowledge Source either.

These are separate capabilities.

13. Natural Language as an Architectural Interface

This is where the concept becomes more interesting.

Historically, software configuration interfaces have been designed around forms.

The user needs to understand the product’s data model first:

Property A
Property B
Configuration C
Option D

Generative authoring reverses part of this relationship.

Instead of requiring the maker to completely understand the internal configuration model before expressing intent, the maker can first describe the desired system.

Human intent
     ↓
Natural language
     ↓
AI interpretation
     ↓
Platform configuration

Natural language therefore becomes an architectural interface.

The maker is not merely chatting.

The maker is expressing system requirements.

14. Prompt Engineering Becomes Requirements Engineering

This also changes how we should think about prompt engineering.

A weak creation prompt might say:

Create a watch expert.

The builder has enormous freedom to interpret this.

A better specification might say:

Create an educational Agent specialized in wristwatches and horology,
primarily covering the 20th and 21st centuries.
Teach progressively.
Cover history, movements, manufacturers, technologies, models,
design, and watch culture.
Prefer authoritative primary sources.
Clearly indicate uncertainty.
Do not create Tools or Actions yet.

This is not merely better “prompt wording.”

It is better requirements engineering.

The quality of the initial generated system increasingly depends on the quality of the maker’s description of the desired system.

15. A Useful Creation-Prompt Structure

For future Agents, we can develop a reusable template.

AGENT IDENTITY
What is the Agent called?
PURPOSE
Why does the Agent exist?
AUDIENCE
Who will use it?
DOMAIN
What subjects does it cover?
BEHAVIOR
How should it reason and communicate?
AUTHORITATIVE SOURCES
Which sources should be preferred?
KNOWLEDGE EXPECTATIONS
What information should eventually become Knowledge?
UNCERTAINTY
What should happen when information cannot be verified?
BOUNDARIES
What should the Agent not do?
INITIAL CAPABILITIES
What should exist in version 1?
EXCLUDED CAPABILITIES
What should not exist yet?
FUTURE CAPABILITIES
What will be added later?

This could become a reusable artifact in an enterprise Agent engineering methodology.

16. The Creation Prompt as a Bootstrap Mechanism

Another useful way to describe this approach is Agent bootstrapping.

The initial prompt is not necessarily intended to be the permanent runtime configuration.

Its job is to bootstrap the project.

Specification
     ↓
Bootstrap
     ↓
Initial Agent
     ↓
Engineering
     ↓
Production Agent

That distinction becomes increasingly valuable as Agents grow.

The builder can accelerate the first 20% of configuration.

The maker still owns the remaining engineering work.

17. Why the Generated Result Must Be Inspected

After creation, every generated component should be treated as something to inspect.

For example:

This is similar to reviewing generated source code.

AI-generated configuration should be reviewed, not merely accepted.

18. The Agent Builder as a Junior Solution Architect

A useful analogy is to imagine the builder as a junior solution architect.

You provide requirements:

Build an educational horology Agent.
Focus on these domains.
Prefer these sources.
Do not add operational capabilities yet.

The architect produces a first design.

You then review it.

You might say:

This Description is good.
These Instructions need refinement.
This Knowledge suggestion makes sense.
This Tool should not exist.
This source requires a security review.

The AI accelerates configuration.

The human retains architectural responsibility.

That distinction becomes especially important in corporate environments.

19. Where This Approach Becomes Powerful

The method becomes particularly interesting when organizations create many specialized Agents.

Imagine an organization creating Agents for:

HR policies
IT support
SharePoint governance
Engineering documentation
Legal procedures
Employee onboarding
Training
Procurement
Project management
Compliance

Instead of manually creating every Agent from scratch, an organization could develop standardized Agent Specification Templates.

For example:

Corporate Agent Specification v1
Purpose:
Audience:
Business owner:
Domain:
Allowed Knowledge:
Preferred sources:
Forbidden sources:
Expected behavior:
Escalation behavior:
Security constraints:
Actions allowed:
Actions prohibited:
Data classification:
Publishing scope:

A natural-language builder could then accelerate creation from these specifications.

This begins to look less like casual chatbot creation and more like Agent engineering.

20. From Prompt Library to Agent Blueprint Library

This suggests another evolution.

Organizations may eventually maintain libraries not merely of prompts, but of Agent Blueprints.

For example:

/agent-blueprints
    knowledge-agent.md
    sharepoint-policy-agent.md
    training-agent.md
    service-request-agent.md
    approval-agent.md
    research-agent.md

Each blueprint could define:

Purpose
Instructions
Knowledge strategy
Security expectations
Tools strategy
Testing strategy
Publishing rules
Governance requirements

A maker could use one of these blueprints as the starting specification in Copilot Studio.

The generated Agent would then be reviewed and adapted.

21. Could Agent Specifications Eventually Become Versioned Assets?

This is where we can speculate a little.

If natural-language specifications become important architectural artifacts, they may deserve the same treatment as other engineering assets.

For example:

Git repository
    |
    +-- agents
         |
         +-- WristWatchBuildingCompanion
              |
              +-- specification.md
              +-- instructions.md
              +-- knowledge.md
              +-- security.md
              +-- tests.md

Changes could then be reviewed:

Agent specification v1
        ↓
Pull Request
        ↓
Architectural Review
        ↓
Agent configuration
        ↓
Testing

Even when the platform itself is primarily low-code, the design artifacts surrounding the Agent can still follow software engineering practices.

This becomes especially relevant for governance and ALM.

22. Natural Language Does Not Eliminate Architecture

Perhaps the biggest misconception about AI-assisted development is that natural language removes the need for architecture.

The opposite may happen.

When configuration becomes easier to generate, organizations can create more systems more quickly.

That increases the importance of:

Architecture
Security
Governance
Testing
Documentation
Ownership
Lifecycle management
Cost management

Creating an Agent may become easy.

Creating a good enterprise Agent remains an engineering problem.

23. Natural Language Does Not Eliminate Security

Suppose a maker writes:

Use our SharePoint HR site as Knowledge.

That sentence says nothing about:

Who authenticates?
Which identity accesses SharePoint?
Does the user's permission apply?
Can the Agent expose restricted information?
What happens when the user lacks access?
What connector is involved?
What environment contains the Agent?
What DLP policies apply?

Natural-language creation can express intent.

It does not eliminate authorization.

Therefore:

Natural-language specification
            ≠
Security architecture

The same applies to Tools.

Writing:

Allow the Agent to create SharePoint items.

does not answer:

Using whose credentials?
In which site?
In which list?
With which permissions?
Under which user context?
With what validation?
With what audit trail?

These remain architectural responsibilities.

24. Natural Language Does Not Eliminate Testing

An Agent that looks correctly configured can still behave incorrectly.

Therefore the lifecycle remains:

Specify
    ↓
Generate
    ↓
Inspect
    ↓
Test
    ↓
Evaluate
    ↓
Refine
    ↓
Publish
    ↓
Monitor

This is one reason Copilot Studio exposes areas such as:

Activity

Evaluation

Monitor

Channels

Agent creation is only the beginning of the lifecycle.

25. A Useful Mental Model

The entire method can be summarized as five layers.

LAYER 1
BUSINESS INTENT
"What problem should this Agent solve?"
        ↓
LAYER 2
NATURAL-LANGUAGE SPECIFICATION
"Describe the desired Agent."
        ↓
LAYER 3
BUILDER INTERPRETATION
Copilot Studio interprets the specification.
        ↓
LAYER 4
AGENT CONFIGURATION
Instructions
Knowledge
Topics
Tools
Model
Settings
        ↓
LAYER 5
RUNTIME
User
  ↓
Agent
  ↓
Knowledge / Retrieval / Grounding
or
Topics / Tools / Actions
  ↓
Answer / Operation

The initial prompt lives primarily between Layer 1 and Layer 3.

It is not the complete runtime architecture.

26. Our WristWatchBuildingCompanion Experiment

Our experiment demonstrated this process concretely.

We described:

WristWatchBuildingCompanion

and included:

Purpose
Domain
Manufacturers
Historical behavior
Technical behavior
Uncertainty rules
Preferred websites
Architecture restrictions
Future Topics

The builder created an Agent.

We then observed:

Name
Description
Instructions
Model
Knowledge suggestions
Web Search
Tools

Most interestingly:

URLs in creation specification
             ↓
Builder interpretation
             ↓
Knowledge Suggestions
             ↓
Maker still decides Add or Dismiss

This is precisely why inspecting generated configuration is valuable.

We learned something about Copilot Studio not by merely reading a definition, but by observing how the builder transformed our specification.

27. Creation Prompt vs Instructions vs Knowledge

A compact comparison is useful.

This distinction prevents many architectural misunderstandings.

28. Recommended Engineering Mindset

The natural-language creation experience should therefore not be approached as:

“Copilot, build everything for me.”

A better mindset is:

“Here is my architectural intention. Generate a useful starting point so that I can inspect, understand, test, and refine the resulting Agent.”

That small change in mindset is significant.

It moves the maker from prompt consumer to Agent architect.

29. Conclusion

The natural-language creation experience in Microsoft Copilot Studio is more than a convenient way to avoid filling out several fields.

It introduces a different authoring model.

The maker can express the desired Agent semantically:

What it is
What it knows about
How it should behave
What sources it should prefer
What it should avoid
What capabilities should exist
What capabilities should not exist yet

Copilot Studio then interprets that specification and produces an initial configuration.

However, the generated Agent must still be inspected.

The most important principle is:

Natural language expresses architectural intent; it does not replace architectural validation.

Our WristWatchBuildingCompanion experiment demonstrated this particularly well. URLs included in the creation specification were recognized by the builder and surfaced as Knowledge suggestions rather than silently becoming confirmed Knowledge Sources.

That simple observation reveals the broader engineering pattern:

Intent
   ↓
Specification
   ↓
AI interpretation
   ↓
Generated configuration
   ↓
Human validation
   ↓
Testing
   ↓
Refinement

As Copilot Studio and Agent authoring continue to evolve, natural language may increasingly become a first-class interface for solution architecture.

But the responsibility for understanding the resulting system — its Instructions, Knowledge, Retrieval, Grounding, Topics, Tools, permissions, security, governance, and lifecycle — remains with the solution architect.

The future of low-code Agent development may therefore not be “configuration without engineering.”

It may be something much more interesting:

engineering through intent.

Official Microsoft References

• Microsoft Learn — Write agent instructions
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-instructions
• Microsoft Learn — Create and configure agents
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-first-bot
• Microsoft Learn — Knowledge sources overview
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/knowledge-copilot-studio
• Microsoft Learn — Add knowledge sources
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/knowledge-add-existing-copilot
• Microsoft Learn — Generative orchestration
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions
• Microsoft Learn — Use tools with custom agents
  https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-plugin-actions

Key Takeaway

The initial natural-language prompt is a specification for building the Agent, not a substitute for understanding the Agent.

A disciplined Copilot Studio workflow is therefore:

Describe → Generate → Inspect → Understand → Configure → Test → Evaluate → Refine → Publish → Monitor.