Designing Confidence Scores for Antigravity Agent Outputs: Auto-Approve the Certain, Escalate the Ambiguous

Three approaches to obtaining a confidence score

Let us look at each one at the implementation level. The examples assume Python and the Antigravity Agent SDK.

Approach 1: Have the model evaluate itself (self-evaluation)

This is the simplest, but a poorly designed prompt produces inflated scores. The trick is to enumerate concrete failure modes and instruct the evaluator to deduct points whenever any of them apply.

# Confidence scoring: ask the model to evaluate its own output
import anthropic
from typing import Literal
 
client = anthropic.Anthropic()
 
SELF_EVAL_PROMPT = """The following is the output of an AI agent.
You are a strict reviewer evaluating it.
 
Output:
{output}
 
Original task:
{task}
 
Starting from 100, deduct points for each item that applies:
- Contains factual errors or invented information: -40
- Does not directly answer the original task: -25
- Includes unnecessary preamble or padding: -10
- Schema or format violation: -30
- Adds assumptions not present in the task: -15
 
Return ONLY a single integer between 0 and 100, with no other text.
"""
 
def self_evaluation_score(task: str, output: str) -> float:
    msg = client.messages.create(
        model="claude-haiku-4-5-20251001",  # a small model is fine for evaluation
        max_tokens=10,
        messages=[{
            "role": "user",
            "content": SELF_EVAL_PROMPT.format(task=task, output=output),
        }],
    )
    raw = msg.content[0].text.strip()
    try:
        score = int(raw)
    except ValueError:
        # Failed parse is treated as the lowest score (conservative)
        return 0.0
    return max(0.0, min(1.0, score / 100.0))
 
# Example
score = self_evaluation_score(
    task="Extract amount, tax rate, and due date from the invoice PDF as JSON",
    output='{"amount": 12000, "tax_rate": 0.1, "due_date": "2026-06-15"}',
)
# Expected output: 0.85 to 0.95 (a reasonable extraction)

A practical caution: if you use the same model for generation and evaluation, the evaluator becomes blind to its own mistakes. Generate with claude-sonnet-4-6 and evaluate with claude-haiku-4-5-20251001, or at minimum route evaluation to a different provider entirely (Gemini or GPT). Cost is rarely a concern because evaluation prompts are short and a small model is sufficient.

One more pattern that has saved me time: keep the deduction list in a separate file (YAML or JSON) and load it at runtime. As your operation matures, you will discover new failure modes that should subtract points. Editing them in a config file rather than a Python string lets non-engineers contribute to evaluation logic, which I have found valuable when domain experts spot patterns the engineer misses. A small operational quality team can iterate on the prompt without touching the deployment pipeline.

A subtler issue is that self-evaluation responses can themselves be hallucinated. The model might "rate" your output even when the deduction logic does not technically apply, simply because it pattern-matches to the prompt format. Counteract this by including, every so often, deliberately broken outputs in your evaluation prompts during testing — if the model rates them as 80, your prompt is too lenient. I run this check monthly with a fixed set of 20 known-bad outputs and watch for drift.

Approach 2: Measure verifiability (schema + rule-based)

Type-checking LLM outputs with Pydantic is a common pattern, but the important shift is treating it as a score rather than a binary pass/fail.

# Confidence scoring: schema and rule-based verification
from pydantic import BaseModel, Field, ValidationError
from datetime import date
 
class InvoiceExtraction(BaseModel):
    amount: float = Field(gt=0, description="Invoice amount, positive")
    tax_rate: float = Field(ge=0, le=1, description="Tax rate between 0 and 1")
    due_date: date = Field(description="Payment due date")
 
def verifiability_score(output_dict: dict, expected_amount_range: tuple = None) -> float:
    """
    Compute a score from schema validation and domain rules.
    Full pass = 1.0, partial violation = 0.5, structure broken = 0.0.
    """
    score = 1.0
 
    # Layer 1: schema validation (strict)
    try:
        parsed = InvoiceExtraction(**output_dict)
    except ValidationError:
        return 0.0  # schema failure is fatal
 
    # Layer 2: domain rules (softer)
    if expected_amount_range:
        lo, hi = expected_amount_range
        if not (lo <= parsed.amount <= hi):
            score -= 0.3  # outside expected band
    if parsed.due_date < date.today():
        score -= 0.4  # past dates are clearly suspect
    if parsed.tax_rate not in (0.0, 0.08, 0.1):
        score -= 0.2  # outside common Japanese tax rates
 
    return max(0.0, score)
 
