The New Product Paradigm: exercises

The right answer is: do not expand yet, but use the request to accelerate the path to expansion.

The 81% resolution rate is below the 90% bar you set for expanding scope. Outcome pricing still works at 81% (you only bill resolved invoices), but each unresolved invoice is work the customer's team still does. If you expand into a new, higher-variance workflow now, you will depress resolution rate on both workflows simultaneously, compromise the core product's reliability, and have a worse investor story in 5 months, not a better one.

What to do instead:

1. Tell the customer: "We'll build PO matching, and here's the timeline, but we go into it only when billing reconciliation is at 90%+. That's the standard we hold ourselves to so you can trust the product." This is a strong answer because it demonstrates product discipline, not weakness.
2. Use the next 6 weeks to aggressively close the 81% → 90% gap: analyze the 19% that isn't resolving, identify the top 3 failure patterns, fix them. This is also the eval work you'll need for PO matching anyway.
3. For the investor: "We have a signed expansion LOI from our largest customer contingent on hitting our 90% resolution threshold, which we're targeting in 8 weeks." That is a better growth metric than premature scope expansion with declining reliability.

The wrong move: expand because the customer is large. Customer size is not a substitute for product readiness. A failed expansion into PO matching with your largest customer costs more than a delayed expansion.

Self-assessment checklist:

• Did you resist expansion pressure from a large customer without meeting the reliability threshold?
• Did you identify the 81% → 90% gap as the highest-leverage work before expansion?
• Did you reframe the investor conversation around a credible near-term milestone rather than premature growth metrics?

The honest answer to "feature or moat?" is: at 71% resolution rate with no eval corpus, no domain SOP capture, and no workflow position beyond Zendesk integration, you are closer to a feature. But you have the raw materials to become a moat in 90 days if you move on the right things.

What LabAgent cannot replicate in 90 days:

• Your labeled outcome dataset from 300 customers' support workflows (every resolved/unresolved ticket is training data)
• Your customer-specific SOP knowledge (what "resolved" means for a fintech customer vs. an e-commerce customer vs. a healthcare SaaS)
• The eval corpus you've been building implicitly through production usage

What to build in 90 days:

1. Formalize the eval corpus: label your existing resolution data by workflow type, ticket complexity, and failure mode. This is the asset LabAgent doesn't have for your specific customers.
2. Fine-tune a smaller model on your domain corpus. Target: match 71% resolution rate at 80% lower inference cost. This is your margin moat.
3. Launch per-customer resolution benchmarks. Your 14-month customers should have resolution rate trends, not just current rate. Show compounding improvement. That's the story LabAgent cannot tell about your customers.

The $50/seat vs. $0.99/resolution comparison is actually in your favor once outcome pricing is understood. For a support team resolving 2,000 tickets/month where 71% resolve without a human, your cost is about $1,406/month (2,000 × 71% × $0.99) vs. LabAgent at $50 × (size of team). For a 40-person support team, LabAgent at $2,000/month is about 42% more expensive with no resolution guarantee.

Self-assessment checklist:

• Did you identify the specific assets (eval corpus, SOP capture, domain data) that are hard to replicate quickly?
• Did you propose concrete work for the 90-day window rather than defensive positioning?
• Did you correctly frame the pricing comparison in terms of outcomes, not seats?

The CTO is most right, the CFO is defending a false stability, and the Head of Sales is raising a real objection that has a solvable answer.

The CFO's mistake: 54% gross margin on average masks the fact that your highest-value customers (largest teams, most engaged) are your most expensive. As these customers grow, your costs grow, your revenue stays flat. This is the seat-pricing trap in slow motion. The 54% margin is already declining if large customers are your fastest-growing segment.

The Head of Sales' objection is real but solvable: "Customers can't predict their bill" is the most common objection to outcome pricing. The answer is hybrid pricing: $500/month platform fee (predictable base) + $0.90/resolution above 500 resolutions/month. The floor makes the bill predictable. The variable component captures upside as usage scales. CIOs can budget for it.

