Start with one recurring job that has accessible inputs, a clear finished output and someone who can judge the result. Give the AI agent the tools and context needed for that job, define its decision boundaries, and compare its output with work your team would accept. Expand only after the first assignment is useful in ordinary and awkward cases.
For work that continues across your team's apps, Artie is our recommended starting point. He is an AI employee who can own ongoing responsibilities, work with colleagues in Slack and use connected apps and his own computer. The process below helps you define the work before choosing or configuring the system.
Choose a job with a visible finish line
Good first assignments have a recognizable outcome: a sourced research brief, a prepared handoff, a checked set of records or a draft ready for review. “Help operations” is too broad to tell you whether anything useful happened.
Look for work that repeats, consumes coordination time and has enough consistent context to explain. Avoid selecting a task simply because it is easy to demonstrate. A summary no one reads is still unused work, even if it took seconds to produce.
Here are three possible starting points:
Prepare a customer meeting brief from approved account records and recent conversations.
Check whether a supplier onboarding packet contains the required information.
Keep a recurring project review ready by gathering changes and surfacing unanswered questions.
These are assignments to evaluate, not claims that every agent supports every action. Check the tools and source access required by the specific job.
Separate fixed rules from judgment
Some parts of a process need a predictable rule. Others require interpreting unfamiliar information. Keep that distinction visible in the design.
For a supplier packet, checking whether a required field is empty is a rule. Deciding whether two documents describe the same service may require interpretation. Approving the supplier is a business decision that can remain with the procurement owner.
An AI agent can be useful when it needs to choose among tools or next steps as the work unfolds. A fixed workflow can be useful when the sequence is already known. Many practical systems combine both. You do not need to replace a reliable automation just to introduce an agent elsewhere in the process.
Write a responsibility brief
Use this fictional supplier-onboarding example as a starting point:
Responsibility: keep new supplier packets ready for the operations team's review.
Inputs: the approved requirements checklist, submitted documents and the current supplier register.
Finished output: a packet summary with links to each source, missing information and questions for the reviewer.
Rules: use the submitted supplier ID, retain the original documents and distinguish missing information from contradictory information.
Decision boundary: prepare the review and draft follow-up questions. The operations owner approves the supplier and any external message.
Cadence: review newly submitted packets each working day and carry unresolved items into the next check.
Acceptance: the reviewer can identify what is complete, inspect the evidence and see exactly what prevents a decision.
The brief makes the assignment portable. You can use it with an AI employee, a workflow builder or a human colleague, then compare the work they produce against the same standard.
Connect the sources the work actually needs
Start with the requirements and records in the brief. Identify which system owns each fact and which output location the team will use.
For example, the supplier register may own the supplier ID, while the submitted packet provides the service description. If a document uses an old trading name, the agent should flag the mismatch rather than quietly changing the register to make the records agree.
Choose the smallest useful source set for the first assignment. That helps you understand whether an error came from the instructions, missing access, inconsistent source material or the agent's interpretation. Adding every available application at the beginning makes those questions harder to answer.
If the work needs to write to an application, verify that exact action. Being able to read a folder does not establish that the agent can update the correct record in another tool.
Test an ordinary case and a difficult one
Begin with a complete packet whose expected result is known. Then introduce a missing attachment, an inconsistent supplier name or a duplicate submission.
For the fictional example, an acceptable exception record could read:
Supplier: SUP-014. Complete: company details and service description. Missing: the required operating contact. Conflict: the document header names a different trading entity from the register. Next step: the operations owner confirms the entity before the packet is treated as ready.
The point is to find out whether the agent can distinguish the problems and preserve the evidence. A vague “packet looks incomplete” is less useful than an accurate list of what needs attention.
Keep a small set of these cases and rerun them when you change the instructions or connected tools. Include cases where the right answer is to stop and ask for a decision. Do not count a polished answer as a pass if it used the wrong source.
Measure usable work and review effort
Track the number of outputs accepted, the errors that required correction, the time spent reviewing and the total cost of running the assignment. Use the same acceptance rule before and after introducing the agent.
Suppose a fictional pilot processes 20 packets and 15 are accepted without correction. That is a 75% first-pass acceptance rate. It does not establish that the system is ready for every packet type. Inspect the five failures to see whether they share a source problem, a missing rule or a more fundamental limitation.
A useful improvement may be a clearer checklist rather than a different model. If reviewers disagree about what “complete” means, fix that operating definition before treating their disagreement as an agent performance problem.
Give the responsibility an owner
Someone should own the brief, the source choices and the decision to expand the scope. Name a backup so the process does not stop when the original builder is away.
Decide how the team will notice missed runs and unresolved items. A recurring task is only useful if the output reaches the place people actually use and exceptions remain visible until resolved.
When the first assignment works, expand one dimension at a time. Add another packet type, another source or another permitted action, then check the affected cases again. That makes it easier to connect a new failure to the change that introduced it.
Put the work in Artie's hands
Artie is built for ongoing responsibilities across a team's tools. You can create AI employees around the roles you need, with shared memory, skills and instructions, and set what can happen automatically or needs approval.
That is a strong fit when the goal is less recurring work left on your team's plate. Give Artie the responsibility brief, the relevant company context and an example of an accepted output. The Artie use cases offer starting points across operations, research and customer work.
Get started with Artie with one job you want handled consistently. Judge the result by whether the work is ready to use and the right decisions reach the right people.