# Example
data = {"amount": 12000, "tax_rate": 0.1, "due_date": "2026-06-15"}
v_score = verifiability_score(data, expected_amount_range=(1000, 1_000_000))
# Expected output: 1.0 (passes all rules)

The strength of this approach is determinism. It does not depend on the LLM's mood and reproduces cleanly in CI. The weakness is that it only applies to verifiable domains — free-form prose is much harder to score this way.

For prose-heavy outputs, you can extend this approach with structural rules even when full schema validation is impossible. Things like minimum and maximum sentence count, presence of required keywords from the task description, and absence of forbidden patterns (URLs to known-broken domains, banned phrases) all serve as cheap deterministic signals. They are not as strong as a Pydantic schema, but they catch a meaningful fraction of failures and contribute to the verifiability score in domains where stricter checks do not apply.

Another extension worth implementing early: cross-reference the output against the input. If the agent is supposed to extract entities from a document, every extracted entity should be substring-findable in the original text. A "hallucinated entity" detector — output entities that do not appear in the source — is a single regex check and catches one of the most common error modes.

Approach 3: Historical similarity from past task logs

This is the most valuable signal, and the one I see implemented least often. Log every agent output along with the human review verdict (approved / rejected). When a new task arrives, retrieve the K most similar past tasks and use their approval rate as the score.

# Confidence scoring: approval rate of similar past tasks
import numpy as np
from typing import List, Tuple
 
class HistoricalScorer:
    """
    Maintains a log of (task embedding, approval flag) and returns the
    approval rate of the top-K most similar past tasks.
    """
    def __init__(self, top_k: int = 10):
        self.embeddings: List[np.ndarray] = []
        self.approvals: List[bool] = []
        self.top_k = top_k
 
    def add_record(self, task_embedding: np.ndarray, approved: bool) -> None:
        self.embeddings.append(task_embedding)
        self.approvals.append(approved)
 
    def historical_score(self, new_task_embedding: np.ndarray) -> float:
        if len(self.embeddings) < self.top_k:
            # Not enough history yet; return a neutral score
            return 0.5
        sims = [
            np.dot(new_task_embedding, e) /
            (np.linalg.norm(new_task_embedding) * np.linalg.norm(e) + 1e-9)
            for e in self.embeddings
        ]
        top_indices = np.argsort(sims)[-self.top_k:]
        approval_rate = np.mean([self.approvals[i] for i in top_indices])
        return float(approval_rate)
 
# Example
scorer = HistoricalScorer(top_k=10)
# At startup, replay your most recent 1000 tasks into scorer.add_record(...)
new_emb = np.random.rand(1024)  # in practice, generated by an embedding model
h_score = scorer.historical_score(new_emb)
# Expected output: with enough data, somewhere in 0.7 to 0.95 depending on task type

What makes this score genuinely useful is that it surfaces task types where your agent is systematically weak. If "rare clauses in legal contracts" stays below a 30% approval rate, you know to swap in a different prompt or route those specifically to a stronger model.

There is a chicken-and-egg concern here: until you have logs, you cannot compute historical scores, and until you score, you cannot decide what to log. The way I bootstrap is to run in "log-only" mode for the first two to four weeks. Every output is reviewed by a human as before, but the verdict is recorded in a structured log alongside the task embedding. Once you have 200–500 labeled records, you can switch on graduated approval with the historical signal already calibrated.

The choice of embedding model matters less than people fear. Anything reasonably capable — text-embedding-3-small from OpenAI, text-embedding-004 from Google, or even a smaller open model — works well enough at this scale. The differentiator is consistency: use the same embedding model for the entire history, because mixing models produces a similarity space where distances are meaningless across vintages.

