A first-week plan for your first AI employee

Think about the best first week you ever gave a new colleague. It had a shape. On Monday they learned one job, not ten. They got the procedure, the list of things that go wrong, and the policy folder. They were told which decisions to bring to their manager. They shadowed before serving a real customer, started with a small share of the work, and went through the day with their manager each afternoon.

Your first AI employee deserves the same week. This post is that schedule, for the operations lead or owner about to hand over a first piece of work. It is a plan, not a guarantee: how long each phase takes depends on your work, not on a calendar. Throughout, a person on your team stays in charge: a workspace owner who decides what goes live and reviews what the AI employee did.

flowchart LR
  A["1. Pick one job"] --> B["2. Write the procedure<br/>and the exceptions"]
  B --> C["3. Gather the documents"]
  C --> D["4. Decide what waits<br/>for a person"]
  D --> E["5. Rehearse as a draft"]
  E --> F["6. Go live small"]
  F --> G["7. Review the records daily"]
  G -->|adjust| B

Before day one: decide how you will know it worked

Write down, before you build anything, the two or three numbers you will judge it by. How many requests of this kind arrive a week? How long does each take a person today? How often does a person have to step in or redo the work? What does a mistake cost?

These are your numbers, measured on your work. We claim no savings, accuracy or speed figure for you. Wetel gives you the records to measure with (below); the baseline has to come from you, and first, or later you will be comparing against a memory.

Day 1: choose one narrow, repetitive, checkable job

Start with a small job. Look for work that is:

• Narrow. One kind of request, not “customer service”. “Tell a customer where their order is” is a job. “Handle the inbox” is a department.
• Repetitive. It happens often enough that a week of it teaches you something.
• Checkable. A person can look at what was done and say right or wrong without a meeting. An order status is checkable. A tone of voice is harder.

It helps if the answers live in documents or systems you already have, and a wrong answer is cheap to undo. The cookbook shows the shapes that fit this well: a support agent that answers from your own documentation, a first-round candidate screening interview, an order-status and product-support agent, and an agent that reads photos customers send. The case studies describe real ones, such as a university library assistant, without customer names.

If Wetel has listed a ready-made role close to your job, a workspace owner can hire it instead of building from scratch; see hiring a role instead of building one.

Day 2: write down the procedure, and especially the exceptions

An AI employee in Wetel has two parts. The persona says who it is and how it speaks. The workflow is the procedure: a graph of steps that decides what happens on each message (understand the request, look something up, branch, reply).

Before anyone opens the builder, write the procedure on one page, as you would for a new colleague:

1. What requests count as this job, and what should be politely handed to a person instead.
2. The steps, in order, including what to look up and where.
3. The exceptions, the part people skip: the order that cannot be found, the customer who asks two things at once, the request that is almost this job.
4. What a good reply looks like, with two or three real examples.

The exceptions become branches in the workflow. A step that calls another system can have a success path and a failure path, so “the lookup did not work” can lead to an honest reply instead of a dead end. Our workflow best practices have one rule worth taking into this page: keep the step that pulls a value out of a message separate from the step that writes the reply. It is more reliable and easier to check.

Day 3: gather the documents it will answer from

An AI employee’s policy folder is a knowledge base: a collection of your documents that a step in the workflow reads from, so answers come from your content instead of a guess. Today you can add PDF, DOCX, Markdown, CSV and XLSX files, up to 20 MB each, or add text directly. The knowledge base belongs to your workspace.

Two habits matter more than the volume of documents:

• Pick the current versions. An outdated policy will be quoted confidently.
• Ask it real questions before you rely on it. You can test what the knowledge base finds for realistic questions, using the same lookup the workflow uses, before you connect it to anything.

One thing to know: if the lookup fails for a moment, the reply still goes out, without the extra context. The run record shows whether the lookup ran, so you can check. We go deeper on this in answering from your own policies, with sources you can check.

Day 4: decide what must wait for a person

Write the list of decisions that go to the manager, using three questions per action: can it be undone, who sees it, and what does a wrong one cost? Our post on what an AI employee should do alone walks through that ladder.

Then build it in. In Wetel, a sign-off is an approval step you add to the workflow. It is not on by default: if you do not add one, the workflow does not stop to ask. Where you do add one:

