Redzam

Inspiration

I built Redzam independently, but the idea did not emerge in isolation.

While talking with developers building AI-driven products, I kept hearing variations of the same problem: the model is rarely the hardest part. The real challenge is giving an agent enough reliable context to work safely inside an existing product.

Coding agents repeatedly search the same files, reconstruct relationships from snippets, consume large amounts of context, and still miss indirect dependencies or side effects. They can generate convincing patches, but it is often difficult to determine what they understood, what might break, or whether the result actually satisfies the original request.

At the same time, the people who notice product problems first—users, support teams, QA, product managers, and operators—are usually far removed from the code. Their requests pass through tickets, triage, backlogs, and several handoffs before anything changes.

Redzam began with a simple question:

Could a request made from inside an application become a safe, traceable code proposal without removing the developer from the final decision?

What Redzam does

Redzam connects the application someone is using with the code behind it.

A user or stakeholder describes a problem or desired change through an embedded widget on the relevant page. Redzam uses the page context and its knowledge of the repository to understand the request, investigate the affected architecture, and ask a focused clarification when the intended outcome is ambiguous.

The complete Taskmaster workflow is designed to turn that confirmed intent into a structured work item, map the potential blast radius, retrieve only the necessary source files, implement the change within repository-defined guardrails, run the project’s checks, and produce an evidence-backed pull request for human review.

Redzam never merges or deploys generated changes automatically. The requester defines the desired outcome; the repository owner defines what the agent may change; a developer makes the final decision.

Why a code graph?

Most AI coding tools begin each task by searching files and assembling temporary context. Redzam instead maintains a typed, versioned graph of the codebase.

The graph represents functions, methods, types, calls, imports, dependencies, effects, execution flows, and exact source locations. Every snapshot is tied to a Git commit, allowing Redzam to reason about the same revision it is being asked to change.

This graph is not a replacement for source code. It is a persistent reasoning substrate that helps the agent decide which source it needs to inspect and what else could be affected by a change.

Redzam also records where its graph is incomplete. A file that failed to parse must not silently look like a file with nothing relevant inside it. Making uncertainty visible is essential when an AI is allowed to propose real code changes.

How I built it

Redzam is a TypeScript and Node.js monorepo built around four main parts:

1. Mechanical code indexing: SWC parses TypeScript and JavaScript and extracts structural facts deterministically.
2. Semantic enrichment: Gemini adds descriptions and domain context where mechanical parsing alone is insufficient.
3. Versioned architecture storage: PostgreSQL stores graph metadata for each workspace and commit, including explicit indexing gaps.
4. Agentic interaction: An embedded React widget communicates with a Hono backend running a Google ADK agent. The agent can query the graph and fetch specific source files on demand.

The widget is distributed as a self-contained script and runs inside a Shadow DOM, so it can be embedded in another React application without interfering with the host page.

Google ADK manages the agent’s tool-calling loop. The backend translates ADK events into a small Server-Sent Events protocol so the user can see responses and activities such as graph queries and source inspection as they happen.

Gemini is used where reasoning is valuable; mechanical facts such as functions, imports, calls, source positions, and dependencies are extracted with deterministic tooling rather than asking a model to guess them.

The system is packaged for Google Cloud Run. A GitHub App provides the foundation for least-privilege repository access, while PostgreSQL stores graph and workflow metadata.

Repository source is not persisted by Redzam. Enrichment happens in CI, where the source already exists, and exact source files are fetched transiently from GitHub when the agent needs them.

Challenges

The hardest challenge was not generating code. It was deciding what an agent must know before it should be trusted to change code.

Cross-file calls, ambiguous symbols, instance-created dependencies, side effects, incremental indexing, and repository drift all make blast-radius analysis difficult. I had to design the graph so it could represent uncertainty instead of inventing relationships.

Another challenge was separating three kinds of authority:

• A requester may describe and confirm the desired product outcome.
• A repository owner decides which paths and operations the agent may access.
• A human reviewer decides whether the resulting pull request should be merged.

Integrating Google ADK into an embeddable browser experience also required translating its event stream into a stable client protocol while preserving conversation history, tool activity, and usage information.

Finally, working alone forced me to be disciplined about scope. Redzam has several natural directions—including MCP access for coding agents and automated investigation of runtime errors—but I chose one primary story for the hackathon: turning an in-app product request into a reviewable code change.

What I learned

The most important lesson was that agent quality is not only a model problem.

A capable model still needs:

• A reliable representation of the system
• Tools with narrow, explicit capabilities
• Revision-aware evidence
• Visible uncertainty
• Durable workflow state
• Idempotent external actions
• Clear authorization boundaries
• A human-controlled final step

I also learned that mechanical analysis and AI reasoning work best together. Static extraction provides dependable facts; Gemini provides semantic interpretation. Neither is sufficient alone.

The conversations I had with developers building AI products reinforced this. Their recurring difficulty was not producing an impressive first response—it was making an agent dependable enough to participate in a real engineering workflow.

What I am proud of

I am proud that Redzam is not another chat interface placed in front of repository search.

The project already includes deterministic indexing, semantic enrichment, versioned graph ingestion, explicit coverage reporting, an embedded ADK-powered conversation, graph and source tools, durable conversation storage, GitHub App authentication foundations, and an extensive automated test suite.

More importantly, it has a clear safety boundary: Redzam creates proposals with evidence. It does not quietly turn a user request into an unreviewed production change.

What’s next

The next step is to complete and harden the autonomous GitHub execution layer: structured work-item creation, durable Taskmaster run state, repository guardrail enforcement, idempotent branch and pull-request operations, CI observation, bounded repair, and requirement-level evidence.

After the primary request-to-pull-request workflow is reliable, the same architecture graph can support two additional interfaces:

• An MCP server that helps other coding agents understand repositories without repeatedly searching the entire codebase
• A runtime incident workflow that connects logs and stack traces to the responsible architecture and proposes repairs

The long-term goal is simple:

Make the path from product intent to a safe, reviewable code change dramatically shorter—without hiding the evidence or removing human control.

Codebase intelligence that acts.

Built With

• docker
• gemini/3.7-flash
• github-api
• github-apps
• google-cloud-run
• google-genai-sdk
• google/adk
• hono
• node.js
• postgressql
• react
• server-sent-events
• swc
• typescript
• vite
• vitest