Combining the three signals

The three signals have different characteristics, so a weighted combination beats a simple average. The weights I use in production:

# Composite confidence score
def composite_confidence(
    self_eval: float,
    verifiability: float,
    historical: float,
    weights: tuple = (0.3, 0.4, 0.3),
) -> float:
    """
    Weighted combination. Verifiability gets the largest weight because
    it is deterministic and tamper-resistant.
    """
    w1, w2, w3 = weights
    composite = w1 * self_eval + w2 * verifiability + w3 * historical
    # Hard floor: if verifiability is 0, force the composite low
    if verifiability == 0.0:
        composite = min(composite, 0.2)
    return composite
 
# Example
final_score = composite_confidence(
    self_eval=0.9,
    verifiability=1.0,
    historical=0.85,
)
# Expected output: 0.3*0.9 + 0.4*1.0 + 0.3*0.85 = 0.925

The floor when verifiability == 0 was a painful addition. Early on I had a case where the schema failed but self-evaluation returned 0.95, the composite climbed above 0.7, and a malformed record auto-approved into production. Never again.

Threshold design and routing

Routing the score into three tiers is mechanically simple. Choosing the thresholds is what determines the quality of your operation.

# Routing for graduated approval
from enum import Enum
 
class Decision(Enum):
    AUTO_APPROVE = "auto_approve"
    HUMAN_REVIEW = "human_review"
    AUTO_REJECT = "auto_reject"
 
def decide(
    confidence: float,
    upper_threshold: float = 0.85,
    lower_threshold: float = 0.55,
) -> Decision:
    if confidence >= upper_threshold:
        return Decision.AUTO_APPROVE
    if confidence >= lower_threshold:
        return Decision.HUMAN_REVIEW
    return Decision.AUTO_REJECT
 
# Example
for c in [0.92, 0.70, 0.40]:
    print(c, decide(c))
# Expected output:
# 0.92 Decision.AUTO_APPROVE
# 0.70 Decision.HUMAN_REVIEW
# 0.40 Decision.AUTO_REJECT

I recommend upper=0.85 / lower=0.55 as a starting point, but treat it as a hypothesis to be tested. The next section walks through calibration.

Calibrating thresholds with ROC-style analysis

Choosing thresholds by gut feel always backfires later. Once you have at least 200 (preferably 500) logged decisions with human-verified labels, run a calibration pass.

# Threshold calibration: derive the upper bound from a target precision
import numpy as np
 
def calibrate_upper_threshold(
    scores: list, true_labels: list, target_precision: float = 0.95
) -> float:
    """
    Derive the upper auto-approve threshold from a target precision.
    true_labels: 1 = correct on later human review, 0 = incorrect.
    target_precision: desired precision among auto-approved items.
    """
    pairs = sorted(zip(scores, true_labels), key=lambda x: -x[0])
    cum_correct = 0
    cum_total = 0
    for s, label in pairs:
        cum_total += 1
        cum_correct += label
        precision = cum_correct / cum_total
        if precision < target_precision and cum_total >= 20:
            # The previous score is the lower bound of the auto-approve band
            return s + 0.01
    return 0.5  # not enough data
 
# Example with synthetic logs
historical_scores = [0.95, 0.90, 0.88, 0.85, 0.80, 0.70, 0.55, 0.40]
historical_labels = [1, 1, 1, 1, 0, 0, 0, 0]
upper = calibrate_upper_threshold(
    historical_scores, historical_labels, target_precision=0.95
)
# Expected output: around 0.86 (the lowest score that still maintains 95% precision)

A practical note: setting target_precision to 0.99 collapses the auto-approve volume to almost nothing, which sends everything to human-review and defeats the point. I find 0.95–0.97 strikes a realistic balance, calibrated to the business cost of letting an error through.

A useful mental check: the target precision is not the same as your acceptable error rate in the system as a whole. If 95% of auto-approved items are correct, that means 5% of them are wrong, but those 5% pass into downstream systems unchecked. Whether that is acceptable depends entirely on what those downstream systems do. Sending an internal Slack notification at 5% wrong-rate is fine. Posting a public tweet at 5% wrong-rate is a brand crisis waiting to happen. Reverse-engineer the precision target from the cost of a single wrong output, not from a generic SLA number you pulled from a blog post.

