Choose a task unit before naming an enterprise Agent scenario
A viable scenario is not an industry label with a chat box. It needs bounded input, executable actions, human takeover, inspectable artifacts, and controls the current Harness can carry.
Task
Bounded, judgeable, and transferable on failure.
Composition
Expose only the minimum capabilities required.
Evidence
Validate with logs, artifacts, and human review—not demo impressions.
Choose a scenario to inspect its business trigger, recommended capabilities, control focus, deliverable, and maturity judgment. These are pilot compositions inferred from current mechanisms, not industry solutions shipped with the repository.
01
Software delivery and code governance
Business trigger
A request crosses code search, editing, tests, and review, forcing people to move context between tools.
A good pilot cannot be judged only by whether the answer “sounds right,” and it should not begin by spanning an entire department. Find one repeatable task unit, then determine whether the Harness can connect model intent, tool action, and business evidence.
Selection question
Good pilot signal
Defer signal
Can inputs be bounded?
Fixed material, repository, form, or request type
The target changes through ad hoc owner judgment
Can actions be encapsulated?
A small set of read-only or controlled-write tools
Manual desktop work with no stable interface
Can outcomes be checked?
Tests, field rules, citations, or a human acceptance sheet
Evaluation is only “it felt good”
Can risk be tiered?
Risky actions can be separately approved or disabled
One call mixes several irreversible operations
Can a person take over?
Failure context and artifacts can transfer to an operator
Nobody can determine what changed after failure
01
Business workflow
→
02
Bounded task unit
→
03
Known inputs
Allowed actions
Observable evidence
→
04
Agent preset
Approval and sandbox
→
05
Reviewed result
Scenario design from business workflow to reviewed result
Scenario 1: Software delivery and code governance
Suitable tasks. Repository questions, defect isolation, bounded edits, test execution, dependency-update explanation, and change review can advance through one session. Filesystem, shell, LSP, diff presentation, and session persistence already form a composition close to the main product path.
Pilot boundary. Select one repository and one change class, such as “fix a defect with stable reproduction.” Initially limit writes to the workspace, while deletion, external network, and publication remain human actions. Check results and patches are deliverables; the assistant summary is an index.
Validation evidence. Did the task produce a reviewable diff? Did relevant checks actually run? Does failure name the command and reason? Does refresh or recovery show the same tool trajectory?
Scenario 2: Knowledge research and document production
Suitable tasks. Internal and external research, policy or competitor review, meeting-material synthesis, and evidence-backed reports can compose web, filesystem, skills, and context compaction. The session log retains source paths and multi-pass revision context.
Pilot boundary. Fix the source scope, report structure, and citation requirements. Mark unverified facts explicitly. When internal sensitive material is involved, combine filesystem policy with deployment network controls. A business owner still reviews final publication.
Validation evidence. Can sampled conclusions return to primary sources? Do citations support the associated proposition? Do follow-up questions reuse context without rewriting confirmed facts?
Suitable tasks. Support assistance, order exceptions, operations configuration, and finance-material prechecks can enter the Harness through domain tools. The pipeline provides argument validation, policy, approval, execution, and result recording; client plugins can turn JSON into dedicated business cards.
Pilot boundary. Start with read-only queries and reversible actions. Write tools need business idempotency keys, caller identity, explicit approval copy, and failure compensation. The business system must provide those domain mechanisms; the Harness does not invent transaction semantics.
Validation evidence. Are unapproved actions never executed? Does the business API detect repeated requests? Can outcomes link approval records to source-system state? Do exceptions enter a human takeover queue?
Scenario 4: Research analysis and repeatable computation
Suitable tasks. Search, data cleanup, script computation, parallel questions, and long waits can use code runtime, workflows, background jobs, and subagents. Intermediate files and session events provide process evidence for findings.
Pilot boundary. Run trusted model-written scripts only, set time, memory, and tool limits, and fix input snapshots. The dynamic workflow worker/VM isolates the Host event loop; it is not a hostile-code security boundary. Use a separate process, container, or remote provider for untrusted code.
Validation evidence. Can the same input reproduce the main result? Are run parameters and intermediate artifacts retained? Does failure identify a step? Is restart correctly reported as non-resumable instead of pretending to recover?
Scenario 5: Enterprise Agent platform foundation
Suitable tasks. A platform team can use profiles, bundles, session presets, and capability seams to serve different Agents to business teams, then integrate through Web, CLI, ACP, and SDKs. The client plugin graph lets domain capability and settings UI ship together.
Pilot boundary. Support two clearly different Agents first, proving they share a runtime spine while receiving different tools and policies. Enterprise tenancy, unified identity, quotas, cost allocation, plugin signing, and release approval require external or new-plugin integration.
Validation evidence. Are tool sets truly separated? Does invalid composition fail during loading? Can models and credentials update without restarting the core process? Does automation stay within its published protocol scope?
Real product interface: a platform team can declare a custom model provider in settings, while credentials resolve through a separate capability instead of ordinary settings fields.
No completion definition exists; the request is only for an Agent to “run the business autonomously.”
One run crosses several irreversible systems without idempotency, approval, or compensation interfaces.
Untrusted code needs a security boundary, but the plan relies only on a worker/VM.
Value can be judged only through long-term revenue change, with no process metric or human baseline.
Evidence status: Confirmed against current source unless noted. Scenario compositions and pilot advice are application inferences that require real workflows, domain tools, and acceptance data.
