Context engineering for agents: how to evaluate Graft

Why it matters

A coding agent can spend a surprising amount of a session figuring out where a small change belongs. It searches, opens files, follows references, and sometimes starts over. The video presents Graft as a way to shorten that investigation by giving the agent a map of how the code connects.

What interests me is whether that preparation improves the economics of an accepted change. Lower token usage is useful, but the evaluation should include the time you spend checking the result. For developers maintaining applications, integrations, and client projects, a faster first draft is only one part of delivery.

There is also an update to account for before following the walkthrough. When checked on October 27, 2026, the official Graft page presented the project as Trail-code. The discussion below keeps the video's name when referring to its demonstration and uses the current documentation for setup guidance. Official Trail-code page

Key points

• 11:08 The demonstrated improvement is narrower than the opening promise. AI Labs reports a 39-minute booking-app build with Graft versus 47 minutes without it. That is roughly a 17% reduction in elapsed time for that run. Reported context-window occupancy fell from 35% to 31%, a difference of four percentage points. Neither measurement directly establishes the reduction in a bill.
• 1:03 Finding the implementation is part of the agent's workload. Before editing, the agent needs to locate relevant code and understand its surroundings. Repeated searches and abandoned file reads are useful things to inspect in your own sessions. Some exploration remains necessary: the agent still needs enough evidence to understand requirements and avoid breaking existing behavior.
• 6:20 The graph supplies relationships worth investigating. Graft records code elements and connections so the agent can find references and dependents. I would treat those results as navigation aids and confirm them against source code and tests. A recorded relationship cannot, by itself, establish every consequence involving runtime configuration, external systems, or production data.
• 8:59 The integration combines instructions with automation. In the walkthrough, a skill explains how to use the tool, while hooks perform actions at specific points in a session. One useful clarification from current Claude Code documentation: a skill's body loads when the skill is used. Installing a skill does not automatically place its entire contents permanently in context. Claude Code skills documentation
• 7:23 Hooks and MCP place retrieval at different points in the workflow. The demonstrated hooks attach candidate locations proactively. With MCP, the agent asks the tool when it decides information is needed. That creates a practical choice between anticipating a lookup and retrieving information on demand. Which approach works better should be established through observed tasks.
• 4:14 The aggregate benchmark remains the developers' evidence. The video cites 162 runs with average reductions of 60% in time, 46% in tool calls, and 32% in cost. Those figures describe that test set. Current documentation clarifies that the reported 42% token reduction concerns uncached input tokens. Official repository and benchmark methodology
• 11:40 The documentation limitation describes the version demonstrated. The video says its Graft setup maps code while leaving requirements and notes outside that mechanism. The current project also includes a learnings layer. A dependency map and a record of decisions still answer different questions, and both need reliable source material. Current project documentation

How to apply

Context engineering for agents starts with a diagnosis

Pick a recent task where the agent seemed to lose its way. Inspect the session for repeated searches, irrelevant reads, revisits to the same modules, and dependencies discovered only after an edit. That gives you a specific problem to evaluate. If most of the difficulty came from an ambiguous requirement, clarifying the expected behavior may deliver a larger improvement.

I would start the evaluation with maintenance work in an established repository. An empty project has relatively few relationships to reuse. An application with authentication, billing, and integrations already contains paths that an agent must discover. Treat that as a hypothesis to test against your own workload.

Define three tasks before running anything

Choose changes that exercise different navigation needs:

1. Fix validation shared by multiple forms.
2. Update a billing rule used by two workflows.
3. Change webhook failure handling and check the affected consumers.

Write acceptance criteria independently of the implementation. For a webhook, a useful criterion might be that delivering the same event twice produces only one business effect. This lets you judge two different solutions against the same requirement. A working screen alone would miss that behavior.

Include the relevant existing checks and identify any additional validation the task requires. The evaluation should have a clear finish line before you observe which setup appears faster.

Set up the current version and record it

The official page now directs users to install @trailhq/trail-code and run trail init inside the repository. Follow the current instructions, select your integration, and record the installed version. The video's graft init and graft build commands belong to the workflow demonstrated there. Official setup instructions

Inspect the configuration changes produced by initialization. Check that relevant project files appear in the map and that the next agent session recognizes the integration. A successful installation is only the starting point; you also want evidence that the agent actually used the map during the task.

Compare complete deliveries

For each task, prepare two separate project copies from the same commit. Keep the model, instructions, permissions, and acceptance criteria consistent. Use fresh sessions and avoid feeding discoveries from the first run into the second. Alternate which setup runs first, and repeat tasks where practical. A single pair of runs provides a useful observation, with limited confidence.

Track a small set of measurements:

| Measurement | What it helps establish | |---|---| | Time to the first relevant edit | Whether code discovery became faster | | Time until acceptance criteria pass | Whether the benefit reaches delivery | | Tool calls and reported usage | How much intermediate work was required | | Defects and human review minutes | Whether the apparent saving moved work to you |

Keep context-window occupancy, token usage, and cost separate. API prompt caching can reduce the cost of reusing context, so a growing history does not imply charging every repeated token at the full input rate on every turn. For subscription workflows, also track the usage information the product actually exposes. Prompt caching documentation

Keep the reasons behind the code accessible

Maintain a concise reference for requirements and consequential decisions. For example: “The provider retries events, so processing must deduplicate using this identifier.” A structural map may help locate the handler and its callers while that note explains the behavior you need to preserve.

I would keep the tool when shorter investigations repeatedly lead to correct changes with equal or lower review effort. If it helps mainly with changes spanning multiple modules, that is a useful adoption boundary. The result worth optimizing is the total time needed to reach a change you are willing to approve.