The lower threshold (auto-reject cutoff) is the inverse problem — at what point should you give up and retry instead of asking a human? In my own setup, where retry costs are mostly API charges and human review is my own time, I keep the lower bound around 0.4–0.5. For setups using expensive frontier models heavily, 0.6–0.7 makes more sense, since paying for another generation is more painful than asking a colleague.

End-to-end pipeline integrated with Antigravity Agent

Here is how all the pieces fit into a Python service that the Antigravity Agent can call.

# Graduated approval service called from an Antigravity Agent
import json
import logging
from dataclasses import dataclass
 
logger = logging.getLogger("graduated-approval")
 
@dataclass
class ApprovalResult:
    decision: Decision
    confidence: float
    output: dict
    reason: str
 
def graduated_approval_pipeline(
    task: str,
    raw_output: str,
    expected_amount_range: tuple = None,
) -> ApprovalResult:
    """
    Receive an Antigravity Agent's raw output and return the routing decision.
    """
    # Step 1: Try to parse (parse failure = immediate reject)
    try:
        output_dict = json.loads(raw_output)
    except json.JSONDecodeError:
        return ApprovalResult(
            Decision.AUTO_REJECT, 0.0, {}, "JSON parse failed"
        )
 
    # Step 2: Compute the three signals
    s_eval = self_evaluation_score(task, raw_output)
    v_score = verifiability_score(output_dict, expected_amount_range)
    # historical scorer assumed initialized at startup
    # h_score = scorer.historical_score(embed_task(task))
    h_score = 0.7  # sample value
 
    # Step 3: Composite
    confidence = composite_confidence(s_eval, v_score, h_score)
 
    # Step 4: Route
    decision = decide(confidence)
 
    # Step 5: Always log for later calibration
    logger.info(json.dumps({
        "task": task[:200],
        "self_eval": s_eval,
        "verifiability": v_score,
        "historical": h_score,
        "confidence": confidence,
        "decision": decision.value,
    }))
 
    return ApprovalResult(
        decision=decision,
        confidence=confidence,
        output=output_dict,
        reason=f"s={s_eval:.2f} v={v_score:.2f} h={h_score:.2f}",
    )
 
# Example: invoked from an Antigravity Agent walkthrough step
result = graduated_approval_pipeline(
    task="Extract amount, tax rate, and due date from the invoice PDF",
    raw_output='{"amount": 12000, "tax_rate": 0.1, "due_date": "2026-06-15"}',
    expected_amount_range=(1000, 1_000_000),
)
print(result.decision, result.confidence)
# Expected output: Decision.AUTO_APPROVE 0.91 (approximately)

Exposing this as an HTTP endpoint lets the agent follow a simple flow: finish task, post output to the service, advance on auto_approve and pause on human_review. Wired into an Antigravity Walkthrough step, the pending-review state shows up directly on the Manager Surface, where it is hard to miss.

A small but practical detail: when human review is required, the agent should not silently spin while waiting. Configure your Antigravity Walkthrough to write a structured event to the Manager Surface (and ideally a Slack or email notification) so a reviewer knows there is work waiting. The faster the round-trip from "agent paused" to "human verdict received," the more this whole pattern feels like augmentation rather than friction.

The same endpoint can also serve as a control plane for emergency overrides. Adding a flag like force_human: bool = False lets you bypass auto-approve for an entire batch when something feels off — a model upgrade just shipped, an unusual event in your domain, a regulator asked questions about a category of decisions. The ability to flip a switch and put everything back into the human queue, without redeploying, is operationally valuable in ways that are hard to appreciate until you need it.

Common pitfalls

Three pitfalls I have stepped on personally. Avoiding them up front saves you a lot of grief.

First, the self-evaluation overconfidence problem. Generation and evaluation by the same model produces lenient evaluations. At minimum, route evaluation to a different model family (generate with Claude, evaluate with Gemini or GPT-4). If cost is a concern, a small model like Haiku 4.5 is plenty for evaluation work.