The CTO is pointing at the most important issue: Without outcome-labeled data, you cannot build the eval corpus that enables model fine-tuning, which is the path to higher resolution rates and lower inference costs, which is the path to 60%+ gross margin at scale. The current pricing model actively prevents you from building your moat.

Transition plan: announce pricing change 90 days out. Grandfather existing customers at a hybrid model. Capture resolution labeling data from day 1 of the new model. Use the 90-day runway to build the outcome-data pipeline before it's operationally required.

Self-assessment checklist:

• Did you identify that the current model's "good margin" is a lagging indicator, not a leading one?
• Did you propose a hybrid model to address the predictability objection?
• Did you connect outcome pricing to eval corpus capture as the data flywheel mechanism?

The 67% plateau is a data problem, not a model problem. Here's the diagnostic framework:

Step 1: Segment the 33%. Break the non-resolutions into categories: (a) the agent attempted and failed (produced an answer the customer rejected or escalated), (b) the agent did not attempt (routed to a human immediately), (c) the agent produced no answer (explicit uncertainty). Each category has a different root cause and fix.

Step 2: Find the top 3 failure patterns. In a typical support workflow, 3 failure categories account for 80%+ of non-resolutions: missing documentation coverage (customer asked about a feature with no help article), ambiguous question routing (the agent couldn't classify the intent correctly), tool call failure (the agent needed to look up an account but the API call failed or returned an unexpected schema).

Step 3: For each category, the fix is different:

• Missing documentation: this is a content gap, not an AI gap. Build the missing articles. Resolution rate will improve automatically.
• Routing failure: add example conversations to the routing classifier. Fine-tune on 20–50 examples per failure class.
• Tool call failure: add schema validation and better error handling. Log and alert on failed tool calls separately.

Step 4: Track leading indicators. Resolution rate is a lagging indicator. For each fix, track a leading indicator that shows impact before resolution rate catches up: coverage rate (% of intents with at least one help article), routing accuracy (% correctly classified), tool call success rate.

The 90% ceiling for most support agents is not about model capability. It is about documentation coverage and routing precision. Both are solvable with non-ML work.

Immediate response (first 10 minutes):

1. Kill switch: disable the refund agent immediately via the feature flag. Not "pause": disable. Every minute of delay is additional refund exposure.
2. Assess reversibility: contact the payment processor to find out which of the $83,400 in refunds are still pending and can be canceled. Many processors cannot reverse a refund once it has been submitted to the card network, so move fast and assume some of it is unrecoverable.
3. Scope the damage: query the full execution log for all refunds processed since 2:15am. You need a complete list before you can communicate with customers or finance.

Next 50 minutes: 4. Root cause hypothesis: the "refund_pending" flag in the imported records was likely interpreted by the agent as a trigger for action. The agent's tool schema or routing logic did not distinguish between "this record historically had a pending refund" vs. "this record requires a refund action now." 5. Communicate: finance and customer success need to know within the hour. Never let them discover an incident through customer complaints.

Postmortem action items:

• Add schema validation for all new integration data before it reaches agent context. New data sources require explicit allowlisting, not implicit passthrough.
• Implement a rate limit circuit breaker: if refund volume exceeds 2x normal rate for more than 5 minutes, auto-pause and alert. This is a monitoring gap.
• Require human approval for bulk action triggers. Any agent action triggered by a bulk import should require an explicit approval step, not autonomous execution.
• Add the 47-refund execution traces to your failure eval dataset. These are high-signal negative examples that prevent the same failure mode from recurring.

The VP's math has three errors worth correcting.

Error 1: 70% resolution rate ≠ 50% headcount reduction. Resolution rate and headcount are not 1:1. Humans don't spend 100% of their time on resolvable tickets. They also handle escalations, QA of AI outputs, complex cases, and work the agent generated (follow-up tasks, account adjustments, process exceptions). A realistic productivity model suggests 70% resolution rate supports 20–30% headcount reduction in the first 12 months, not 50%.

Error 2: Headcount reduction has a risk profile. Laying off 600 support employees eliminates institutional knowledge, creates morale risk in the remaining team, and is irreversible if the agent underperforms. The AI agent can be turned off; the layoff cannot be undone. The option value of keeping human capacity while the agent matures is substantial.

Error 3: The comparison should be risk-adjusted. Assume (illustratively) that 1,200 agents handle about 40,000 tickets a day. At a 70% resolution rate that is about 28,000 AI resolutions a day, or roughly $10M a year at $0.99 each. Cost to maintain 600 support employees (fully loaded, $70K average): $42M a year. The question isn't "$0.99/resolution vs. $0". It is "about $10M/year that can be cancelled vs. a $42M/year saving that is hard to reverse if the agent underperforms."

The right recommendation: deploy the agent, reduce new hiring, reallocate existing headcount to higher-value work (QA, complex case handling, product feedback), and measure resolution rate improvement over 6 months before making irreversible headcount decisions.

The CTO is right, but the founder needs to be able to explain why to the investor in a way that doesn't sound like defensiveness.

Why the CTO is right: 74% resolution rate with no documented eval corpus, no domain SOP capture, and no published case studies is not a foundation for vertical expansion. Expanding into three new verticals simultaneously means three new failure surfaces, three new evaluation requirements, and diluted engineering focus. The likely outcome: 65% resolution rate across four verticals, no reference customer strong enough to close the next deal in any of them.

The asset the founder is undervaluing: 22 enterprise customers and 8 months of production data is a domain corpus, if it's been captured properly. The path to a credible Series B story is not TAM expansion. It is showing that this product compounds. Resolution rate improving from 74% to 85%+ over the next 6 months, with a published case study showing ROI, is worth more than theoretical TAM across 4 verticals.

How to frame it for the investor: "We're going deep before we go wide. Here's the bet: we get to 90% resolution rate in this vertical in the next 6 months, publish the case study, fine-tune a smaller model that gets us to 65% gross margins, and then we have a replicable playbook for vertical expansion, not a theory. The TAM story is the same; the execution risk is dramatically lower."

This is a better Series B story than "we're in four verticals" with mediocre metrics in all of them.

This is a real situation for many agentic AI products in 2026. The answer needs both honesty about the gap and a structured remediation plan, and it starts with getting the dates right.

Where the law stands (as of October 2026):

• The AI Act entered into force on 1 August 2024. The bans on prohibited practices have applied since February 2025, and general-purpose AI model obligations since August 2025.
• High-risk obligations for Annex III systems (which include recruitment and worker management) were due on 2 August 2026. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force 27 July 2026) moved that date to 2 December 2027. High-risk AI inside products already covered by EU product law (Annex I) moves to 2 August 2028.
• So this is not current non-compliance. It is a hard deadline about 14 months away, and EU customers' procurement teams will ask about it well before then.

