Skip to main content

Bottega8 Executive AI Operating Advisor

Bring one AI decision. Leave with a plan you can challenge.

Pick the situation closest to yours, open ChatGPT or Claude, and answer up to five questions. You get a Decision Docket: a go/no-go recommendation, the operating diagnosis behind it, the size of system it actually needs, the unit economics and break-even, what your team must cover for your stage, a 30-day proof plan, and the questions your team must answer before production.

1Choose your decision

Tap the one closest to what you are facing.

2Open your advisor

Choose a service. The advisor setup is copied to your clipboard and a new chat opens. Paste it to begin.

Open in ChatGPT Open in Claude

Choose a decision above to enable the buttons.

Copy didn’t work? Show the advisor setup as text.

Tap inside the box, choose Select All, then Copy. Paste into a new chat.

Everything happens in your own ChatGPT or Claude account. This page sends nothing you type, paste, or receive to Bottega8. Use high-level or de-identified descriptions; do not paste customer records, patient data, credentials, source code, or board materials. The advisor’s output is a working hypothesis, not a security approval, diligence report, or regulatory conclusion.

3Keep your advisor

Your Decision Docket lives in the chat you just opened. To revisit it or push on it later, reopen that same conversation in ChatGPT or Claude. A fresh chat will not remember it; come back here and start again.

Method card

What the advisor is judging you against

The rules Bottega8 applies when it takes agentic systems into production. The advisor uses them to challenge your plan; it will say when a simpler tool, a process fix, or a pause is the better answer. Below the five principles: the four sizes, how to forecast the economics, the levers you can pull, and what your team must cover for your stage.

  1. 1Locate the bottleneck before choosing the agent

    The unit of analysis is an end-to-end workflow, not a model feature. Look for work that waits in queues, loses context at handoffs, or changes by customer. A copilot that makes one person faster while the queue stays put barely moves the business.

  2. 2Build the translation layer

    Agents are only as reliable as the specifications, decision rules, source provenance, exceptions, and acceptance criteria they receive. If those are weak, the first project is to structure the work, not to add execution.

  3. 3Treat the last mile as part of the product

    Customer, site, and team variation is where working agents fail at deployment. Capture it as governed configuration, UAT cases, readiness decisions, and reusable knowledge before promising autonomous scale.

  4. 4Increase autonomy only as evidence earns it

    Observe → draft → recommend → bounded action with approval → bounded monitored execution. Advancement requires tests, override patterns, error severity, auditability, rollback, and an accountable human owner.

  5. 5Make the business case and the trust case together

    An agent that cannot survive security review, customer scrutiny, or board diligence is not production-ready. Require one operating metric and one trust metric, and keep measured results separate from estimates and targets.

Autonomy ladder

  1. 1Observe and summarize
  2. 2Draft an artifact for review
  3. 3Recommend an action
  4. 4Take a bounded action after approval
  5. 5Execute a bounded class of actions with monitoring and rollback

Advance one rung only on evidence: tests, override pattern, incident severity, audit record, accountable owner.

Your Decision Docket

  • Decision
  • Operating diagnosis
  • Size (S, M, L, XL) and the gate to the next size
  • First workflow
  • Autonomy level
  • Economics: unit economics, break-even, compute levers
  • Team and readiness for your stage
  • 30-day proof plan
  • Measures: business, trust, cost
  • Red flags
  • Runner-up
  • Three board questions

The four sizes

Size the system before you fund it

Four sizes, each nesting the one before. The gate between sizes is never that the model got better; it is that the failure mode of the current size became the bottleneck. Answer the four questions honestly and the size picks itself.

  1. S Single call. Can a human verify the output cheaply?
  2. M Grounded workflow. Does it need your data?
  3. L Bounded agent. Does it need to touch a system?
  4. XL Orchestrated system. Is the process, not the task, the unit of value?
S Single call A wrapper around an API

Components. Prompt, model, output schema. No state, no tools.

Trust mechanism. A human reads every output.

Use cases. Summarize a document, classify a ticket, draft an email, extract fields from a PDF.