Second, score distribution drift. After one or two months in production, the input data shifts and the score distribution skews. For example, invoice processing peaks early in the month with high scores; contract processing peaks late in the month with lower scores. Build a weekly habit of plotting the distribution (a histogram plus median is enough) and investigate when it moves abruptly. Combining this with the A/B testing infrastructure from antigravity-prompt-versioning-ab-testing-production-guide works well.

Third, the always human-review failure mode. Set thresholds too tight and almost everything funnels into the queue, which is full review by another name. Aggregate auto_approve / human_review / auto_reject rates monthly. If auto_approve dips below 50%, revisit the thresholds before you blame the agent.

When graduated approval is not the right answer

This pattern is powerful, but it is not universal. There are at least three categories of work where I would advise against deploying it.

The first is irreversible high-stakes actions. If a single bad output can cost five figures, ruin a customer relationship, or trigger regulatory action, the right answer is not "auto-approve at high confidence." It is "always require human review for this action class," and confidence scoring becomes a way to prioritize the human queue rather than skip it. A wire transfer, a contract signing, a public announcement — these belong in a permanent human-required tier no matter how confident the agent is.

The second is work without a verifiable signal. If you have no way to retrospectively check whether the output was correct (no Pydantic schema, no domain rule, no downstream system that will eventually catch errors), then the historical similarity score never gets meaningful labels and the whole calibration loop breaks. Pure creative writing, brainstorming output, and exploratory research often fall here. For these, a different review pattern works better: sample, say, 1 in 10 outputs at random and check those.

The third is very low task volume. If your agent processes 5–10 items per day, the engineering investment in scoring infrastructure outweighs the savings. Just review them all. Graduated approval pays back its complexity at roughly 50 items per day or more.

Recognizing these cases honestly is part of professional judgment. I have seen well-intentioned engineers (myself included) try to apply this pattern to creative work and end up with a calibration loop that never converges, because the underlying labels were always subjective.

A back-of-envelope cost analysis

Whether graduated approval pays off in your situation is worth estimating before you build it. The numbers below are from one of my own production agents, normalized to make them general.

Suppose your agent processes 500 outputs per day. Without graduated approval, you (or a team) spend on average 30 seconds per item reviewing. That is 250 minutes per day, or roughly four hours of focused review work daily. Most teams cannot sustain this; in practice it gets cut to a "spot check" that misses the actual problems.

With graduated approval at the suggested initial thresholds, a typical distribution after calibration is roughly 60% auto-approve, 30% human-review, and 10% auto-reject. That gives 150 items per day requiring human review, at the same 30 seconds each — 75 minutes daily. The auto-reject items take effectively zero human time, since they are queued for retry.

The added cost is API spend on the self-evaluation calls. With a small evaluator model like Haiku 4.5, the per-call cost is well under one US cent. At 500 calls per day, that is around three to five dollars per day of additional API spend, or roughly $100 per month — far less than the time you reclaim.

The breakeven, in my own bookkeeping, is somewhere around 80 items per day. Below that, the engineering and API overhead is not worth it. Above 200 items per day, the savings are dramatic. This is worth modelling honestly with your own numbers before committing to building the infrastructure.

A continuous improvement loop from operational logs

Thresholds are not a one-time decision. Building a calibration loop into your operations lets you watch the agent improve over time, with data instead of impressions.

In practice: log every human review verdict (approved or rejected) as structured records, and run a weekly batch that recomputes:

• The latest upper_threshold that holds a target_precision of 0.95
• A histogram of the most recent N confidence scores
• A list of "high-confidence but human-rejected" cases

That last list is gold. It points directly at the failure modes that your SELF_EVAL_PROMPT is missing, and gives you a concrete list of new deductions to add. In my own operation, the deduction list grew from 5 items to 12 over three months, and the rate of "high-confidence but rejected" dropped from 8% to 2%.

For the observability foundation that makes all of this easy to see, the OpenTelemetry setup in Antigravity Agent Trace Observability Design pairs naturally with this pipeline. The three patterns of validation loops themselves are catalogued in Three Patterns of Antigravity Agent Validation Loops.

