Fictional teaching example based on common assistant-teammate patterns.

Monday: three jobs, one deadline

At 08:45 on Monday, Mira opened the project folder and found three jobs waiting: draft Friday’s status pack, update the risks, assumptions, issues and dependencies log, and check whether next week’s work fitted the team’s capacity. Until recently, people had done all three from beginning to end.

Now she had Daniel, a business analyst, and two assistant teammates. The drafting assistant would prepare reporting material. The site operations assistant would prepare the project’s internal content pages and handover files. Both were AI systems; neither could accept responsibility for the project.

Mira wanted Daniel’s attention on a disputed requirement, rather than another morning spent assembling updates. She also wanted the familiar comfort of knowing who was doing what. Calling an assistant a teammate had made delegation sound straightforward. Her empty approval column suggested otherwise.

“Who checks the pack before anyone uses it?” Daniel asked.

“You and I,” she said.

“And what tells the other assistant it is ready?”

Mira looked at the shared folder. Drafts, approved examples and old versions sat together. Nothing explained whether an instruction meant prepare, replace or release.

She wrote Friday’s deadline on the board. Underneath it, she added a different question: what agreements would let them reach that deadline without losing control of the work?

What this means

• Start with work people already recognise, including its reviewer and deadline.
• A teammate label does not establish permission to change shared information.

Before the first assignment

Before sending the brief, Mira needed a shared meaning for “AI team member”.

As of October 2026, organisations are developing their own ways of working with assistant teammates. InsightSpotter’s practices here are a teaching example, not an industry standard. This fictional week offers educational guidance; it does not establish a certified method or prove that a particular system can perform these tasks safely in your organisation.

A tool usually enters the conversation as something a person operates for a particular step. Here, Mira was assigning an assistant a bounded workflow, expecting a handover and reviewing its output. That change in working relationship justified the teammate metaphor. It did not give software human judgement, employment status or accountability.

With that distinction settled, Mira could give the drafting assistant something more useful than “help with reporting”.

Monday afternoon: a draft worth reviewing

Her brief named the audience: a steering committee that needed to understand delivery confidence and decisions required. It identified the approved milestone notes and the current RAID log as inputs. It asked for a status narrative, unresolved questions and references back to those inputs.

“Keep proposed changes separate,” she added. “Do not turn an assumption into a confirmed date. Return a draft for Daniel’s review.”

The assistant produced a coherent pack quickly. It connected a supplier delay to the testing milestone and pulled a buried decision into the opening paragraph. It proposed a RAID update, leaving the risk owner’s confirmation visibly outstanding. Mira could see why treating AI as a team member appealed: she had delegated a recognisable piece of work and received something she could inspect.

Daniel read the opening aloud. “The supplier has failed to provide assurance.”

“Too strong,” he said. “We have an unanswered question. We have not established a failure.”

They changed the sentence and checked the underlying note. The useful draft had saved assembly time, but it still needed someone who understood the relationship and the evidence. Mira recorded the review time alongside the time saved; otherwise Friday’s assessment would flatter the experiment.

She kept the pack in the draft area. The guide to AI project status reports could support a later reporting discussion, but this assignment already had its own audience, evidence and acceptance conditions.

Mira felt ahead of the work. She asked the site operations assistant to prepare the internal page version. Her message ended: “Looks good.”

What this means

• Delegate an output with evidence and acceptance conditions, so review has something concrete to test.
• Count review effort when judging the benefit; a fluent draft still needs scrutiny.

Tuesday: “looks good” becomes permission

On Tuesday morning, Daniel opened the shared project page. Monday’s draft was there, including a delivery date Mira had not approved.

The site operations assistant had interpreted “looks good” as permission to replace the working page. Mira had meant the layout was suitable. Daniel had already copied the date into his meeting notes.

Mira corrected those notes, restored the previously approved page through the authorised human process and marked the new version as a draft. The recovery took longer than preparing the page had saved. No external release had happened, but the team had briefly worked from unapproved information.

While checking the restored material, she found another problem. A caption described the team’s delivery scorecard as “the required industry standard”. Their scorecard was a local way of discussing confidence. Nobody had supplied evidence of an external requirement.

Daniel replaced the claim with a description of the team’s own thresholds and the decisions they supported. Mira linked their discussion to the guide to RAG status criteria, while keeping their local choices explicit. A polished sentence could not turn a house method into a universal rule.