What being a high-risk provider requires (Articles 9 to 17, 43 and 49): a risk management system, data governance for training and test data, technical documentation, automatic logging, transparency to the deploying customer, human oversight measures, accuracy and robustness testing, a quality management system, a conformity assessment, and registration in the EU database. For most Annex III systems, including employment, the conformity assessment is the provider's own internal check, not a third-party audit. Providers must keep the documentation for 10 years after the system is placed on the market. The Act does not require a named "responsible AI officer", but someone has to own this.

Timeline (realistic, illustrative):

• Weeks 1–2: Legal review to confirm the classification and the specific requirements for this use
• Weeks 3–10: Technical documentation (system design, data provenance, accuracy metrics, known limitations): slow if you have not been capturing it, fast if you have
• Weeks 8–20: Quality management system, logging, and human-oversight design; internal conformity assessment
• Before 2 December 2027: EU database registration and CE marking

Cost estimate (order of magnitude, illustrative; get real quotes):

• External legal: $50–150K
• Engineering for logging, documentation and oversight features: $50–150K
• Ongoing compliance ownership: 0.5–1 FTE

Board framing: "We have until 2 December 2027, and our EU customers will want evidence long before that. This is a 4–6 month, low-six-figure program. The penalty for breaching high-risk obligations is up to €15M or 3% of global annual turnover, whichever is higher (the €35M / 7% tier is for prohibited practices). The bigger near-term risk is losing the two EU accounts at renewal. We should start now."