Fails when. Output is wrong because the model does not know your material (context), or there is too much to read (volume).

Gate to the next size. You have narrowed the task, written evals against real examples, and output is still rejected for missing context. The problem is retrieval, not reasoning.

M Grounded workflow Retrieval plus a deterministic chain

Components. Adds retrieval over your data, a fixed sequence of steps, structured I/O between steps, a trace per run, and an eval harness. The model reads systems; it does not write to them. Branching lives in your code, not the model's head.

Trust mechanism. Traces and evals; humans still move outputs into systems of record.

Use cases. Answer questions over policy documents, triage inbound with routing suggestions, research brief generation, contract clause flagging.

Fails when. The real workflow has exceptions and handoffs the fixed chain cannot express, and humans are copying outputs into systems of record by hand.

Gate to the next size. Rework is measured (edit distance, rejection rate) and low; the remaining cost is humans moving data between the model and the system of record. The problem is integration and bounded action, not accuracy.

L Bounded agent Tools plus approval gates

Components. Adds tool use with scoped permissions, model-chosen steps within one bounded task, human approval before any write, a rollback path, policy gates, replayable runs, and reason codes on every human override. Writes are reversible.

Trust mechanism. Draft → recommend → act with approval.

Use cases. CRM update agent, PR-opening coding agent, prior-authorization packet assembly, vendor onboarding checklist execution.

Fails when. Approval volume swamps the reviewers, or one task is not the unit of value; the process across many tasks and systems is.

Gate to the next size. A label store exists (accepted, rejected, modified, escalated, with reasons), autonomy thresholds are set per action class from that data, and a named owner is accountable for the agent in production. The problem is now orchestration and memory, not any single task.

XL Orchestrated system Multi-agent with shared state and memory

Components. Adds a shared memory and relationship graph, an orchestrator routing across specialist agents, long-running state and queues, monitored execution on pre-approved action classes, an escalation hierarchy, cost and drift telemetry, and an audit trail across agents.

Trust mechanism. Bounded monitored execution. Humans manage exceptions, not runs.

Use cases. End-to-end go-to-market back office (enrich → score → brief → follow-up), claims adjudication with clinical and financial escalation lanes, revenue operations across CRM, billing, and support.

Fails when. Nobody can explain why the system did something. At that point you have built a liability, not a capability.

Gate to the next size. There is no next size. The work is keeping the explanation, the audit trail, and the cost telemetry ahead of the autonomy.

Each size inherits every component of the one inside it. You do not get to add tools (L) without evals and traces (M). Most failed agent projects are an S wearing an L costume.

Economics

Forecast the return as unit economics

A headline savings number with no baseline is the most common reason a board says yes to the wrong thing. Build the forecast from the unit: what one run is worth, what one run costs, how many runs. The advisor labels every figure you give it measured, estimated, or target, and will not invent one.

Value drivers

  • Throughput. Units per period × minutes or dollars saved per unit. The only driver that counts is end-to-end, after review and rework.
  • Cycle time. Days removed from contract-to-live, ticket-to-close, or claim-to-decision; priced by what the wait costs (cash, churn, capacity).
  • Rework and error. Rejections, corrections, and downstream incidents avoided, including the ones a faster first draft can create.
  • Revenue and capacity. Volume the same team can now take, or a customer promise you can now make; label it target until the proof slice shows it.

Cost lines

  • Build and integration. One-time: workflow structuring, retrieval over your data, system connections, approval and rollback paths.
  • Evals and data preparation. Known-good and adverse test sets, label store, de-identification. Cheap to build first, expensive to retrofit.
  • Compute per run × runs. Tokens per run at the chosen model tier, times expected volume, times retries and review passes. This is the line most proposals forget to multiply.
  • Human review. Minutes per run at the chosen autonomy level. Falls as override rates fall; never zero at L.
  • Operations and monitoring. Traces, drift and cost telemetry, model and vendor changes, incident response, the named owner's time.

The forecast shape

