Nuvio · Founding Engineer · 2026
Glue.tools
Brownfield code, turned into a queryable product graph, with agents that document, answer and triage
Part of a ProductOS platform, built for brownfield codebases where a product's features live only in thousands of undocumented functions and tribal knowledge. Glue turns the code into a queryable product graph and runs agents on top to auto-document features, answer questions in plain English, and triage bugs to a root cause, owner, and fix plan.
The chronicle
After Leucine I wanted to explore the uses of AI beyond pharma, so I joined Nuvio as a founding engineer and built Glue from the inception of the idea. Glue is part of a ProductOS platform: it connects to your codebase, turns it into a product graph, and runs a set of agents over that graph to understand, manage and grow the software, built specifically for brownfield projects, where the code already exists and almost nothing is documented.
The graph is the foundation. Deterministic, language-specific indexers (Java, TypeScript, Python) parse the codebase to extract symbols, symbol calls, web routes and API calls, and dependencies. The result is a graph where nodes are functions and edges are calls, the substrate every agent reasons over.
I built the agents on LangChain with a LangGraph human-in-the-loop orchestrator for the dev-plan flow, integrated all the external data sources for the agentic tool calls, wrote the language indexers, and built the MCP server that exposes the graph and dev plans natively in the developer's IDE.
Movement I
The product graph
Everything starts by turning code into something queryable: a deterministic graph built before any model is involved.
- Language-specific indexers (Java, TypeScript, Python) parse the codebase to extract symbols, symbol calls, web routes and API calls, and dependencies
- The output is a graph where nodes are functions and edges are calls, the substrate every downstream agent reasons over
- Built for brownfield codebases, where the software exists but its features were never written down anywhere
Movement II
Documentation agent
A repo can hold thousands of functions, and its features live nowhere in the code. Dumping the whole graph at an LLM is the naïve fix; structure does it better.
- A Louvain community-detection pass clusters the symbols that interact most frequently, a base grouping that maps to the product's features
- The documentation agent explores each cluster's symbols through fixed agent tools, generating the feature list and enriching the details in two steps
Movement III
Q&A and Triage agents
With documentation, graph and clusters exposed as tools, two more agents put the graph to work, and connect to where the team already operates.
- Q&A agent: lets users talk to their codebase in plain English over the docs, graph and Louvain clusters; connectable to Slack so answers live in the team's channels
- Triage agent: ingests a ticket, finds the root cause from the product graph and production logs, identifies the experts from commit history, and generates a development plan to fix it
- Integrations feed the context: ClickUp, Jira, and Linear for tickets and feature requests; Slack and Sentry for production logs
Movement IV
Orchestration, tools and MCP
Every agent runs on a central orchestration architecture built on LangChain and LangGraph, the harness that keeps an agentic system reliable.
- Input guardrails (prompt injection, off-policy intent) and output guardrails with formatting
- An LLM gateway logging every request's input, output, cost and errors; rate limiting per user and per model; fallback routing on context-limit hits, provider errors and failures
- Tool-call logging, retries and rate limits per agent, with specific tools plugged into each agent for its task
- An MCP server exposing the indexed product graph and generated dev plans natively in the IDE (Claude Code, Cursor, Cline, VS Code) so developers can use the graph for their own purposes too