A calibration logbook: three months of numbers

Abstractions only go so far, so here is my own calibration logbook from running an invoice-and-inquiry processing agent for three months, in chronological order. The numbers are rounded for generality, but the shape of the change is real.

Month 1 (log-only). No routing yet — every item went through human review while I recorded only the self-evaluation score and the approved/rejected label. About 1,400 records accumulated. Plotting the distribution at this point showed a large peak above 0.9 and a smaller second peak around 0.6. The latter was almost entirely "contract clause interpretation" tasks, which surfaced the agent's weak spot before I had even added the historical score.

Month 2 (routing on). I turned on routing with upper=0.85 / lower=0.55. The first week's distribution was 52% auto-approve, 41% human-review, 7% auto-reject. Auto-approve was lower than I wanted, so I ran calibrate_upper_threshold with target_precision=0.95, which returned an optimal upper of 0.83. Lowering it from 0.85 to 0.83 raised auto-approve from 52% to 63% while still holding 95.4% precision among auto-approved items. That a 0.02 difference matters this much is exactly why you should not pick thresholds by feel.

Month 3 (prompt improvement loop). Each week I pulled the "high-confidence but human-rejected" cases and added deductions to SELF_EVAL_PROMPT. The deduction list grew from 5 to 12 items, and the "high score yet rejected" rate fell from 8% to 2%. At the same time, routing the contract-clause tasks specifically to a separate prompt plus a stronger model lifted that category's approval rate from 31% to 78%.

The single most effective thing across those three months was not a clever algorithm. It was the dull habit of just looking at the rejected cases every week. An agent's weaknesses do not reveal themselves in the abstract — they show up, always in concrete form, inside the rejected logs.

Build the kill switch in from day one

Finally, the mechanism I most wished I had added earlier: a kill switch that forces an entire batch back into human review at once.

Right after a model upgrade, when something unusual happens in your domain, when an outside party asks questions about a class of decisions — in these moments you want everything back under human eyes regardless of score. Being able to do that with a single switch, without redeploying, is something whose value you only fully appreciate once you need it.

# Routing with a kill switch
import os
 
def decide_with_kill_switch(
    confidence: float,
    upper_threshold: float = 0.85,
    lower_threshold: float = 0.55,
    force_human: bool = False,
) -> Decision:
    # External flag (env var / KV / feature flag) overrides everything
    kill_switch = force_human or os.environ.get("APPROVAL_FORCE_HUMAN") == "1"
    if kill_switch:
        # Auto-reject is still fine to discard (it only goes to retry)
        if confidence < lower_threshold:
            return Decision.AUTO_REJECT
        # Everything else goes to a human regardless of confidence
        return Decision.HUMAN_REVIEW
    return decide(confidence, upper_threshold, lower_threshold)
 
# Example: send everything to humans for a day right after a model swap
os.environ["APPROVAL_FORCE_HUMAN"] = "1"
print(decide_with_kill_switch(0.97))   # Decision.HUMAN_REVIEW
print(decide_with_kill_switch(0.30))   # Decision.AUTO_REJECT

The key is to keep the flag outside your code — in an environment variable, a KV store, or a feature flag. Embed it in code and an emergency requires a redeploy, which defeats the entire point of "I need to stop this now." I flip this flag manually on any day I make a large change to my automated publishing pipeline, watch every item by hand for half a day, and only then turn it back off.

A small first step

This was a long article, but the next step you can take tomorrow is a single one.

Attach the self-evaluation score to your existing agent's outputs and just log it. No routing yet — only logging. After one or two weeks of accumulated logs, you will start to see the pattern: scores below 0.7 really do correlate with suspicious outputs, scores above 0.9 really do tend to be right. Threshold design comes after that intuition forms.

Concentrating human judgment on the cases that most need it — that has been a principle I have rediscovered repeatedly while running my own apps as an indie developer for over a decade. Defining, with data, the line between what you trust the agent to decide and what you keep for yourself is becoming, I think, one of the core engineering skills of the next few years of independent development.

Thank you for reading to the end.