Brandon Callender is a founding engineer at Typedef whose work spans hardware telemetry, data infrastructure, and tools that help coding agents understand software dependencies. He contributed fenic’s OpenRouter integration and built an Agent Context Workshop that examines a practical problem: giving an agent better information does not guarantee it will use it.
From hardware telemetry to Typedef
Brandon studied computer science at the University of Chicago, graduating in 2016. His public résumé documents a backend engineering internship at Coolan and his progression at Salesforce, where he joined full-time in 2016 and reached Lead Member of Technical Staff in 2021. He completed three Salesforce internships before joining and later mentored successive intern cohorts, including engineers who became full-time employees.
On Salesforce’s Coolan team, Brandon built a Kafka-based pipeline carrying server telemetry and unstructured logs into a distributed parsing service. He led hardware-error detection and integration work, then became the team’s technical lead. His responsibilities included rearchitecting the hardware-health and analytics platform and operating an alerting framework that helped data-center engineers identify and resolve hardware problems.
Brandon subsequently became a founding engineer at Typedef. His contributions include integrating OpenRouter into fenic, giving developers controls over provider selection, latency, throughput, and cost. Fenic combines relational DataFrame operations with model-powered extraction, classification, and summarization, allowing developers to use those capabilities together in data-processing workflows.
His code-context work addresses another infrastructure problem for AI systems: how an agent can determine which parts of a codebase a proposed change will affect. The Agent Context Workshop uses selected crates from Qdrant’s Rust codebase to make the difference between finding a name and identifying the thing it refers to concrete.
Making dependencies explicit
Two Rust types in the example are both called PostingList, yet changes to them affect different code. A text search finds both names. A graph that preserves each type’s identity can distinguish their dependents and let an agent investigate the consequences of changing one particular type.
Brandon’s implementation combines three mechanisms:
Syntax extraction: Tree-sitter identifies symbols and syntactic structure in the selected code.
Symbol identities and dependencies: Rustdoc resolves symbols so that identical names do not collapse into one entity.
Queryable dependency graphs: Neo4j stores the resulting nodes and edges, allowing an agent to traverse relationships through tools such as a blast-radius query.
Together, these give the agent an explicit way to ask which symbols depend on a type, rather than repeatedly searching files and reconstructing the connections. The example covers selected Rust crates; extending it into a maintained context layer requires further work on indexing, updates, and language-specific symbol resolution.
When the agent still chooses grep
The harder interface problem appears after the graph is available: the agent may continue to use grep. Tool names, familiar output formats, and prompting influence whether it chooses the new tools. Building useful context and making that context accessible through tools the agent will select are separate engineering tasks.
The workshop’s reported experiments found near-tied single-run accuracy—21 correct answers out of 30 versus 19 out of 30—alongside stronger consistency across repeated runs. Graph-tool adoption increased from 34% to 72% across the evaluated configurations. These are results from a bounded experiment, rather than a general benchmark for coding agents, but they make the engineering question sharper: a small difference in one-run accuracy can conceal meaningful differences in repeatability and tool use. Brandon’s evaluation pairs those measurements with trace inspection to examine how the agent reached its answers.
Yoni Michael and Brandon Callender connect safe data changes to a working code graph over Qdrant, then confront the harder problem: getting an agent to use that context and measuring whether it helps consistently.
Valid SQL can preserve syntax while changing grain or metric meaning. Check intended row identity, join cardinality and business predicates before acting.
A graph’s capability matters only when the agent uses it. Familiar tool names, familiar result formats and useful first responses help adoption; traces reveal actual usage.
Update operational context incrementally, but keep benchmark commits and injected changes fixed so agent comparisons continue to measure the same task.
▶ Watch ↗