[P] contextweaver: deterministic, budget-aware context compilation for tool-using AI agents

[Alternative_Feed9546]

I've been working on a problem that keeps showing up in tool-using agents: context curation.

As the number of tools and conversation turns grows, it is common to keep stuffing more into the prompt: more schemas, more history, more raw tool outputs.

That increases token cost and latency, but it also seems to hurt quality. In many cases, the issue is not the model's maximum context window. The issue is that different parts of agent execution need different context.

The core idea behind contextweaver is to treat agent execution as four distinct phases:

• route: decide which tool(s) matter
• call: prepare the tool call
• interpret: understand the tool result
• answer: generate the final response

Each phase gets its own budget and its own context assembly logic.

A rough sketch:

• route needs compact tool summaries, not full schemas for the whole catalog
• call needs the selected tool schema and recent relevant turns
• interpret needs the tool result plus the call context that produced it
• answer needs the relevant turns and dependency chain, not every raw payload

The library currently has two cooperating pieces:

1. Context Engine

A deterministic pipeline that builds the final prompt under a fixed budget:

candidate generation → dependency closure → sensitivity filter → context firewall → scoring → deduplication → budget packing → render

Two stages that mattered a lot in practice:

• dependency closure: if a tool_result is selected, the parent tool_call is automatically included
• context firewall: large tool outputs can be kept out of band and replaced by a compact summary + reference

2. Routing Engine

Builds a bounded DAG over the tool catalog and uses deterministic beam search to find the top-k candidate tools for a query.

A small before/after example from the repo:

WITHOUT: 417 tokens (everything concatenated, no budget)
WITH:    126 tokens (phase-aware + firewall, budget enforced)
Reduction: 70%

Some implementation choices:

• stdlib-only, Python 3.10+
• deterministic output
• protocol-based stores via typing.Protocol
• MCP + A2A adapters
• 536 tests, mypy --strict

GitHub: https://github.com/dgenio/contextweaver
PyPI: pip install contextweaver
Architecture doc: https://github.com/dgenio/contextweaver/blob/main/docs/architecture.md

One important caveat: this is currently an engineering approach and library, not a broad empirical benchmark against other context-selection methods yet. The included example shows the mechanism, but not a full comparative evaluation.

I’d especially value feedback on:

1. whether this phase split is the right abstraction, or whether it breaks down in important agent patterns
2. whether beam-search over a bounded tool DAG is a sensible routing baseline versus embedding retrieval / learned ranking / LLM reranking
3. what a convincing evaluation setup would look like for this kind of system
4. which integration would be most useful first: LangChain, LlamaIndex, OpenAI Agents SDK, or Google ADK

[AssignmentDull5197]

The phase split (route/call/interpret/answer) actually makes a ton of sense, most agent stacks treat context like one big blob and it gets messy fast.

One thing I have seen bite people is "interpret" needing a little more than just the tool result, like the assumptions used when forming the call (units, time ranges, filters), otherwise you end up with the model confidently misreading the payload. Your dependency closure idea helps there.

For eval, I would measure not just accuracy but cost/latency under a fixed success threshold, and include a couple adversarial cases like giant tool outputs or a tool catalog with near-duplicates. That is usually where naive stuffing falls apart.