Skip to content
Yanyu Zhou
Portfolio
Case study 01Finance · HR · Legal · IT · Operations · Project Management

AI-Enabled Operations Layer

Turned operational knowledge that was concentrated in individual operators into a reusable internal AI support and execution layer.

Delivered · in use

Business value

Teams get answers and routine actions from specialized agents instead of waiting on one person — with approval gates wherever an action carries risk.

My role
Requirements gathering · Agent and permission design · Build and configuration · Testing and rollout · Ongoing routing review
Skills
  • Requirements gathering
  • Process mapping
  • Agent design
  • Access-control design
  • Project delivery
  • Change management
Built with
  • Collaboration platform
  • Native agent platform
  • LLM / coding agents
  • Browser automation
  • Rules-based automation

Confidentiality note. Company-specific data, configurations, workflows and diagrams in this case study have been anonymized and reconstructed for public presentation.

01

The request

From · Finance, HR, Legal, Operations and Project teams

Operational knowledge and routine execution across Finance, HR, Legal, Operations and Project Management depended on individual operators. To find information, interpret a process, retrieve a document, answer a recurring question or complete a follow-up action, employees asked a person.

  • Pain point 01

    The same questions were asked again and again — and answered by the same person.

  • Pain point 02

    Routine follow-up actions were done by hand.

  • Pain point 03

    Answers depended on who was available, not on a shared source.

02

What I built

  1. 01An Operations Orchestrator as the single front door
  2. 02Specialized agents by business area, plus one shared operations agent covering Finance, Legal, IT, HR and Operations
  3. 03A skill and tool layer for approved actions
  4. 04A controlled execution path, with human approval wherever an action carries risk
03

Try it — route a request

Pick a sample request and follow how the orchestrator handles it — from the front door to an answer, an action, or a person.

How to use
  • All requests are fictional examples.
  • Watch which requests are answered from knowledge, which run an approved skill, and which stop for a person.
  • Untick “approved to run actions” to see an action blocked.
1 · Pick a request
2 · Follow the route
  1. 01
    Front door
    Request arrives in the collaboration platform the team already uses.
  2. 02
    Orchestrator
    Classified as Finance → routed to the Shared operations agent.
  3. 03
    Path
    Knowledge retrieval over the agent’s approved sources.
  4. 04
    Answered from approved knowledge

    A lookup in approved policy documents. Reading carries no risk, so the agent answers directly with the source.

Simplified demo · fictional data · not the real system
04

How I thought about it

  1. 01

    Separate reading from acting

    Answering a question and taking an action carry different risk, so they run on different paths with different permissions.

  2. 02

    Specialized agents, not one agent for everything

    Each agent only sees the knowledge for its area. Answers stay grounded and exposure stays limited.

  3. 03

    Escalate instead of guess

    When sources disagree or a route is unclear, the request goes to a named owner.

05

How it was delivered

Run as a project: from the team’s request to something people use every day.

  1. 01
    Intake

    Mapped the recurring questions and routine tasks each team sent to operations.

  2. 02
    Scope & plan

    Split the work into agents by business area, defined which actions were in scope, and set the rollout order.

  3. 03
    Design

    Defined each agent’s knowledge, routing precedence, permissions, approval rules and escalation owner.

  4. 04
    Build

    Set up knowledge bases, shared instructions, approved skills and the separate execution path.

  5. 05
    Test & roll out

    Tested sample requests across every route and approval path, then released to allowlisted users.

  6. 06
    Iterate

    Routing quality and skill failures are reviewed on a recurring cadence and adjusted.

06

Result

BeforeOne operator retrieved information and ran routine tasks by hand
AfterRequests are routed to specialized agents with scoped knowledge and approved tools
BeforeOperational knowledge depended on specific people
AfterKnowledge is maintained as shared, approved agent knowledge
BeforeRisky actions relied on individual judgment in the moment
AfterSensitive actions stop for human approval; conflicts go to a named owner
Recurring requests are increasingly handled by specialized agents instead of waiting on one person, and the knowledge behind them no longer lives with individuals.
07Technical detailsFor the deeper read: How the orchestration works · How does the agent know? · How are models and tools used? · What remained controlled / human

How the orchestration works

  1. 01
    Request

    A request enters through the collaboration platform the team already works in.

  2. 02
    Route

    The Operations Orchestrator classifies it and routes it to the right specialized agent, following a defined precedence when a request touches more than one area.

  3. 03
    Answer or act

    The agent answers from its scoped knowledge, or calls an approved skill to act.

  4. 04
    Approve

    Actions that touch money, contracts, access or external parties stop for human approval.

  5. 05
    Escalate

    Unclear routes, conflicting information and skill failures go to a named human owner — never resolved by the agent — and are reviewed in a recurring routing report.

Two paths: knowledge retrieval and controlled execution
Path AKnowledge retrievalAnswers questions from approved sources
Who
Employees
Entry point
Operations Orchestrator
Delegates to
Specialized agents by business area
Team agent · area 1Team agent · area 2Team agent · area 3Shared operations: Finance · Legal · IT · HR · Ops
Scoped to
Approved data sources & tools
Path BControlled executionPerforms approved actions
Interface
Enterprise collaboration app
Gate
Authenticated bot
Approved users only (allowlist)
Reasoning
AI / coding agent layer
Can only call
Approved skills & tools
Where required
Controlled browser automation
Governance across both paths
  • Access scoped by use case
  • Allowlisted users for execution
  • Human approval for sensitive actions
  • Exceptions route to a person
Reconstructed, sanitized architecture. Agent names, platforms, identifiers and security configuration are omitted.

How does the agent know?

Each agent works from scoped operational knowledge rather than one unrestricted memory shared across every agent and every user.

  1. 01
    Persistent knowledge
    Approved policies, SOPs, templates and process documentation
    Curated in each agent’s knowledge base and updated when the source changes
  2. 02
    Fresh context
    Current operational information from approved business sources
    Refreshed from those sources rather than frozen at setup
  3. 03
    Task context
    Only what the current request needs
    Passed into execution per request — nothing broader
This is knowledge grounding and retrieval over approved sources — not model training.

Instruction layer: each agent has a defined role, scope, routing rules and escalation rules, and a team shares one set of instructions, skills and templates so behaviour stays consistent across users.

Design principle: one person’s conversations, client details or email content should never be exposed to another user.

How are models and tools used?

The architecture is intentionally model-agnostic: different models and execution methods are selected based on the task, rather than forcing every workflow through one agent platform.
Native agent platforminside the collaboration suite
Team-facing questions, internal knowledge retrieval and simple tasks
LLM / coding-agent layervia a custom app in the collaboration platform
Heavier reasoning, skills, coding and controlled multi-step execution
Browser automation
Third-party tools with no reliable native API or integration
Rules-based automation
Deterministic workflows that do not need AI
Human
Sensitive, ambiguous or high-risk decisions

The split came from testing: the native agent platform performed well at retrieving internal collaboration knowledge, but was limited when a workflow needed reliable interaction with third-party web tools — so execution runs on a separate, controlled path.

What remained controlled / human

  • Approval of sensitive actions — money, contracts, access and external commitments.
  • Resolving conflicting or ambiguous information, through a single escalation owner.
  • Reviewing routing quality and skill failures on a recurring cadence.
  • Deciding which skills an agent may call — agents do not improvise actions.