What Matters
A founder can organise research, sales, delivery, finance and support around AI-assisted workflows while remaining the approval point for all five. That creates a capacity constraint: faster drafts can produce more work to review. DN’s planning model makes that workload, retry exposure and operating cost explicit. Its scenarios are authored examples, not evidence that five autonomous agents can run a profitable company.
Build five work contracts around one accountable owner
The operating question is what happens between a request arriving and a result the business can accept. A research draft may inform an offer; the offer creates a delivery obligation; delivery creates an invoice and future support work. These dependencies survive even when software produces the intermediate documents.
DN’s earlier one-person business guide covers choosing a service, developing a trust channel and establishing payment foundations. This blueprint addresses the next layer: coordinating the resulting work without losing control of commitments, costs or the founder’s time.
Five roles describe functions, not a requirement to buy five products or deploy five autonomous agents. One application may support several roles; a deterministic rule may handle part of a role. Anthropic distinguishes predefined workflows from agents that dynamically choose their steps, and describes programmatic gates and human checkpoints. The appropriate degree of autonomy depends on the task. [1]
For each workflow, write a contract covering its inputs, proposed output, permitted actions, acceptance test and accountable approver. A shared instruction to “help run the company” leaves those decisions unresolved.
| Role and work product | Permitted activity | Owner’s approval | Acceptance check |
|---|---|---|---|
| Research: a sourced brief from an approved question and source set | Read permitted sources, record dates and draft findings with unresolved questions. | Approve material claims before they support a customer promise or published statement. | Claims match cited evidence; uncertainties and source dates remain visible. |
| Sales: a proposed response or offer from approved customer records and terms | Prepare meeting notes, draft follow-ups and identify missing information. | Approve recipients, pricing, commitments and any outbound communication. | The offer matches current terms, customer context and delivery capacity. |
| Operations and delivery: a draft deliverable from an agreed brief | Prepare working files, run allowed checks and propose status updates. | Approve final delivery, scope changes and edits to authoritative records. | The agreed specification is met; source material, version and outstanding issues are retained. |
| Finance: an invoice or reconciliation proposal from approved records | Extract fields, compare records and flag exceptions using restricted access. | Approve ledger changes, bank-detail changes and any movement of money separately. | Identity, amount, currency and references reconcile against the originals. |
| Support: a draft answer or escalation from a case and approved policy | Retrieve relevant guidance, assemble the case history and propose a response. | Approve sending, exceptions, refunds and consequential account changes. | The answer is supported, the promised action is authorized and the final case state is evidenced. |
Keep the authority boundary outside the conversation
A workflow needs access proportionate to its contract. Drafting a support response does not require permission to issue refunds. Preparing invoice fields does not require payment credentials. Restrict the connected accounts and tools, rather than depending on the model to remember a prohibition.
OWASP’s excessive-agency guidance recommends limiting functions and permissions, requiring approval for high-impact actions and enforcing authorization downstream. Monitoring and rate limits are additional controls; they do not make unrestricted access appropriate. [2]
An approval request should show the proposed effect, its source and the affected recipient or record. Bind approval to that specific proposal. If a price, amount, destination or scope changes afterward, return the revised proposal for review. A general permission to use a tool cannot settle every decision the tool exposes.
Define what happens when the founder is unavailable. A queue can wait, a routine draft can remain unsent, or a case can follow an agreed escalation path. The system should not infer broader authority from the absence of a response.
The founder’s review queue is a shared resource
All five workflows can draw on the same human attention. Research needs verification, sales needs commitment checks, delivery needs quality review, finance needs reconciliation and support needs exception decisions. Increasing output in one role can therefore delay decisions in another.
Budget for routine review, correction and exceptions separately. A short average review time can hide a small number of cases that consume most of an afternoon. Include the work needed to reconstruct context when an approval arrives without its source material or when several attempts produce conflicting records.
Compare required owner time with the time actually reserved for these activities. Capacity available for review excludes hours already committed to meetings, specialist work or other obligations. An apparently affordable software setup can exceed that remaining time budget.
The bottleneck is a modeling inference, not a measured finding about every solo business. A scenario with more required review time than the available budget is a prompt to reduce workload, simplify the contract or change the operating arrangement. It is not evidence that every item will eventually be completed by working faster.
Use the Agent Team Cost and Capacity Planner
The on-page scenario planner compares 27 combinations: incoming demand of 50, 100 or 200 weekly items; Lean, Planning or Surge assumptions; and an owner-time budget of 10, 15 or 25 hours. These are selectable presets. Work items are not interchangeable customers. The downloadable package includes an editable HTML planner for your inputs.
For every 100 incoming items, the authored role mix is 10 research, 20 sales, 20 operations/delivery, 10 finance and 40 support. Every item receives an initial attempt, and a profile-specific fraction receives one retry. The maximum of two attempts per item is a modeling assumption; this planning tool does not run workflows or enforce a real billing limit.
The Planning profile assumes a 25% retry share, a 10% exception share and 90% final acceptance. At 100 items, that produces 125 modeled attempts, 90 planned accepted outcomes and 10 unfinished items. Acceptance is a separate assumption, not a success rate inferred from retries.
Routine review takes 10.42 modeled hours, exception handling 2.80 hours and fixed operations two hours: 15.22 hours per week, slightly above a 15-hour allocation. At the same demand, Lean requires 10.275 hours and Surge 27.75 hours. These conditional calculations do not measure a real founder’s workload. An overloaded plan cannot turn its assumed acceptances into promised throughput.
View all 27 scenario results and cost-per-planned-acceptance ratios
All rows are included in this page. The 12 cases within budget and 15 cases above budget describe this authored grid, not an industry sample. Accepted and unfinished counts are independent planning assumptions. For overloaded plans, acceptance is unrealized; unfinished counts do not include additional capacity backlog. Cost ratios divide monthly cost by planned monthly acceptances. The final column is conditional on fixed volume, unit costs and two attempts; it is not an enforced bill cap.
| Profile | Incoming/week | Owner budget h/week | Required h/week | Owner-time status | Capacity incoming/week | Attempts/week | Planned accepted / unfinished per week | Software CU/month | Owner-time value CU/month | Full cost CU/month | Software CU/planned accepted item | Full CU/planned accepted item | Conditional two-attempt software CU/month |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Lean | 50 | 10 | 6.14 | Within budget | 96 | 55 | 47.5 / 2.5 | 291.76 | 1,063.83 | 1,355.59 | 1.417 | 6.586 | 366.83 |
| Lean | 50 | 15 | 6.14 | Within budget | 157 | 55 | 47.5 / 2.5 | 291.76 | 1,063.83 | 1,355.59 | 1.417 | 6.586 | 366.83 |
| Lean | 50 | 25 | 6.14 | Within budget | 277 | 55 | 47.5 / 2.5 | 291.76 | 1,063.83 | 1,355.59 | 1.417 | 6.586 | 366.83 |
| Lean | 100 | 10 | 10.28 | Exceeded | 96 | 110 | 95 / 5 | 383.52 | 1,781.00 | 2,164.52 | 0.932 | 5.258 | 533.67 |
| Lean | 100 | 15 | 10.28 | Within budget | 157 | 110 | 95 / 5 | 383.52 | 1,781.00 | 2,164.52 | 0.932 | 5.258 | 533.67 |
| Lean | 100 | 25 | 10.28 | Within budget | 277 | 110 | 95 / 5 | 383.52 | 1,781.00 | 2,164.52 | 0.932 | 5.258 | 533.67 |
| Lean | 200 | 10 | 18.55 | Exceeded | 96 | 220 | 190 / 10 | 567.03 | 3,215.33 | 3,782.37 | 0.689 | 4.594 | 867.33 |
| Lean | 200 | 15 | 18.55 | Exceeded | 157 | 220 | 190 / 10 | 567.03 | 3,215.33 | 3,782.37 | 0.689 | 4.594 | 867.33 |
| Lean | 200 | 25 | 18.55 | Within budget | 277 | 220 | 190 / 10 | 567.03 | 3,215.33 | 3,782.37 | 0.689 | 4.594 | 867.33 |
| Planning | 50 | 10 | 8.61 | Within budget | 60 | 62.5 | 45 / 5 | 304.27 | 1,492.11 | 1,796.38 | 1.560 | 9.212 | 366.83 |
| Planning | 50 | 15 | 8.61 | Within budget | 98 | 62.5 | 45 / 5 | 304.27 | 1,492.11 | 1,796.38 | 1.560 | 9.212 | 366.83 |
| Planning | 50 | 25 | 8.61 | Within budget | 174 | 62.5 | 45 / 5 | 304.27 | 1,492.11 | 1,796.38 | 1.560 | 9.212 | 366.83 |
| Planning | 100 | 10 | 15.22 | Exceeded | 60 | 125 | 90 / 10 | 408.54 | 2,637.56 | 3,046.10 | 1.048 | 7.811 | 533.67 |
| Planning | 100 | 15 | 15.22 | Exceeded | 98 | 125 | 90 / 10 | 408.54 | 2,637.56 | 3,046.10 | 1.048 | 7.811 | 533.67 |
| Planning | 100 | 25 | 15.22 | Within budget | 174 | 125 | 90 / 10 | 408.54 | 2,637.56 | 3,046.10 | 1.048 | 7.811 | 533.67 |
| Planning | 200 | 10 | 28.43 | Exceeded | 60 | 250 | 180 / 20 | 617.08 | 4,928.44 | 5,545.53 | 0.791 | 7.110 | 867.33 |
| Planning | 200 | 15 | 28.43 | Exceeded | 98 | 250 | 180 / 20 | 617.08 | 4,928.44 | 5,545.53 | 0.791 | 7.110 | 867.33 |
| Planning | 200 | 25 | 28.43 | Exceeded | 174 | 250 | 180 / 20 | 617.08 | 4,928.44 | 5,545.53 | 0.791 | 7.110 | 867.33 |
| Surge | 50 | 10 | 14.88 | Exceeded | 31 | 75 | 37.5 / 12.5 | 325.12 | 2,578.33 | 2,903.46 | 2.001 | 17.867 | 366.83 |
| Surge | 50 | 15 | 14.88 | Within budget | 50 | 75 | 37.5 / 12.5 | 325.12 | 2,578.33 | 2,903.46 | 2.001 | 17.867 | 366.83 |
| Surge | 50 | 25 | 14.88 | Within budget | 89 | 75 | 37.5 / 12.5 | 325.12 | 2,578.33 | 2,903.46 | 2.001 | 17.867 | 366.83 |
| Surge | 100 | 10 | 27.75 | Exceeded | 31 | 150 | 75 / 25 | 450.25 | 4,810.00 | 5,260.25 | 1.385 | 16.185 | 533.67 |
| Surge | 100 | 15 | 27.75 | Exceeded | 50 | 150 | 75 / 25 | 450.25 | 4,810.00 | 5,260.25 | 1.385 | 16.185 | 533.67 |
| Surge | 100 | 25 | 27.75 | Exceeded | 89 | 150 | 75 / 25 | 450.25 | 4,810.00 | 5,260.25 | 1.385 | 16.185 | 533.67 |
| Surge | 200 | 10 | 53.50 | Exceeded | 31 | 300 | 150 / 50 | 700.50 | 9,273.33 | 9,973.83 | 1.078 | 15.344 | 867.33 |
| Surge | 200 | 15 | 53.50 | Exceeded | 50 | 300 | 150 / 50 | 700.50 | 9,273.33 | 9,973.83 | 1.078 | 15.344 | 867.33 |
| Surge | 200 | 25 | 53.50 | Exceeded | 89 | 300 | 150 / 50 | 700.50 | 9,273.33 | 9,973.83 | 1.078 | 15.344 | 867.33 |
The inputs and arithmetic are visible
All inputs below are authored and fictional. Routine review occurs on every attempt. Rescue is incremental time once per exception item; exceptions and retried items may overlap. The profile multiplier applies to routine review only. Final acceptance is assumed independently after all handling.
| Role | Items per 100 | CU per attempt | Routine review minutes per attempt | Extra rescue minutes per exception |
|---|---|---|---|---|
| Research | 10 | 1.20 | 6 | 20 |
| Sales | 20 | 0.25 | 4 | 15 |
| Operations | 20 | 0.80 | 10 | 30 |
| Finance | 10 | 0.15 | 4 | 10 |
| Support | 40 | 0.10 | 3 | 12 |
| Profile | One-extra-attempt share r | Exception share e | Final acceptance share a | Routine-review multiplier m |
|---|---|---|---|---|
| Lean | 10% | 5% | 95% | 0.75× |
| Planning | 25% | 10% | 90% | 1× |
| Surge | 50% | 25% | 75% | 1.5× |
The fixed mix gives weighted inputs of 0.385 CU per attempt, 5 routine minutes per attempt and 16.8 rescue minutes per exception. Every plan includes two fixed maintenance hours/week and 200 fixed software CU/month. Owner time is valued at 40 CU/hour, as a noncash opportunity valuation. A month uses 52 ÷ 12 weeks.
Let N be weekly incoming items and B the weekly owner-hour budget; r, e, a and m are the profile inputs above.
- Weekly attempts = N × (1 + r). Planned weekly accepted items = N × a; planned unfinished = N × (1 − a).
- Routine hours = N × (1 + r) × 5 × m ÷ 60. Rescue hours = N × e × 16.8 ÷ 60. Total owner hours H = routine + rescue + 2.
- Monthly software S = 200 + [N × (1 + r) × 0.385 × (52 ÷ 12)]. Owner-time value = H × (52 ÷ 12) × 40. Full modeled cost = S + owner-time value.
- Planned monthly accepted items = N × a × (52 ÷ 12). Each cost-per-planned-accepted ratio divides the corresponding monthly cost by that denominator.
- Incoming capacity = floor[max(0, B − 2) ÷ ((H − 2) ÷ N)]. A plan exceeds its budget when unrounded H > B; an exact fit leaves no time reserve.
- Conditional two-attempt software amount = 200 + [N × 2 × 0.385 × (52 ÷ 12)]. It assumes fixed workload, scope and unit costs, and is not an enforced bill cap.
Capacity holds the mixed workload and profile constant; it is not a queue or deadline model. No accepted output is observed. In the editable download, zero demand leaves fixed maintenance and software costs; per-accepted costs and demand-based capacity are unavailable when their denominators are zero. The on-page presets do not change billing settings, permissions or real workflow limits.
Start with a workflow whose acceptance check and recovery route are clear. DN’s 50-process small-business readiness framework provides a shortlist and distinguishes initial pilots from work needing stronger controls.
Bound retries around the business operation
Specify an attempt limit, an operating-cost ceiling and the condition that stops further automated work. A stopped run should retain enough context for the owner to determine what completed and what remains unresolved. Unlimited retries turn a bounded task into an open-ended claim on time and spending.
Retries also have effects beyond cost. AWS’s Builders’ Library explains how a lost response can leave the caller uncertain whether an operation completed. A retry can duplicate an effect unless the service supports an appropriate idempotency contract. Caller-provided identifiers, retention and parameter handling matter; an identifier alone does not create universal exactly-once execution. [3]
Preserve the original operation identity and reconcile destination records before authorizing a replacement when the outcome is uncertain. A second draft is often easy to discard. A second customer message, booking or payment can require a separate corrective action.
Check how the chosen runtime counts attempts and restarts. AWS Step Functions, for example, defines configurable retry limits and backoff, but a redrive can reset retry counters for relevant states. That platform-specific behavior illustrates why a per-step retry setting should not be assumed to enforce a lifetime budget for the business operation. [4]
Carry the business-level budget and unresolved state across any restart. When the budget is exhausted, route the case for a decision instead of silently creating a fresh operation with a fresh allowance.
Keep operating cost, accepted output and profit separate
Record cash spending on software, model usage, connected tools and other incremental services. Report the owner’s review and exception time alongside it. Valuing that time can support an economic comparison, but it does not turn the valuation into a cash invoice. Keep the two views labeled.
The fictional 100-item Planning case models 408.54 currency units of software cost per month, including 200 fixed units and usage converted at 52 weeks ÷ 12 months. Valuing owner time at 40 units per hour adds 2,637.56, bringing full modeled cost to 3,046.10. These are invented consistent-currency inputs, not provider prices or actual bills.
Cost per accepted outcome needs an explicit numerator and denominator. State whether the cost includes retries, rejected work, review and corrections, and count only outputs that pass the declared acceptance standard. When there are no accepted outcomes, a finite unit-cost estimate is unavailable.
An accepted research brief or checked draft is not automatically a sale. Profit also depends on demand, pricing, delivery obligations, variable business expenses and the portion of output a customer actually pays for. The planner does not establish those commercial facts by calculating workflow costs.
Time saved can improve capacity without reducing spending. Avoid valuing every freed hour at a billing rate when that hour is neither sold nor used to avoid a real expense. DN’s industry ROI framework separates capacity from realised financial value and makes the required assumptions visible.
Make the operating record usable when work stops
Maintain a compact queue with the task ID, workflow owner, requested outcome, source references, current state and next permitted action. Keep routine reviews separate from unresolved exceptions so neither category disappears inside a general inbox.
At each handover between roles, carry the accepted version and remaining obligations. Sales should not treat an unapproved research draft as verified evidence. Finance should not infer delivery acceptance from a workflow’s “complete” message. Support needs the actual customer commitment and the destination system’s state.
Review the queue and its costs at a frequency appropriate to the commitments being made. A useful stop procedure pauses new actions, preserves records and leaves a named person able to resume the existing process. A complicated agent arrangement with no workable fallback can consume the capacity it was intended to release.
Download the scenarios and editable planner
The CSV contains all 27 authored scenarios. The reproducibility package contains the standalone editable HTML planner, role inputs, assumptions, methodology, Python generator and review evidence.
Open agent-team-cost-and-capacity-planner.html locally to change the supported demand, profile, budget and cost inputs. To reproduce the 27 locked scenarios with Python 3’s standard library, extract the package and run:
python3 build_model.py --output reproduced-resultsA separate assistant consistency and arithmetic review passed for all 27 scenarios. This confirms calculations against the authored assumptions; it is not an external expert review or validation of business performance. The source files and model-review-report.json record the scope and limitations.
Frequently asked questions
Does this blueprint require five autonomous agents?
No. The five roles describe business functions. They can use a mixture of ordinary software, deterministic rules, AI assistance and bounded agent workflows. The founder retains the stated approval responsibilities.
Has DN measured a real one-person company running this setup?
No. This release uses authored scenario planning and has zero measured deployments. Its calculations do not establish production performance, hours saved, profitability or a typical founder workload.
Why can faster generation make the business harder to operate?
Additional drafts can create more verification, approval and exception work. If that demand exceeds the owner’s available review time, the queue can grow even when the software produces outputs quickly.
Can I give every workflow the same account access?
Access should match each work contract. A research or drafting task generally does not need authority to send messages, move money or change account rights. Enforce consequential permissions in the connected systems.
Does a retry limit prevent duplicate business actions?
No. It bounds attempts under the runtime’s rules. Avoiding duplicate effects also depends on operation identity, the destination’s idempotency contract and reconciliation when the previous outcome is uncertain.
Is cost per accepted output the same as profit?
No. It is a workflow efficiency measure with a defined cost boundary. Profit also requires revenue and the other costs of delivering the business’s obligations, which the planner cannot verify.
What should happen when the founder is unavailable?
Follow the pre-agreed waiting or escalation path. Preserve the proposal and its evidence. An unanswered approval request should not be interpreted as permission to make a broader commitment or take a consequential action.
Can the planner tell me how many customers I can serve?
Only as a conditional planning exercise after customer work is mapped to the model’s assumptions. Real capacity also depends on task mix, variability, deadlines, quality requirements and other demands on the owner.
Method, limitations and disclosure
DN authored the workflow contracts and planning scenarios with AI assistance. All default workload, cost, review-time and exception inputs are assumptions unless explicitly identified as measured. Reproducible arithmetic checks consistency with those assumptions; it does not validate their realism.
The model cannot establish demand, quality, legal compliance, safe permissions or recovery in a live system. Workloads can vary, dependencies can block progress and failures can be correlated. Review any conclusion after changing the task definition, tool, model, operating contract or acceptance rule.
No affiliate offer or paid product ranking appears here. Send corrections through the DN contact page, identifying the scenario, workflow or source and supplying non-sensitive evidence. The 2027 URL is an editorial series label; the research and verification date is 22 October 2026 (SAST).
Primary sources
- Anthropic: Building effective agents, 19 December 2024 — workflow architecture, gates and human checkpoints; vendor engineering guidance.
- OWASP: LLM06:2025 Excessive Agency — functions, permissions, approvals and downstream authorization.
- AWS Builders’ Library: Making retries safe with idempotent APIs, Malcolm Featonby — uncertain outcomes and service-specific idempotency contracts.
- AWS Step Functions: Handling errors — retry limits, backoff and redrive behavior; platform-specific documentation.
About the Author