• The run pauses until a workspace owner approves or rejects it, with an optional comment. When approving, they can correct only the fields you allowed them to edit.
• Every active owner gets an in-app notification. Email notice is not available yet.
• Every approval step must have three paths wired up: approved, rejected and expired. If nobody decides in time (72 hours by default, at most 14 days), the run takes the expired path, never the approved one. We cover that case in what happens when nobody approves in time.
• The approval step says nothing to the customer. Put a reply before it, such as “I’ve asked a manager to review this”, so they know a person is checking.

Who decides matters too. Today only workspace owners can read the approvals inbox and decide, so make sure the person you picked as this AI employee’s manager is an owner of your workspace.

Day 5: rehearse it as a draft

Before a customer sees anything, run the workflow as a draft in a test session. Edits reach real conversations only when someone publishes. You can also simulate each approval outcome without opening a real request. The full steps, and one caution about steps that call other systems, are in how to try a workflow safely before customers see it.

What to rehearse:

• Twenty or thirty real requests, in the words customers actually use, not your one tidy example.
• Every exception from your Day 2 page.
• Every approval outcome: approved, rejected and expired.
• The failure paths of anything that calls another system.

After each test, read the run record: every step the run visited, in order, with what each produced.

Day 6: go live small

Publishing is a decision a person makes; nothing goes live on its own. When you publish, start small: one channel, one kind of request, one team’s customers, or the hours when someone is watching. It is how you collect evidence cheaply, before a mistake reaches everyone.

Keep your own copy of each version you publish, so that if a later change goes wrong you can put back one that worked.

Day 7 and every day after: read the records, then adjust

The afternoon sit-down with a new colleague becomes a short daily review. A person on your team, signed in to your workspace, can read:

• Each conversation’s messages, start to finish.
• Each run’s step-by-step record: which steps ran, in what order, what each produced, and where one failed.
• A per-agent summary over a window (the last day, week or month): runs by outcome, recovered failures, open questions waiting on a person, and a flag for an agent that needs attention.
• Evaluations: a score for a finished conversation. For a conversation the workflow ends, one is generated only when its end-session step asks for it, so switch it on if you want it.

Read for patterns, not single mistakes. If the same error keeps coming back, change the workflow’s structure (split the step, add a branch, add a document) rather than rewording the instructions again. Before you change a step that routes messages, save a real run as a regression scenario and replay it against your draft, so you can see whether the change quietly sends conversations down a different path. Then go back to Day 2, update the page, and rehearse again.

Nothing alerts you today when an agent starts going wrong. Being told without having to look is on the roadmap, not built, so the daily review is a person’s job for now.

What to expect from us

Honestly, this is what is live today and what is not.

Live today:

• Agents with a persona and a workflow, knowledge bases from your own documents, approval steps you add, draft testing with simulated approval outcomes, and run records you can read.
• Guided setup: Wetel can set up a role in your workspace for you, with a setup checklist for anything that needs your own credentials, and workspace owners (on the PRO plan for now) can hire a role Wetel has listed. Nothing is listed until Wetel lists a role, so today that is by invitation.

Not built yet:

• Approval by default. A pause happens where someone adds an approval step.
• Email notice for approvals, and approvers other than workspace owners.
• Memory across conversations. Each new conversation starts fresh.
• Alerts when an agent needs a person, starting work when something happens in another system (scheduled work exists; event triggers do not), and phone calls.

None of that stops a good first week. It means a person on your team is the manager, does the daily review and decides when the AI employee takes on more. The changelog records what arrives and when.

Related reference docs

• Getting Started: what an agent is, and the two ways to work with Wetel
• Workflow best practices: patterns that make a workflow reliable and easy to check
• Knowledge Base: supported files, ingestion, and testing what it finds
• Human approval: a walkthrough: add a manager’s sign-off, test it and decide
• Approval node: fields, the default and maximum wait, and the three required paths
• Observability and debugging: reading a run’s step-by-step record and evaluations
• agentActivitySummary: the per-agent summary for your daily review
• Regression scenarios: replay a real run against your draft before a change
• Cookbook and Case studies: proven shapes for a first job
• Roadmap: what is direction, not yet built

If you are planning your first week, tell us which work you’d hand over first.