Speculative tool calling: read early and commit once

TL;DR: Speculative tool calling starts permitted reads before a caller's request is final, then reuses only results that match the confirmed intent, authorization scope, and freshness rules. Keep writes behind a separate commit gate, check the resolved capability rather than its alias, and reconcile uncertain outcomes with a stable operation identity.

A caller begins, "Can you book Friday afternoon..." and then adds, "Saturday morning instead." Starting an availability read early can save waiting, while creating the booking early can create the wrong appointment.

The difference is the effect of the operation. An optimization that overlaps safe work needs an explicit boundary between gathering information and changing business state.

HTTP Semantics, RFC 9110, distinguishes safe request semantics from idempotence. A tool planner needs a similarly precise capability policy, because a friendly function name or a GET route cannot prove what an application does.

The architecture in this guide is vendor-neutral. It does not claim that 60db Agent uses speculative execution, and it contains no measured latency or cost improvement.

Use the speech-to-playback benchmark to test whether speculation shortens the caller's useful-answer wait. This guide focuses on making the optimization safe enough to evaluate.

Table of contents

1. Decide which work can begin early
2. Authorize the resolved capability
3. Give speculative reads a reusable identity
4. Separate the read path from the commit path
5. Handle retries and unknown write outcomes
6. Bound cancellation, privacy, and resource use
7. Test adversarial timing and capability changes
8. Measure the benefit and adopt incrementally
9. Frequently asked questions
10. Keep the optimization behind the business contract

Decide which work can begin early

Speculation is work performed before all of its eventual inputs or decisions are confirmed. In a voice agent, that can mean reading availability while speech continues, preparing a grounded answer before endpointing, or warming a permitted service connection.

Each case has different risks. A speculative read can waste resources, reveal information, consume rate limits, or return a result that becomes stale before it is used.

A speculative write can create a business effect the caller never intended. That effect can survive a corrected transcript, a canceled language-model response, and a disconnected call.

Start by classifying capabilities by actual effect. A public catalog lookup, a private account read, a reservation hold, a booking creation, and a payment are separate categories even if their tool schemas look similar.

A reservation hold changes availability for other people. Treat it as a write or resource reservation with an explicit policy, rather than calling it read-only because no final booking exists yet.

A read can also require identity verification. The absence of a state change does not make private information safe to retrieve before the caller has established the required scope.

Use a capability inventory

For every candidate tool, record the effect class, authorization requirement, data sensitivity, freshness requirement, cancellation behavior, rate budget, and retry semantics. Record only facts verified from the actual service contract and implementation owner.

Do not let the model assign these properties during the call. A model-generated label such as safe lookup is a proposal, while the application registry owns the capability's permitted execution mode.

A capability can support multiple operations. Resolve the actual method and arguments before deciding whether the request is speculative-read eligible.

For example, a customer tool might expose profile reading and profile modification through one endpoint. An allowlist of the endpoint alone cannot establish that a particular request is read-only.

The workflow enforcement guide explains where to keep these policy decisions. The commit boundary must remain enforceable when a model improvises, a prompt changes, or a caller supplies misleading instructions.

Compare operation classes

The following table is a design classification. A check means the operation can fit the stated mode when the listed conditions are satisfied; it is not a blanket approval for every implementation with that name.

The useful first optimization is usually one narrow read. Pick a stable, frequent dependency whose result can be matched to confirmed arguments and whose wasted requests fit the service's budget.

Avoid starting with irreversible or sensitive operations. The additional safety machinery can cost more complexity than the latency benefit you have not yet measured.

Preserve conversation boundaries

A partial transcript is provisional evidence. Recognition can revise a date, a name, or a negation before the caller finishes speaking.

The turn-detection guide explains why a pause alone does not establish final intent. Your speculative planner must tolerate revisions without treating every partial hypothesis as permission to act.

For multilingual requests, argument normalization deserves separate tests. The multilingual evaluation guide keeps names, dates, quantities, and code-switching errors visible at the task boundary.

Use structured intent snapshots. A snapshot can contain the current hypothesis, its source revision, the authorization context, and the response generation that owns it, without claiming that the hypothesis is final.

Authorize the resolved capability

Authorization must evaluate the capability that will execute, after aliases, routing, and wrappers have resolved. Checking an earlier label creates a gap where a permitted name can lead to an impermissible effect.

Suppose a planner requests lookup_slot, an alias your registry resolves to availability.read. That resolved capability can be eligible for speculation if its scope and arguments pass the policy.

