Client AI assistant work · Human-led implementation · Clear roles, testing & handover
AIAI ExpertsBook AI support
Home / Case Studies / AI Agents & Custom Assistants
AI agents & custom assistants case studies

Two client assistants built around a defined job, controlled knowledge and repeatable outputs.

These case studies are based on assistant and agent implementation work delivered across client engagements. They show how role definition, source rules, task templates, outputs, tool permissions and testing were turned into usable systems. Identifying details are omitted where unnecessary.

Case Study A · Research assistant

Source-aware research and briefing assistant for recurring market scans

A client team repeatedly researched competitors and market changes, but each person prompted the AI differently and the final briefing format changed from request to request.

Starting stackGeneral AI assistant + research tools
Main riskUnsupported claims and inconsistent briefs
Primary goalRepeatable, source-aware research output
Delivery patternInstruction design + templates + QA

Starting problem

Broad requests such as “research this competitor” produced a mixture of facts, assumptions and generic advice. There was no consistent source-freshness rule, evidence hierarchy or executive briefing structure.

Constraints

  • The assistant needed to label uncertainty and avoid inventing source-backed facts.
  • Research had to use a structure that decision-makers could scan quickly.
  • Users needed reusable request templates rather than one unmaintainable giant prompt.
  • Web access and connected research tools remained dependent on the selected platform.

A→Z implementation

  1. Define recurring research jobsMapped competitor scans, product comparisons, meeting briefs and market updates to the audience and decision each output supported.
  2. Set evidence rulesDefined acceptable source types, recency expectations, handling of conflicting information and how unsupported claims should be marked.
  3. Build the core instructionCreated role, research process, evidence hierarchy, uncertainty language, prohibited behaviors and output structure.
  4. Create task templatesBuilt reusable input formats for common research tasks so users supplied the minimum useful context consistently.
  5. Test difficult research situationsTested stale sources, incomplete questions, conflicting evidence, missing data and prompts that invited overconfident conclusions.
  6. Refine and hand overFinalized the instruction, templates and an operating guide for requesting and critically reviewing research.

Artifacts delivered

Research assistant system instruction
Source and uncertainty policy
Reusable research request templates
Executive briefing output schema
Quality-control test set
User operating guide

Acceptance criteria

  • The assistant separated sourced facts, interpretation and uncertainty.
  • Briefs followed the intended structure across different research topics.
  • Missing evidence was surfaced instead of silently filled in.
  • Users could start common tasks with reusable request templates.
Case Study B · Operations assistant

Internal SOP assistant that answers from approved procedures and escalates policy gaps

A client operations team stored procedures across multiple documents and checklists. Staff repeatedly asked similar questions, while the existing AI setup sometimes mixed outdated and current instructions.

Starting stackSOP documents + internal assistant
Main riskInvented or outdated process guidance
Primary goalControlled operational Q&A and task support
Delivery patternKnowledge cleanup + boundaries + testing

Starting problem

Documentation was fragmented, several procedures overlapped and users could not easily tell which source was current. The assistant answered quickly but did not reliably expose policy gaps or conflicts.

Constraints

  • Only approved operational documents could be treated as authoritative.
  • Conflicting, missing or policy-sensitive instructions required escalation.
  • Manager-only approvals had to remain outside the assistant's authority.
  • The knowledge set needed a repeatable maintenance process.

A→Z implementation

  1. Map use cases and ownershipListed recurring operational questions, task types, policy-sensitive topics and ownership of each source document.
  2. Clean the knowledge setRemoved duplicates, separated current procedures from old material and flagged contradictory instructions for human resolution.
  3. Configure assistant boundariesDefined how to answer, when to clarify, when to summarize approved procedure and when to escalate.
  4. Create repeatable task modesBuilt templates for SOP lookup, handover summaries, checklists and document-preparation tasks.
  5. Test policy-sensitive casesTested outdated procedures, missing source material, conflicting rules, incomplete requests and manager-approval scenarios.
  6. Handover maintenance processDocumented how to update sources, retire old material and rerun critical tests after changes.

Artifacts delivered

Use-case and authority matrix
Clean knowledge inventory
Operations assistant system instruction
Reusable SOP/task templates
Policy-sensitive test matrix
Knowledge maintenance checklist

Acceptance criteria

  • Routine SOP questions used the approved current guidance.
  • Conflicting or missing policy information was escalated instead of invented.
  • Manager-only decisions stayed outside the assistant's authority.
  • The team had a repeatable process for source updates and retesting.
Assistant behavior still depends on model capability, permissions and source quality. High-impact decisions and sensitive processes may require additional human, legal or domain review.
Related service

Need a task-specific assistant with clearer boundaries?

See the AI Agents & Custom Assistants service for role design, tools, output formats, testing and handover.

View agent & assistant service View pricing