Break-even in months or units = (one-time build + evals) ÷ (monthly value − monthly compute − monthly review − monthly operations). Then name the two assumptions that move it most, usually volume and review minutes per run, and make the 30-day proof measure exactly those.

Contouring compute

  • Route by case class: small models for the routine majority, large models only where evals show they earn it.
  • Cache repeated context (policies, schemas, prior briefs) instead of resending it on every run.
  • Trim inputs to what the decision needs; retrieval beats pasting whole documents.
  • Batch non-urgent work into off-peak runs with lower-cost tiers.
  • Set per-run and per-day budgets with hard stops, and alert on drift.
  • Raise autonomy only where override rates justify it; every extra review pass is a compute and labor cost.

Levers

What you can actually pull

Business and product decisions that change the outcome more than the model choice does. The advisor names the ones that apply to your case.

  1. 1Narrow the case path

    One high-volume case class and its exceptions, not the whole function. Narrowing is the cheapest way to raise accuracy and cut compute.

  2. 2Set the autonomy level explicitly

    Observe, draft, recommend, bounded action, monitored execution. The level is a policy decision you own, not a model property.

  3. 3Structure the inputs first

    Specifications, decision rules, acceptance criteria, source provenance. Often the whole first project, and it pays off at every size.

  4. 4Choose the size, not the ambition

    S, M, L, or XL by the four questions. Fund the size the evidence supports; let the gate, not the roadmap, trigger the next one.

  5. 5Price the run

    Know the cost per run and the value per run before scaling volume. A run that costs more than the decision it supports is a subsidy.

  6. 6Make trust a product feature

    Access controls, audit trail, eval results, incident path. Customers and boards buy these as much as the output, and they are cheaper early.

  7. 7Stage the funding

    Tranche against proof: baseline → vertical slice → gate. A conditional yes with a cost ceiling beats an unconditional yes with no baseline.

  8. 8Decide what humans keep

    Consequential, regulated, and relationship-bearing decisions stay with a named person. Design the handoff; do not let it happen by default.

Team and readiness

What has to be covered before production

Initiatives fall down in production for missing capabilities, not missing models. Every one of these needs a named owner, and the bar moves with your company's stage and risk profile.

  • Workflow and product ownership. A named owner for the workflow, the metric, and the autonomy policy.
  • Evals and test data. Known-good and adverse cases, acceptance thresholds, a label store for human overrides.
  • Data access and integration. Retrieval over the right sources, scoped read and write paths, reversible writes.
  • Security and access review. Permissions, secrets handling, data boundaries, vendor and model data terms.
  • Observability and audit. A trace per run, replay, reason codes on overrides, cost and drift telemetry.
  • Change management. The people whose work changes: training, incentives, the path from reviewer to exception handler.
  • Model and vendor management. Model tiering, upgrade and deprecation plan, fallback when a provider changes behavior or price.

How the bar moves with stage

Pre-seed and seed

Prove one vertical slice with founders as owners. Keep the size at S or M, measure one metric, and write the eval set now; it becomes diligence material later.

Typical failure: Building an L for a customer you have not yet signed.

Series A

This is the first real diligence round and usually the first enterprise buying gate. Trust evidence (access controls, audit trail, eval results, incident path, data terms) is part of the product, not overhead. Name an owner for security review and for evals before the raise, not after.

Typical failure: A demo that wins the pilot and fails the customer's security questionnaire.

Growth

Ownership across functions (product, engineering, security, operations), cost telemetry per workflow, and an autonomy policy per action class. The size can reach L where the label store supports it.

Typical failure: Approval volume swamping reviewers because thresholds were never set from data.

Public and regulated

Model risk governance, documented controls, model inventory, board-level reporting, and regulator-ready audit from day one. Size and autonomy advance only with evidence a third party can read.

Typical failure: A system nobody can explain in front of an examiner or an audit committee.

Want to test the diagnosis against the real thing?

If you want to test this diagnosis against the real workflow and systems, Bottega8 can run a focused diagnostic with your team. Optional, and only after you have your Docket.

Talk to a principal How we work

Advisor v1.1 · bottega8.com/executive-advisor