Now suppose a configuration change resolves the same alias to availability.hold. A name-based gate that remembers only lookup_slot can start reserving resources while still believing it is performing a read.

These names are illustrative. The lesson is to bind the policy check to the actual executable descriptor and version that the dispatcher will invoke.

Resolve once, validate once, and execute that exact descriptor. If resolution can change between validation and execution, pin the version or repeat validation atomically at the execution boundary.

Fail closed on unknown effects

An unknown capability should not enter the speculative path. The application can defer it to the confirmed path or reject it according to the workflow.

A tool declaring itself read-only is useful metadata only when the registry owner has verified the declaration. Do not trust an arbitrary remote tool description to define your authorization policy.

Review wrappers too. A wrapper can log sensitive arguments, create a cache entry with cross-tenant visibility, or call a second service with broader permissions than the wrapped read suggests.

The policy should cover the observable effect and disclosure boundary. Calling a tool safe because its final return value looks harmless misses side effects in the request path.

A runnable resolved-capability gate

The following Python code is a vendor-neutral local example. It demonstrates alias resolution and rejects a write hidden behind a familiar alias; it does not implement a hosted tool API or a complete authorization system.

from dataclasses import dataclass


@dataclass(frozen=True)
class Capability:
    name: str
    effect: str
    required_scope: str
    version: int


REGISTRY = {
    "availability.read": Capability("availability.read", "read", "slots:read", 1),
    "availability.hold": Capability("availability.hold", "write", "slots:write", 1),
}


def resolve_for_prefetch(alias, aliases, scopes):
    resolved_name = aliases.get(alias)
    capability = REGISTRY.get(resolved_name)
    if capability is None:
        raise PermissionError("unknown resolved capability")
    if capability.effect != "read":
        raise PermissionError("speculation permits reads only")
    if capability.required_scope not in scopes:
        raise PermissionError("required scope is missing")
    return capability


allowed = resolve_for_prefetch(
    "lookup_slot", {"lookup_slot": "availability.read"}, {"slots:read"}
)
assert allowed.name == "availability.read"
try:
    resolve_for_prefetch(
        "lookup_slot", {"lookup_slot": "availability.hold"}, {"slots:read", "slots:write"}
    )
except PermissionError:
    pass
else:
    raise AssertionError("write alias entered speculative path")

Save it to a Python file and execute it. The assertions check the narrow classification gate, including rejection even when write scope exists, because write authorization does not make speculative writes part of this policy.

A production dispatcher must bind the returned immutable descriptor to the implementation it invokes. It must also validate arguments, tenant context, caller authorization, freshness, resource limits, and the actual operation effect.

The example's registry is local application data. A mutable global mapping is not a distributed policy service, and the code makes no claim that it prevents an implementation from lying about its effect.

Treat registry changes as contract changes. A capability that gains a side effect must lose speculative eligibility until the policy owner and tests account for the new behavior.

Give speculative reads a reusable identity

A prefetched result is reusable only when it answers the current confirmed question. Matching the tool name is insufficient because the caller may have changed the date, location, account, or service.

Build the reuse identity from canonical arguments, resolved capability version, tenant, authorization scope, and any data version or freshness condition that matters. Keep the representation explicit enough to explain why a result matched or failed to match.

Canonicalization should follow the business domain. Convert a spoken date to the intended calendar date and time zone before comparing it, rather than hashing raw transcript text and assuming different phrases mean different requests.

Do not normalize away meaningful distinctions. A morning appointment and an afternoon appointment can share a date while requiring different availability reads.

Keep the source transcript revision for diagnostics. A result can be rejected because recognition changed a digit, because the caller corrected the request, or because the authorized account changed.

Separate identity from freshness

A matching request identity does not establish that the result is still current. Availability, prices, balances, and account status can change while the caller is listening or deciding.

Attach the observation time and any service-provided version or expiry to the result. The consumer applies a freshness policy when it uses the data, not merely when the read starts.

For availability, the final write still needs the business system's conflict check. A fresh read can become outdated between checking a slot and attempting to book it.

AWS DynamoDB's conditional-write documentation provides a concrete example of enforcing a condition at write time. The general design is to let the authoritative store decide whether the state still permits the operation.

Do not simulate that guarantee with a local timestamp alone. A short age does not prove that another caller did not reserve the last slot during the same interval.

Keep cache scope narrow

