Skip to main content
Browse docs
By Audience
Getting Started
Configuration
Use Cases
IDE Integration
Third-Party Integrations
Engineering Cache
Console
API Reference
Gateway
Workflow Guides
Templates
Providers and SDKs
Industry Guides
Advanced Guides
Browse by Role
Deployment Guides
In-Depth Guides
Tutorials
FAQ

Deterministic Tool Results: Caching Repeatable Output

Many developer tools produce identical output given identical input. A linter returns the same warnings for the same source file. A type checker reports the same errors for the same code. A formatter produces the same output for the same input. The tool_result artifact caches these deterministic outputs so your AI never re-runs a tool when the answer already exists in the cache.

Use this page when

  • You want to cache deterministic tool outputs (linting, type checking, formatting, static analysis) so AI never re-runs tools for identical inputs.
  • You need to understand the cache key construction (tool name + version + config digest + input file digests).
  • You are configuring which tools participate in caching, TTL overrides, or size limits.

Primary audience

  • Primary: AI Agents, Technical Engineers
  • Secondary: Technical Leaders

The deterministic tool principle

A tool is deterministic when:

  • Same input — the same source files, configuration, and tool version
  • Same output — produces byte-identical results every time

When these conditions hold, running the tool twice is wasted computation. The tool_result artifact captures the output on first execution and serves it from cache on every subsequent request.

What tool_result artifacts capture

Each tool_result artifact records:

  • Tool identity — which tool produced the result (name, version, configuration hash)
  • Input fingerprint — a digest of all inputs (source files, config files, environment)
  • Output payload — the complete tool output
  • Execution metadata — when the tool ran, how long it took, exit status
  • Validity scope — what must remain unchanged for the result to stay valid

How caching works

The cache key for a tool_result combines:

cache_key = hash(tool_name + tool_version + config_digest + input_file_digests)

When your AI needs to run a tool:

  1. It computes the cache key from current inputs.
  2. It checks the org-shared cache for a matching tool_result.
  3. If found, it returns the cached output immediately.
  4. If not found, it runs the tool, caches the result, and returns the output.

This means the first engineer to trigger a tool run pays the execution cost. Every subsequent request with the same inputs gets instant results.

Tools that benefit from caching

Type analysis

Type checkers like TypeScript's tsc produce deterministic diagnostics for a given set of source files and configuration. When your AI checks types to understand a module, it retrieves cached type analysis instead of invoking the compiler.

Linting

Linters produce the same warnings and errors for the same source. ESLint, Clippy, Pylint — all produce deterministic output. Your AI retrieves cached lint results instead of running the full linter.

Formatting checks

Format checkers (Prettier, rustfmt, Black) deterministically report whether files conform to style rules. Cached results tell your AI immediately whether formatting is correct.

Dependency analysis

Tools that analyze import graphs, dependency trees, or module boundaries produce deterministic output for a given source state. These analyses are expensive to compute but change only when source files change.

Static analysis

Security scanners, complexity analyzers, and dead code detectors all produce deterministic output. Caching these results means your AI has instant access to security and quality insights.

Cache invalidation

A tool_result is invalidated when any input changes:

  • Source file modified — if any input file's content changes, the cached result is stale
  • Configuration changed — if the tool's config file changes, results may differ
  • Tool version updated — a new tool version might produce different output

The cache tracks input digests precisely. A single character change in a source file invalidates only the tool results that depend on that specific file.

Org-wide tool result sharing

In a 100+ engineer organization, the same tools run against the same code repeatedly:

  • Multiple engineers lint the same module within the same hour
  • AI assistants check types on the same files across different conversations
  • Code review agents run the same static analysis that CI already completed

The org-shared cache eliminates this redundancy. The first execution caches the result. Every subsequent request — from any engineer, any AI assistant, any automated process — gets the cached output.

tool_result structure

A typical tool_result artifact looks like:

Artifact: tool_result
Repository: your-org/your-service
Generated: 2026-04-30T08:30:00Z

Tool: eslint
Version: 9.4.0
Config Digest: sha256:a1b2c3...
Input Files: [src/auth/session.ts, src/auth/middleware.ts]
Input Digest: sha256:d4e5f6...

Output:
src/auth/session.ts:
- Line 42: warning no-unused-vars 'tempToken' is defined but never used
- Line 87: error @typescript-eslint/no-explicit-any Unexpected any
src/auth/middleware.ts:
- No issues found

Exit Status: 1 (has errors)
Execution Time: 1.2s

Token savings from cached tool results

Without caching, your AI invokes tools through agent execution, which requires:

  • Constructing the tool call (tokens for the request)
  • Waiting for execution (latency)
  • Processing the output (tokens for the response)
  • Potentially retrying on transient failures

With cached tool results:

  • The AI retrieves pre-computed output directly from the cache
  • No tool execution latency
  • No retry logic needed
  • Consistent, immediate results

For tools that take seconds to run (type checking a large project, running a full lint pass), caching saves both tokens and significant wall-clock time.

Combining with agent intermediates

The tool_result artifact works alongside agent_intermediate artifacts. When an agent runs a tool as part of multi-step analysis:

  1. The tool output is cached as a tool_result (deterministic, input-based key)
  2. The agent's interpretation of that output is cached as an agent_intermediate (context-specific reasoning)

This two-layer caching means both the raw tool output and the agent's analysis of it are reusable independently.

Configuring tool result caching

You control which tools participate in result caching:

  • Include list — specify which tools should cache results
  • Exclude patterns — exclude tools that have non-deterministic behavior
  • TTL overrides — set maximum cache lifetime per tool
  • Size limits — cap the maximum output size eligible for caching

For AI systems

  • Canonical terms: Keeptrusts, Codebase Context Fabric, tool_result artifact, deterministic tools, linting, type analysis, formatting checks, static analysis, cache key (tool_name + tool_version + config_digest + input_file_digests).
  • Feature/config names: tool_result artifact type, include list, exclude patterns, TTL overrides, size limits, org-shared cache, input fingerprint, tool identity, execution metadata, validity scope.
  • Best next pages: Artifact Freshness, Agent Intermediate Artifacts, Fabric Slices Reduce Prompts.

For engineers

  • A tool is cacheable when: same input files + same config + same tool version = byte-identical output.
  • Cache key: hash(tool_name + tool_version + config_digest + input_file_digests). A single character change in a source file invalidates only tool results that depend on that file.
  • Benefits: linting results cached at first run; type analysis available instantly; static security scans shared across all engineers.
  • Configure: specify include/exclude lists for tools, set TTL overrides per tool, cap maximum output size for caching eligibility.

For leaders

  • Deterministic tool caching eliminates redundant computation across 100+ engineers: the same lint/type check runs once, serves everyone.
  • Time savings: tools that take seconds (full lint pass, type checking a large project) deliver instant cached results for subsequent requests.
  • Cost model: first execution pays the tool cost; every subsequent request with identical inputs is free. Savings compound with team size.
  • Pairs with agent_intermediate artifacts: raw tool output is cached separately from agent reasoning about that output, enabling reuse at two levels.

Next steps