01 Start with a task your team knows well
A team needs new laptops and sends a request to purchasing. Someone has to establish how many devices are needed, what specifications they must meet and when they should arrive. Missing details lead to questions. We chose this example to explain a first agent role; it is not an observed client case.
The agent could prepare these requests: collect the details, link to the original message and flag gaps. A named person in purchasing reviews the result and decides what happens next. That gives the agent a clear first task. “Make purchasing more efficient” would be too vague.
First, check whether you need an agent at all. A fixed rule that forwards every request to a mailbox can be automated without one. Our guide to choosing an agent or automation helps with that decision.
02 Decide what the agent is allowed to do
Preparing a request is different from ordering laptops. In this example, the agent may read approved messages and organise the information. A person keeps authority over purchasing commitments. Put that boundary in the role description and enforce it through the system’s permissions.
This is what we mean at MING by “hire, don’t deploy” : the agent gets an assignment, suitable tools and a person to report to.[S1] It works within an existing team. Treating it as a colleague helps define the job; the named person remains responsible.
03 Name the person who will supervise the agent and review its work
The person in purchasing needs to know where prepared requests arrive and when to review them. They need time for feedback and someone to cover their absence. The requesting team also needs to understand the arrangement. An agent watching a new mailbox is little help if everyone keeps writing to the old one.
The following agreement makes the example role concrete. Work through it with the team before building the integration.
| What to agree | Purchasing example |
|---|---|
| Where does work arrive? | The team sends its request to the agreed mailbox and names a person who can answer questions. |
| What should the agent produce? | A summary of quantity, requirements, requested date and a link to the request. Missing details are flagged. |
| Who reviews and decides? | A named person in purchasing checks the summary, resolves gaps with the team and decides on the purchase. |
| What must the agent not do? | It does not order devices or promise delivery dates. |
| Who helps when something goes wrong? | The responsible person or their cover takes over the request, records corrections and can pause the agent. |
The graphic shows the same workflow. If the number of laptops is missing, for instance, purchasing takes the question back to the team. A well-written summary cannot resolve that gap on its own.
04 Give the agent access to the systems its task requires
You can now describe the technical task. The agent needs the approved requests and somewhere to leave its summary for purchasing. It does not need ordering access. Ask the responsible people to agree which data it may read and which records it may change.
Microsoft documents controls for Copilot and agents covering data access, overshared information and audit logs, among other areas. Availability depends on the product and licence.[S3] Check the setup you actually use. A list of vendor features does not tell you which access your organisation has approved.
05 Test incomplete requests and staff absences too
Try the role with typical requests under approved conditions. The person in purchasing reviews each summary: are the details correct, is anything missing, and can they use it to continue the work? Record how much time review and correction take.
Then test a missing quantity, conflicting dates, denied access and the responsible person’s absence. While the role is being introduced, the team must still be able to handle requests itself. Our guide to testing before production covers technical checks in more detail.
A Lünendonk survey of 180 leaders in larger DACH organisations illustrates the gap between a pilot and routine use: 66% reported that fewer than a quarter of their previous AI pilots had reached production.[S2] These are organisation-level self-reports. They establish neither a universal project failure rate nor the effectiveness of our method.
06 Expand the role once it is helping the team
At the agreed review, decide whether the agent makes the work easier. Can people handle requests without constant help from the project team? Is the benefit worth the review and rework? Only then consider another task or greater independence.
You can also narrow the role or end it. Our guide to stopping an agent helps with that decision. To work through a first role with us, bring a recurring task, typical inputs and the person who needs the result. In a Hybrid Organisation workshop , we can use those to develop the first role description.
Evidence and limits
- The purchasing example, table and graphic explain MING’s proposed method. They show no client case or measured productivity gain.
- The survey provides context for introducing AI, not evidence that this workflow is effective.
- This page gives no universal implementation duration. Platform access and legal requirements need to be resolved for the specific use.