A per-call cache is a simple starting point. It reduces accidental sharing and makes cancellation and retention easier to reason about.

A cross-call cache can be useful for genuinely public data, but private account results need explicit tenant and identity isolation. Authorization changes can invalidate a cache entry even when the query arguments remain identical.

Include the permission context in reuse decisions. A result fetched under one caller's verified identity must not be reused after the session switches to another account or loses the required permission.

The data-boundary guide maps where these results travel. Prefetching increases collection before you know whether the data will be used, so retention and access deserve attention at design time.

Reject late or superseded results

Attach the response generation and intent snapshot to every speculative task. When a correction invalidates the snapshot, cancel disposable work and reject its result from the active answer path.

The interruption state machine explains why cancellation alone is insufficient. A remote service can finish just before cancellation arrives, leaving a result that still needs a validity check.

A result can remain in a narrowly scoped cache if policy allows it. That does not authorize inserting it into the current answer or using it as evidence for different arguments.

Make rejection reasons observable: argument mismatch, expired result, unauthorized scope, stale generation, unknown capability, or exhausted budget. Those reasons help determine whether speculation is saving time or mostly doing discarded work.

Matching a tool name is insufficient evidence that a prefetched result answers the current request.

Separate the read path from the commit path

The read path can start when a provisional intent is strong enough to justify the permitted cost and data access. The commit path starts only after the application's required intent, identity, authorization, and confirmation evidence is complete.

Keep the paths distinct in code and in the operation ledger. A read result is evidence that informs a proposal; it is not an instruction to execute the proposal automatically.

For a booking, the read can return available times. The agent presents a supported option, the caller confirms the relevant details, and the backend validates those confirmed arguments immediately before creating the booking.

A confirmation must bind to the operation's actual arguments. A general "yes" from an earlier turn cannot be reused after the date, price, destination, or account changes.

Model the sequence explicitly

sequenceDiagram
    participant C as Caller
    participant A as Agent application
    participant P as Policy gate
    participant R as Read service
    participant W as Write service
    C->>A: Provisional request
    A->>P: Resolve capability and authorize read
    P-->>A: Permit scoped read
    A->>R: Prefetch current hypothesis
    C->>A: Finish or correct request
    R-->>A: Result with identity and freshness
    A->>P: Match confirmed arguments and scope
    P-->>A: Reuse or discard
    A->>C: Present supported proposal
    C->>A: Confirm exact proposal
    A->>P: Authorize current write
    P-->>A: Permit confirmed operation
    A->>W: Commit with stable operation identity
    W-->>A: Verified result or unknown outcome

This sequence is a reference design. Some workflows need additional identity checks or policy steps, and some reads should wait until the caller finishes because they are too sensitive or expensive to speculate.

The diagram's verified result is stronger than an HTTP request being sent. The application must interpret the service's actual acceptance and completion contract.

Handle changes after confirmation

A caller can correct the request after confirming but before dispatch. If the write has not crossed its commit boundary, invalidate the proposal and require the appropriate confirmation for the changed arguments.

If the write is already accepted, reconcile its state before deciding what to do next. The correction may require a supported modification or cancellation rather than suppressing a local callback.

Keep the spoken response honest. The agent should not claim that nothing happened merely because its own task was canceled.

A warm handoff can be an approved fallback for an unresolved operation. Transfer the known operation state and uncertainty so a human does not unknowingly create a duplicate.

Avoid a hidden commit path

Review every execution route, including retries, fallback tools, aliases, and administrative wrappers. A separate write gate provides little protection if one fallback bypasses it.

The backend should enforce the same policy regardless of which model or prompt proposed the action. Tool arguments are untrusted input until schema validation and business validation succeed.

A signed request establishes a sender relationship under the signature contract. It does not establish that the caller authorized a payment or that the proposed account belongs to the current session.

Those checks remain application responsibilities. The workflow enforcement guide connects them to required-step evidence and adversarial tests.

Handle retries and unknown write outcomes

A network failure does not tell you whether a write happened. The request may have been rejected before reaching the service, accepted but not completed, or completed with its response lost.

Give the confirmed operation a stable identity. Use the same identity when retrying the same operation under a documented idempotency contract, and change it when the business intent changes in a way that defines a new operation.

Do not derive the identity from personal data. An opaque identifier avoids leaking account details through logs, headers, metrics, and support tools.

Store the operation's canonical arguments beside that identity in the authorized business ledger. A repeated identifier with different arguments should be rejected or reconciled under a documented policy.

