A product team wants an agent that helps finance collect overdue invoices. Finance already has an invoice database, a CRM, an email service, and people doing the work. The first decision is which part of that work deserves an agent.
A useful first release might prepare reminders for review. The finance lead can inspect the invoices, recipients, and messages before sending. Autonomous collections, credit decisions, and negotiating payment terms can wait.
The launch deliverable is one complete job: a person requests work, reviews the proposal, gets a checked result, and can find the result later. The steps below are a practical sequence for building that job. The invoice workflow is an illustration, not a report about a vendor’s product.
Choose the first job from actual work
Export recent cases from support, operations, or the product’s own activity history. Keep the original request, the actions a person took, and the eventual result. Include abandoned requests and jobs handled through spreadsheets; chat history alone misses both.
Group cases by the result someone wanted. “Explain this invoice,” “correct the billing contact,” and “send a reminder” need different tools and permissions. Count recurring work across customers, then inspect the exceptions that make the work difficult.
The first job should combine meaningful demand, accessible data, a checkable result, and a manageable consequence. A team that cannot confirm the right recipient should solve contact selection before giving the agent a sending tool. Prioritize tools from historical cases includes a labeling sheet and a worked backlog.
Write a short release brief:
| Decision | Invoice example |
|---|---|
| Person and job | Finance lead prepares reminders for overdue, undisputed invoices |
| Eligible work | One workspace, approved customer contacts, invoices still unpaid |
| First result | A reviewed set of messages, then a per-invoice sending receipt |
| Outside the release | Changing balances, issuing refunds, contacting disputed accounts |
| Quality check | Correct invoice, contact, amount, and no duplicate reminder |
| Business question | Does the workflow reduce active finance effort at the same quality? |
| Owner | Finance owns the result; billing engineering owns the operation |
Make the product the harness
The harness is the product around the model: context, permissions, review screens, execution, history, and recovery. Tight coupling means the agent uses the product’s real objects and services. Coupling does not require putting business logic in the model prompt.
For the invoice job, the product supplies a workspace, selected invoice IDs, current balances, contact roles, and the rule for prior reminders. The model can propose wording and decide which approved tools help. The billing service remains responsible for reading invoices and applying changes.
A practical division looks like this:
| Layer | Responsibility |
|---|---|
| Product context | Resolve the selected workspace and objects; retrieve only accessible data |
| Agent loop | Interpret the request, ask about gaps, choose tools, prepare a proposal |
| Operation service | Validate arguments, authorize the actor, enforce limits, execute once |
| Review surface | Show the saved proposal and the consequence of accepting |
| Job store | Keep progress, pending decisions, cancellations, and receipts |
| Evaluation and analytics | Check output quality and measure the cost of the whole job |
Native UI, a scheduled rule, and an MCP client should reach the same operation service. A permission check hidden in a React button will not protect a background worker.
Build a narrow tool set and a repeatable skill
Start with the tools the first job needs: list eligible invoices, read an invoice, find an approved contact, prepare a reminder, and commit an approved send. Each tool should return enough structured detail for the next decision.
The agent’s skill describes the procedure: inspect disputes, confirm unpaid status, use the approved contact, draft a reminder, and ask before sending. A skill supplies instructions. The operation service supplies authority. Skills and a shared capability platform explains ownership, versions, and rollout controls.
Choose an agent framework after deciding which state must survive a restart. A quick model loop and a workflow waiting two days for approval have different runtime needs.
Design review and authorization together
Save an exact proposal before showing a tool call card. The proposal names the invoice IDs, recipients, messages, acting connection, and expiration. The card renders that proposal; the backend commits the same proposal.
Finance should see the recipients and message text before sending. A total such as “12 reminders” needs an expandable list. Sending email cannot be undone by deleting a CRM note. The review card should say which effects cannot be reversed. Designing approvals covers the card, stale selections, and bulk operations.
Approval answers whether someone agreed to the work. Authorization answers whether the actor may perform the work now. Check both again when the effect happens, including after a long wait.
Keep background work visible
Create a job ID before starting work. The job records preparation, pending review, execution, partial completion, and failure. Closing a browser should detach the viewer from the job, not silently lose or duplicate the job.
A stream reports progress to the current viewer. A persisted event log lets a returning viewer recover that progress. The job history should open from the invoice screen as well as the conversation. Runtime design covers retries, ownership, and unknown outcomes.
Proactive runs can prepare proposals under a written rule. A mobile push should open the saved proposal after a fresh access check. Mobile review and proactive notifications follows the path from trigger to receipt.
Launch with operations and measurement attached
Run historical cases without writes first. Compare selected invoices, contacts, messages, and exclusions with human-reviewed answers. Reserve recent cases for a final check after tuning. Include negative cases: paid invoices, disputes, revoked access, duplicate events, and expired approvals.
Next, run a bounded pilot with proposals reviewed by finance. Track manual effort, review effort, corrections, delivery results, and unknown outcomes. Set the acceptable limits with finance before seeing the results. The BizOps scorecard provides the event fields and comparison method.
A launch checklist should name the operational owner, pause control, alert destinations, support escalation, and recovery procedure. An agent release also needs a way to disable one broken capability while leaving useful read-only work available.
Read the guides in order
- Prioritize tools from historical cases: choose useful work and identify missing tools.
- Choose an agent framework: compare the loop, state, and deployment responsibilities.
- Authorization for product agents: define actors and enforce scope at execution.
- Designing approvals: expose exact changes, bulk scope, and irreversible effects.
- Skills and a shared capability platform: let multiple teams contribute without conflicting rules.
- Mobile review and proactive notifications: deliver useful interruptions and durable decisions.
- The BizOps scorecard: compare checked results and total effort.
The interactive copilot, support, and back-office playbooks add cost models and copyable specifications for each kind of job.