Wedge selection: The worst first wedge is "help accountants prepare taxes": too broad, too seasonal, unclear verifiability. The best first wedge is the most repetitive, verifiable sub-workflow. In tax prep: document extraction and classification: taking the pile of documents clients submit (W-2s, 1099s, receipts, bank statements) and classifying, extracting, and organizing them into the right categories in the tax software. Score: Frequency (high during tax season, weekly during bookkeeping months), Pain (2–4 hours per client on average), Verifiability (correct category + extracted value, checkable against the source document), Tool access (QuickBooks, tax software APIs available), Reversibility (miscategorized documents are easy to correct before filing). Score on the Chapter 05 seven-dimension rubric: 6/7.

ICP: Not "accounting firms"; that's too broad. Target: accounting firms with 10–50 accountants, primarily small business clients ($200K–$5M revenue), using QuickBooks + Lacerte or Drake tax software, with a documented client document intake process. The system environment matters: the moat lives in the QuickBooks + Lacerte data shape, not in a generic document classifier.

Architecture:

• Tool layer: QuickBooks API, document storage (S3/GCS), tax software import API
• Context: per-client document history (what they submitted last year, what categories were used)
• Model routing: document classification → fine-tuned smaller model; anomaly detection → frontier model
• Eval: every extracted value is verifiable against the source document; build golden dataset from first 50 clients
• Human handoff: confidence below threshold triggers accountant review queue
• Observability: extraction accuracy per document type, correction rate by category

6-month metrics:

• Document processing time: baseline → 30-minute target per client
• Extraction accuracy: 95%+ on standard document types (W-2, 1099-NEC, 1099-DIV)
• Accountant correction rate: below 8%
• Gross margin: 55%+ (model right-sizing to smaller model after fine-tuning milestone)

This is a case where the technically impressive approach is likely the wrong one.

The cost of multi-agent coordination: Adding multiple specialized agents to replace a single agent with tool calls introduces: (a) coordination overhead: each inter-agent handoff is a new failure mode, (b) debugging complexity: a failure in a multi-agent workflow is dramatically harder to trace than a failure in a single-agent workflow with tool calls, (c) context fragmentation: each specialized agent sees only a subset of the session context, increasing the risk of lost information at handoff boundaries.

The resolution rate argument: The claim that multi-agent coordination will push resolution rate from 82% to 90% is speculative. The more likely path to 90% is: (a) analyzing the 18% non-resolutions to identify the top 3 failure categories, (b) fixing them with targeted data and prompt work, (c) fine-tuning a smaller model on the domain-specific failure dataset. This path is lower risk, lower engineering cost, and produces a better cost structure as a byproduct.

When multi-agent IS the right answer: Multi-agent coordination is justified when different workflow segments have fundamentally different context, tool sets, or model requirements that genuinely cannot be served by one agent, not when the single agent isn't performing as hoped. "It will get us to 90%" is not a valid architectural justification.

Recommendation: Reject the rebuild. Commit to a 60-day data-driven path to 90%: full failure analysis of the 18% non-resolutions, targeted fixes, eval measurement. If 90% is achievable by that path, you avoided 3–6 months of architectural risk. If it isn't, you now have real data showing what the architectural constraint actually is.