Read the provider's actual idempotency contract

Stripe's idempotency documentation describes provider-specific storage, retry, and parameter-consistency behavior. It is a concrete example of why idempotency must be understood at the service boundary rather than assumed from an application variable.

Your tool service may provide a different guarantee. Some services deduplicate only within a time window, some require a separate operation lookup, and others provide no supported retry safety for writes.

When a service lacks the required guarantee, design reconciliation before enabling automatic retries. A local deduplication record cannot prove that an external side effect did not occur after your process lost contact.

Distinguish operation states

Use states that reflect available evidence. Proposed, authorized, dispatched, accepted, completed, failed, and unknown are useful concepts when the service can supply the corresponding observations.

Do not invent accepted or completed states that the external system cannot establish. A durable local request record proves dispatch intent, while the service's own record proves its effect.

An unknown state should trigger the approved resolution path. That may be an operation lookup, a same-key retry, a manual review, or a supported handoff.

The outcome metrics guide should count unresolved operations separately from confirmed success. A fluent final sentence cannot turn missing business evidence into a completed task.

Use conditional writes for current-state requirements

Idempotency prevents repeating the same logical operation within its contract. It does not automatically ensure that the operation is still valid against current business state.

A slot can be booked by another caller after your availability read. A balance can change, or a quoted price can expire before confirmation.

Enforce those constraints at the authoritative write boundary using the service's supported version, condition, or transaction mechanism. If the condition fails, return a conflict the agent can explain and resolve.

Do not keep retrying a business conflict as if it were a transient network error. A conflict often means the caller needs a new proposal and fresh confirmation.

Local network failure cannot establish whether the business service committed a write.

Bound cancellation, privacy, and resource use

Speculation creates work that may never be used. Bound that work per call, per capability, and across the system so an optimistic planner cannot exhaust the service that confirmed requests depend on.

Start with one in-flight read for the eligible hypothesis where possible. If each partial transcript starts a new request, recognition revisions can multiply load without producing a better answer.

Coalesce equivalent requests under the complete reuse identity. Cancel superseded reads when supported, but keep stale-result rejection even when cancellation is requested.

Python's asyncio task documentation describes cancellation as a task lifecycle mechanism with cleanup responsibilities. Remote request cancellation still depends on the client and service contract, so do not infer it from a local task state alone.

Budget the whole path

A speculative read has a start deadline, an execution budget, a usefulness deadline, and a retention policy. A result that arrives after the answer was already delivered may have no value even when the request itself succeeded.

Measure waiting on semaphores and connection pools. A system can appear to issue requests early while they spend most of the time queued behind other speculative work.

Prioritize confirmed work over optional speculation. The exact scheduling mechanism can stay simple, but the resource policy must prevent discarded work from delaying operations the caller has already confirmed.

The cost-per-success guide provides the denominator for this trade-off. Include canceled and unused requests rather than reporting only the cost of the winning read.

Limit sensitive prefetch

A private read requires the same access checks whether it is speculative or final. Do not fetch sensitive records just because a partial utterance resembles an account number.

Fetch the minimum fields required for the likely task. A full account export is an inappropriate substitute for a scoped balance or availability lookup.

Keep speculative results out of general logs. Record opaque identity, capability, timing, and reuse status while applying the data policy to payloads.

The transport does not remove this responsibility. The WebRTC, WebSocket, and SIP comparison describes media boundaries, while tool data can travel through a separate HTTPS path with its own logs and processors.

End speculation at the call boundary

On hangup, cancel call-bound speculative reads and reject later results from the active conversation. Approved post-call settlement follows its own policy and should not keep media alive.

The shutdown guide separates those lifetimes. A call-ending event does not erase a dispatched write, but it normally removes the reason to keep an unused availability prefetch running.

Verify resource settlement in long-running tests. A small leak per call can alter later load conditions and make the apparent latency benefit disappear under sustained traffic.

Test adversarial timing and capability changes

Test the optimization as a concurrency feature and an authorization feature. A happy-path read reused once proves little about corrections, stale permissions, or uncertain write outcomes.

Start with the alias case from the local snippet. Resolve the permitted label to a write and assert that the speculative gate refuses it before any external effect.

Test a registry version change between planning and dispatch. The dispatcher must execute the validated descriptor or repeat validation against the new descriptor under a safe binding rule.

Exercise argument revisions

Begin an availability read for Friday, then complete the request with Saturday. Release the Friday result after the correction and assert that it cannot populate the Saturday answer or write arguments.