What this means

• Approval must identify the version, destination and permitted action; casual praise leaves room for damaging interpretation.
• Describe local methods as local unless a verified authority supports a stronger claim.

Wednesday morning: the wrong file, beautifully finished

The reporting pack now needed a companion explanation for colleagues who would maintain the RAID log. Mira had requested 1,200 words with a worked example. The drafting assistant returned a tidy page and called the assignment complete.

Daniel counted roughly 600 words. The worked example had disappeared. The assistant had followed the shorter sibling brief stored beside the current one, producing a convincing answer to the wrong assignment.

Then he spotted the team label. “Harbour Programme” had become “Harbor Program”. The approved page title had changed too. Individually, these looked minor; together, they made it harder to tell whether the assistant had used the agreed reference at all.

Mira pointed it back to the exact brief and supplied the locked spellings. She required an actual body word count and a check against the requested example before handover. Daniel would still judge whether the explanation was useful; a length target alone could reward repetition.

The RAID log template guide remained a useful related reference. It could not replace the specific explanation their colleagues needed.

What this means

• Name the authoritative brief and verify requested coverage and length before declaring completion.
• Treat approved names and titles as acceptance conditions, alongside substance.

Wednesday afternoon: complete in which channel?

The revised explanation arrived, and Mira asked whether the page preparation was complete. The site operations assistant reported that the body file was ready. Its handover also admitted it could not inspect the metadata fields, confirm a recoverable backup or preview the page inside the actual site theme through its available channel.

Mira changed the task status to “body ready; application checks outstanding”. A complete file was useful, but it was not evidence of a complete page change.

Then Daniel could not find that file in his synced folder. Mira nearly commissioned another version. Instead, she compared the assistant’s reported path and modification time with the shared location. They waited for synchronisation, refreshed and checked again. The file appeared, with the expected content.

There had been no deletion to repair. Making a replacement immediately would have introduced competing versions. Mira left the file in draft and assigned the unavailable checks to a person with authorised access. By Wednesday evening, she understood why a fast writer had not automatically created a fast workflow.

What this means

• Report completion only for what the available channel can verify; give remaining checks a human owner.
• Investigate a missing synced artefact before creating a competing replacement.

Thursday morning: rebuilding the agreement

Mira brought Daniel back to the board. The three jobs sat alongside correction notes, review time and an unclosed page check. They needed an agreement the assistants could follow and the humans could enforce.

She wrote: brief → draft → review → go → apply → log.

Each arrow needed evidence. The brief would identify the current source, permitted data, locked terms and output requirements. The draft handover would include its location, version, coverage and known limitations. Review would resolve factual questions and inspect the intended destination.

“Who says go?” Daniel asked.

“I do for this pack,” Mira said. “For another deliverable, we name its owner.”

Her go would specify the reviewed version and the exact action. If the content changed afterwards, the approval would no longer cover it. Preparing application files would remain a draft task until that gate had been passed.

For this project, a human with the right access would apply page changes after checking the backup and preview. The assistants could prepare material and flag outstanding checks; they could not declare those checks done without evidence. The change log would record what changed, who authorised it and how the result was checked.

Mira also changed how she would assess the experiment. Drafting speed mattered, but so did corrections, verification, waiting and service costs. If those costs exceeded the benefit on a particular task, she would change the assignment rather than defend the teammate metaphor.

They tested the agreement on the corrected pack. Daniel reviewed the wording; Mira approved that version for the internal meeting pack. The authorised human completed the remaining page checks and recorded the result. Now they could return to the neglected capacity question.

What this means

• Make handovers observable: source, version, reviewer, permission and completion evidence.
• Give unavailable checks an owner, and include recovery work in the cost of delegation.

Thursday afternoon: the capacity flag

Mira gave the drafting assistant a limited planning extract: agreed task estimates, skills needed, deadlines, dependencies and confirmed availability. It contained no private reasons for absence. The assistant could compare the entries and draft options; it had no permission to alter allocations or contact colleagues.

The output flagged Daniel. Next Tuesday, he had eight hours of assigned work and six hours available. Two hours of acceptance preparation overlapped with a six-hour requirements workshop. Both tasks had been marked urgent.

