Agent Pilot Starter Kit: A Three-Table, Seven-Step Acceptance Method

After reading, you can get the task admission table, permission boundary table, and acceptance table, and use a seven-day pilot to determine which operations can be automated, require human approval, or must be disabled.

Author: Jinxue Studio · Guanshan Academy

Full text: approx. 3,261 characters · About 11-minute read

---

Recently, in discussions about AI agents, you often hear: models can write, retrieve, and call tools. But once they receive real tickets, problems appear immediately: Who authorizes them to change orders? How do you roll back a wrong answer? Which steps can only generate drafts?

This article does not talk about grand architecture. It only provides a pilot starter kit: three tables to close the scope of scenarios, seven days and seven steps to run through acceptance, so that business, technology, and operations can judge on the same basis what can be automated today and where human control must be enforced.

1. First decide whether to do it: three gaps in Agent pilots

Many teams start projects from model capabilities and first look for the most impressive tasks. A more stable approach is to reverse this: first look for business gaps. Gaps usually fall into three categories: slow information organization, heavy cross-system data movement, and rule-based judgments that are easy to miss. If an Agent only makes answers more fluent without changing process cost, it is not worth doing.

1. First choose high-frequency, low-damage, and verifiable tasks

Pilot tasks should ideally meet three conditions: high occurrence frequency, limited impact when errors occur, and results that can be judged with samples. Ticket summaries, document classification, and draft generation are suitable to start with; payment refunds, bulk price changes, and contract stamping are not suitable for the first batch.

You can use one sentence to filter: if this happens every day and a single error can be remedied quickly, it is suitable for a read-only pilot.

2. Every task must have inputs, outputs, and success conditions

Many projects get stuck because they can chat but cannot deliver, due to tasks lacking boundaries. You must clearly specify what the Agent inputs, outputs, what counts as passing, and where it falls back on failure.

Task example: first-screen summary of a customer ticket. Input = ticket number | user's original words | attachment list | historical interaction records; Output = three-line summary | to-do list | candidate risk-level values; Success = summary covers key demands, to-dos can be routed to the designated group, risk level can be counted; Failure = retain the original text, mark it as requiring manual initial screening, and do not generate an automatic reply.

If you cannot write a fallback for failure, the scenario is still too vague. Do not connect tools yet.

3. The first batch defaults to read-only or draft mode

Let the Agent produce candidates instead of directly changing live data. Read-only mode can see context, and draft mode can generate results that humans can edit. These two levels are suitable for building trust and also keep an entry point for accountability.

—— First close the scope, then grant authority

Illustration: Lake light at dusk

2. Three project initiation tables: turn scenarios into acceptable pilots

A pilot is not just opening a chat window. Before implementation, turn the scenario into three tables: the admission table decides what to do, the permission table decides what can be touched, and the acceptance table decides what counts as passing.

1. Task admission table

This table is suitable for business owners to fill out. The goal is to avoid trying to do everything.

• Task name: for example, after-sales ticket assignment suggestion.
• Frequency: high, medium, low. Only high frequency can easily create scale benefits.
• Impact scope: does it only affect internal processes, or does it touch customers, funds, and permissions?
• Rollback capability: can it be quickly remedied through drafts, cancellation, or manual override?
• Owner: who judges quality and who handles exceptions?

2. Permission boundary table

This table is maintained jointly by technology and security. The Agent cannot receive a universal key; instead, permissions must be graded by tool, field, and action.

Permission example: order after-sales scenario. Tools/APIs = order query interface | ticket creation interface | user notification interface; Read/write levels = order query read-only | ticket creation draft | user notification requires approval; Sensitive fields = phone number | address | refund reason | invoice information, masked by default; Approvers = after-sales supervisor or on-duty operations; Disabled items = automatic refunds | bulk price changes | deletion of original tickets | cross-tenant reads.

The principle is: read is broader than write, draft is broader than execution, and sensitive actions must have approvers and audit trails.

3. Acceptance table

The acceptance table divides results into three levels to avoid the launch meeting ending with only "looks good".

Do not guess the sample size. According to public materials and industry practice, the first batch can draw one batch each of normal samples, historical failure samples, and boundary samples; only after you can form reproducible pass rates, misjudgment types, and manual time costs should you talk about scaling.

—— Seven days is not a sprint; it is calibration

Illustration: Mountain color in morning mist

3. Seven-day pilot rhythm: from sandbox to controlled operation

Step 1: Build a task profile

Align business, technology, and operations, and confirm one main scenario. Do not do customer service, marketing, and R&D assistants at the same time. The deliverables for the day are drafts of the task admission table and permission boundary table.

Step 2: Run normal historical samples

Connect to masked historical data. First run common, complete, low-risk tasks to confirm that the Agent can output stable formats. In this step, do not chase impressive answers; chase reusable structure.

Step 3: Stress-test abnormal samples

Prepare for missing fields, garbled text, and overly long text.