Repeat with account, location, quantity, and service changes. These cases expose incomplete reuse keys that happen to work for date-only fixtures.

Add a negation revision, such as a caller changing from requesting a booking to asking whether a booking is possible. The system must preserve the distinction between information gathering and authorization to act.

Exercise authorization changes

Start an authorized private read, then change the session's account scope before the result returns. Assert that the old result cannot cross into the new scope.

Test a permission revocation and an expired identity check. A cached result does not create a permanent right to disclose the source data.

Test direct attempts to request a write through an alias or broad wrapper. The policy should classify the resolved operation and its actual arguments regardless of how the model describes it.

Exercise uncertain commits

Accept a write in the test business system, then drop the response. The agent must reconcile using the same operation identity rather than create a second operation.

Return a conflict after a previously successful availability read. The agent should present a supported next step and obtain any required fresh confirmation.

The real-call regression guide explains how to preserve these scenarios as release fixtures. Use deterministic barriers for the race, then run a smaller authorized media test to verify the spoken continuation.

Test the evaluator too

A test that always reports pass is worse than no evidence. Include intentionally unsafe event ledgers and assert that your evaluator detects a duplicate write, a stale read reuse, and a write dispatched before confirmation.

Keep semantic judging bounded to wording or task interpretation. Authorization, capability classification, and duplicate-operation detection should use deterministic evidence where the contract exposes it.

Preserve the first divergence in a failed run. A stale read can cause wrong speech and a wrong action; the report should identify the originating reuse decision rather than treating every symptom as an unrelated model problem.

Measure the benefit and adopt incrementally

Speculation is justified by observed improvement under acceptable correctness, privacy, and cost limits. A theoretical overlap in a sequence diagram is not a measured product result.

Compare baseline and candidate using the same corpus, task mix, load, and observation boundary. Record useful-answer latency separately from first acknowledgment audio.

Track how many reads start, finish, are reused, are discarded, time out, or are rejected by policy. A high discard rate can reveal unstable hypotheses, overly broad triggering, or a workload that offers little useful overlap.

The observability guide connects those counters to individual traces. Use a trace to verify that a claimed latency improvement comes from moving required work off the critical path rather than skipping a necessary check.

Watch transport and speech conditions

A speculative tool read cannot fix a broken media route. Use the SIP troubleshooting guide when dead air comes from transport, and the turn-detection guide when delays come from waiting for an unfinished caller turn.

Measure under representative speech timing. A read triggered near the end of a short request offers less overlap than one triggered early in a long, stable request.

Do not manufacture a benchmark corpus full of unusually predictable utterances merely to make prefetching look effective. Retain corrections, ambiguity, and requests that should never trigger a speculative read.

Apply public tool contracts carefully

60db Agent's tools and webhooks documentation describes HTTPS tool requests, signature verification, a tool-call identifier for deduplication, and a response budget of about six seconds. Those facts describe a public tool boundary, not a statement that the product speculates.

If you build an application-owned read cache behind that boundary, validate the current request contract first. Tool invocation delivery and call-event delivery have different semantics, so do not copy retry assumptions from one to the other.

Keep any speculation in your application explicitly documented and independently tested. Do not expose private runtime routes or infer an undocumented product algorithm.

Preserve the result provenance

Every reused result should carry an explanation of which request produced it and which validation admitted it. Record the capability version, argument fingerprint, scoped identity, observation time, reuse decision, and the response that consumed the result.

That ledger makes a wrong answer investigable. Without it, the team may know that a booking used stale availability but have no way to distinguish an expired cache entry from an incomplete key or a result inserted after interruption.

Avoid recording sensitive payloads merely to make the trace convenient. A restricted reference to the business record can support investigation while ordinary performance logs retain only opaque identifiers and timing.

When the policy rejects reuse, keep the reason even if the application successfully performs a fresh read. Successful fallback can hide a broken optimization unless rejected attempts remain visible in the experiment.

Roll out one capability

Choose one read with a clear owner and contract. Enable it for a controlled test cohort, retain a baseline path, and preserve the same commit gate in both paths.

Define rollback around the optimization flag or call path already present in your system. Avoid adding a general policy platform just to evaluate one prefetch.

Review correctness before latency. If the candidate introduces stale reuse, unauthorized disclosure, or duplicate writes, disable it and fix the contract rather than accepting the defect as a performance trade-off.