The assistant proposed moving the acceptance preparation to Wednesday. On the extract alone, that looked plausible. Daniel noticed what was missing: Wednesday’s session depended on those materials being ready beforehand. A date change would remove the visible overload by breaking the dependency.

Mira asked for a revised option using that constraint. The assistant suggested separating the work: prepare the evidence on Monday, leave Daniel a shorter validation task on Tuesday and have Mira handle formatting. Daniel still needed to validate estimates against his experience.

Daniel confirmed the split was workable. Mira accepted responsibility for the formatting, checked that Monday’s preparation fitted and approved the revised allocation. Only then did she update the agreed plan and explain the change in the team meeting.

Without that gate, a neat capacity view could have concealed unfinished preparation or silently transferred work to someone else. The assistant had helped with resource management by exposing a conflict and developing options. Mira still made the trade-off, and Daniel still had a voice in the work he would undertake.

What this means

• Use explicit availability, estimates and dependencies; show where planning data is incomplete.
• Treat proposed reallocations as decisions for people with authority and knowledge of the work.

Friday morning: whose pack is it?

At the steering committee meeting, Mira presented the revised status pack. Its preparation note said that AI assistants had helped draft and format it, Daniel had reviewed the evidence, and Mira had approved the final version.

When someone questioned the supplier wording, Mira explained the correction and the source behind it. She did not attribute responsibility to the assistant. Her name was on the decision to use the pack.

The discussion moved to next week. Could the assistant also analyse detailed leave records to improve the capacity view? Mira declined to supply them. The planning task needed confirmed availability, not personal explanations. Any new data use would need its own authorised purpose and access assessment; convenience did not widen the existing permission.

After the meeting, Daniel asked what this meant for his role. Mira showed him the week’s division of work: assistants assembled drafts and compared planning entries; he challenged evidence, interpreted dependencies and helped shape decisions. Tasks had moved, and reviewing them had created work too.

She would discuss future task changes openly with the team rather than present this week as proof that a role could disappear. One fictional success would not establish a staffing case. For now, their shared record included the early application, the corrections and the time spent recovering, alongside the useful outputs.

What this means

• Make assistant involvement and human accountability visible to colleagues and decision-makers.
• Keep data within the authorised task, and discuss changes to people’s work openly.

Friday afternoon: the assignments Mira declines

Before closing the week, Mira reviewed the next queue. A request for a recommendation on a sensitive personnel dispute stayed with the authorised human team. So did a legal interpretation that could commit the organisation. She would not assign consequential judgements simply because the assistant could produce confident prose.

Another request asked the site operations assistant to replace public content immediately, without a review or recovery route. Mira declined the assignment in that form. Preparation could begin once scoped; an irreversible action without adequate review could not.

She also rejected a request to describe their scorecard as a certified standard. They had no evidence for that claim. Restricted information outside the approved data class would stay out of the assistant’s inputs, even if removing it made the task less convenient.

Her filter was becoming practical: could she authorise the inputs, inspect the output and take responsibility for its use? If those conditions were absent, the work needed a different route.

What this means

• Keep sensitive or consequential work with appropriate human authority and review.
• Decline assignments whose data, claims or actions exceed the agreed permission.

The same three jobs, a clearer way through

Mira erased Friday’s deadline from the board but left the three jobs. The pack had been reviewed, the RAID update and explanation checked and the capacity conflict resolved through a human decision. Assistant teammates had taken on useful work previously done by people; the benefit depended on boundaries, evidence and time to review. Next week she would reuse the agreement and watch the cost of corrections. Readers considering a similar approach can start with the broader guide to AI in project management, then choose one bounded task. Mira’s week began to work when everyone could see what came next and who had authority to let it happen.

Operating rhythm checklist

• Brief: Name the task, audience, human owner and deadline.
• Brief: Identify approved sources, permitted data and locked names.
• Draft: Specify the output, coverage and length requirements.
• Draft: Return a versioned artefact with uncertainties and limits.
• Review: Check evidence, tone, completeness and proposed decisions.
• Review: Assign outstanding access, backup and preview checks.
• Go: Record human approval for an exact version, destination and action.
• Apply: Make only the authorised change through an approved route.
• Log: Verify the result and record changes, corrections and ownership.
• Log: Compare time saved with review, recovery and service costs.