Build your first Agent

Build one Agent capability end to end: define the operational outcome, connect evidence and systems, teach a reusable Skill, test it and hand it to operators.

Use this walkthrough when you want to go from a business problem to one useful, tested Agent capability.

The example is sales-order intake from Outlook into an ERP. The same pattern applies to supplier follow-up, tender responses, invoice checks, master-data work and other operational tasks.

1. Start with the operational outcome

Open the Agent in the Project that should own the work and describe the outcome in business language.

For example:

I want to set up order intake. Orders arrive in Outlook as emails and PDFs and need to end up correctly in Business Central. I want the Agent to resolve what it can, ask when customer/product/pricing information is genuinely unclear, and never invent commercial terms.

That is enough to start discovery.

Do not begin by designing every tool call or writing a large instruction block. Let the Agent identify what it still needs to know.

2. Establish the source of truth

Before automating the task, settle which evidence owns which facts.

For example:

• current customer and product records → ERP;

• customer-specific mappings → maintained Table or source system;

• commercial policy → approved Knowledge;

• order document → case-specific evidence;

• recurring validation method → Skill.

Tell the Agent where uncertainty must return to a person.

This source-authority model is more important than a clever prompt.

3. Connect the systems the work needs

Ask the Agent to use or initiate the required Connections.

For supported providers, it can guide the setup flow. The human still completes provider authentication or secure credential entry.

Do not paste secrets into the conversation.

After connecting production authority, check the Connection scope, enabled actions and approval policy under Control → Connections.

4. Give it representative work

Use a small set of real-shaped examples that cover both the normal path and important exceptions.

For order intake, useful examples might include:

• a clean known customer/product order;

• a new delivery address;

• an ambiguous product description;

• a price that disagrees with the ERP;

• a missing requested delivery date.

Run the task with the Agent and correct the method, not only the final answer.

5. Turn the method into a Skill

Once the task shape is clear, ask the Agent to create or update the reusable Skill.

A strong Skill should capture:

• the intended outcome;

• source authority;

• rules and checks;

• systems and supporting components;

• what can be acted on automatically;

• what requires approval or a person;

• what evidence proves success.

The Agent presents the proposed capability for review before it becomes the maintained Project Skill.

6. Test representative cases

Use the Skill's Tests surface as a regression set.

Start with the examples you already used to teach the method. Add important failure/exception cases as they appear.

A useful test tells you whether the expected business criterion was met. If a test is inconclusive or errors, establish what happened before treating the Skill as wrong.

Correct the cause, rerun the affected cases and review the proposed change.

7. Publish deliberately

Publish only when the reviewed method and representative tests give you enough confidence for the intended boundary.

Publishing makes the reviewed Skill the maintained capability. It does not make the whole process autonomous and it does not remove approval or human boundaries.

8. Run a fresh operator session

Start a new Agent session and use the Skill as an operator would.

Do not rely on the long build conversation as hidden configuration. The new session is a useful test that the durable Project setup actually carries the method.

Verify:

• the right Skill is used;

• the right sources are consulted;

• required approvals/questions appear;

• the concrete output or system change is correct.

9. Improve from evidence

Use session feedback, Activity, test failures and repeated corrections as evidence for the next reviewed improvement.

If the same stable sequence is executed at high volume, consider moving that deterministic part into a Workflow while keeping the Agent for interpretation, investigation and exceptions.

Definition of done

Your first Agent capability is in a good place when:

• an operator can describe the job in business language;

• the Agent can access the evidence and systems it needs;

• source authority and human boundaries are clear;

• the recurring method lives in a reviewed Skill;

• representative cases are tested;

• a fresh session can complete the job without relying on build-session history;

• the result can be verified in the system or artefact that owns it;

• bad outcomes have a clear feedback and improvement path.

From here, expand the test set and move only the sufficiently stable parts further into background execution.