Publish the measured benefit only after the experiment establishes it. Until then, the honest deliverable is a design, a runnable gate example, and a test protocol.

A latency experiment must retain the cost and correctness of work that was never reused.

Frequently asked questions

What is speculative tool calling?

It starts a tool operation before the caller's final request or response plan is complete. A safe design limits early execution to permitted operations and validates whether the result still matches confirmed intent before using it.

Which tools should I speculate first?

Start with a narrow read whose permissions, freshness, and resource cost are well understood. Avoid writes, sensitive broad reads, and operations whose side effects are unclear.

Is a GET endpoint always safe to prefetch?

No. HTTP method semantics do not prove that an application's implementation has no harmful side effects or disclosure risk. Classify the actual capability and enforce its verified contract.

Is a temporary reservation a read?

No. A hold changes shared availability or consumes a resource, even when no final booking exists. Give it an explicit reservation policy and treat it as a business effect.

Why check the resolved tool rather than the alias?

Aliases and routing can map a harmless-looking name to a different capability. Authorization must bind to the exact executable descriptor and arguments that will run.

Does write permission allow speculative writes?

Not under the read-only speculative policy in this guide. Permission to perform a confirmed write is separate from permission to act before the caller's final intent and required confirmation exist.

Can I reuse a read after the caller corrects the request?

Only if the complete canonical request identity, scope, capability version, and freshness policy still match. A result for a different date or account cannot become valid merely because the tool name is unchanged.

What belongs in a speculative cache key?

Include canonical arguments, resolved capability version, tenant, authorization scope, and relevant data version or freshness constraints. Keep personal data out of externally visible identifiers and metric labels.

Is a fresh availability read enough to book safely?

No. Shared state can change after the read. The authoritative write service must enforce current availability or another supported condition when it accepts the booking.

What does idempotency protect?

It protects retries of the same logical operation within the service's documented contract. It does not automatically prove current business validity, authorization, or unlimited exactly-once execution across unrelated systems.

What if the write response is lost?

Treat the outcome as unknown until the supported reconciliation path establishes it. Use an operation lookup or documented same-key retry rather than immediately creating a new operation identity.

Should cancellation discard a completed write?

No. A local cancellation cannot undo an accepted external effect. Reconcile the write and follow a supported modification or compensation workflow when the caller changes the request.

Can a signed tool request prove caller authorization?

It proves only the sender relationship and message properties covered by the signature contract. The backend still needs caller scope, validated arguments, required confirmation, and business authorization.

How much latency does speculation save?

The benefit depends on how much permitted work overlaps with speech or other required processing. Measure useful-answer latency with a matched baseline rather than promising a fixed improvement from the architecture alone.

Can speculation increase cost?

Yes. Reads that are canceled, discarded, or never reused still consume resources and may incur charges. Include that work when evaluating cost per completed task and capacity under load.

How do I prevent partial transcripts from flooding tools?

Coalesce equivalent hypotheses, bound in-flight work, and trigger only eligible reads under an explicit budget. Preserve the source revision and cancel or reject superseded work when the caller changes direction.

What should happen when a result expires?

Reject it for decisions that require fresh data and perform the supported fresh read or fallback. A cache hit is useful only when its freshness matches the operation's actual requirements.

Does 60db Agent use speculative tool calling?

This guide makes no such claim. Its public documentation describes tool webhooks and related contracts; the speculative architecture here is a vendor-neutral application design.

How do I test a resolved-tool bypass?

Map a permitted alias to a write capability and assert that the speculative gate rejects it before dispatch. Repeat with a registry version change to test binding between validation and execution.

What is the smallest safe rollout?

Enable one verified read capability for a controlled cohort, preserve the confirmed-write gate, and record reuse, discard, latency, cost, and correctness evidence. Expand only when the measured result justifies the additional work.

Keep the optimization behind the business contract

Speculative tool calling works by moving permitted work earlier. Its safety depends on preserving the boundary between provisional information and confirmed business effects.

Resolve capabilities before authorization, bind reads to complete request identities, and validate freshness when results are used. Keep writes behind their own policy and reconcile uncertain outcomes with stable operation identities.

Start with the local resolved-capability example and one delayed-read regression fixture. Then compare the candidate against a matched baseline through the real supported media path, with business correctness and resource use visible beside latency.

If you connect this design to 60db Agent, build against the current public tool contract and keep the application-owned speculation explicit. The goal is a shorter verified wait for the caller, with every committed action still grounded in the request they confirmed.