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:
- It computes the cache key from current inputs.
- It checks the org-shared cache for a matching
tool_result. - If found, it returns the cached output immediately.
- 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:
- The tool output is cached as a
tool_result(deterministic, input-based key) - 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_resultartifact 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_intermediateartifacts: raw tool output is cached separately from agent reasoning about that output, enabling reuse at two levels.
Next steps
- Learn how artifact freshness determines when tool results expire
- Explore how agent intermediate artifacts cache agent reasoning on top of tool results
- Understand how fabric slices reduce prompt size by sending cached results instead of raw tool output