WeaveHacks 2: Building ¡alacard!, the Self-Improving AI Agent Cookbook with Google ADK and W&B Weave

On the weekend of October 11–12, 2025, I participated in WeaveHacks 2: Self-Improving Agents Hackathon in San Francisco. Organized by Cerebral Valley and co-sponsored by Weights & Biases and Google Cloud, the hackathon had a unique twist: unlike typical Cerebral Valley events held at SHACK15 in the Ferry Building, this one was hosted directly inside Weights & Biases Headquarters.

I teamed up once again with Daniel Green—reconnecting after our LlamaCon / LlamaLinked project—and joined forces with Amine Lbath. Together, we set out to tackle one of the most frustrating bottlenecks in modern generative AI development: the brittle “last mile” of assembling, executing, and maintaining multi-tool Jupyter notebooks.

The result of our weekend sprint was ¡alacard! (Devpost project): an open-source instruction layer and agentic factory that composes, executes in isolated sandboxes, observes via deep telemetry, and autonomously repairs and self-improves Jupyter notebooks.

Our project propelled us into the Finals, where we had the privilege of pitching on stage at W&B HQ to an esteemed panel of judges that included Eugene Cheah, the co-creator and champion of the RWKV open-source architecture.

The Autonomous Weekend: Cruising SF in Waymo Robotaxis

Traveling between our hotel, team brainstorms, and the W&B headquarters felt like stepping directly into the future. Instead of dealing with parking or hailing traditional rideshares, we navigated San Francisco almost exclusively using autonomous Waymo robotaxis.

Riding in a driverless vehicle late Saturday night through foggy, winding SF streets while discussing multi-agent reinforcement loops was pure cyberpunk reality:

The next morning, we took another Waymo back to the office to finish our final push before the deadline:

(Riding an autonomous Waymo robotaxi through San Francisco on Sunday morning, October 12, 2025, heading into Weights & Biases HQ for our final sprint.)

The Problem: The “Last Mile” Minefield of Jupyter Cookbooks

Daniel Green’s professional focus is centered around AI education, cohort-based courses, and technical coaching. Drawing from his daily experience working with developers learning applied AI, Daniel highlighted an acute, universal pain point: putting together a reliable, working IPython or Jupyter notebook for complex AI systems is surprisingly rocky.

Modern AI agents don’t live in isolation. A realistic enterprise or production prototype rarely uses just a single API; it stitches together:

• Large Language Models (Google Gemini, Meta Llama, Anthropic Claude)
• Specialized search APIs (Tavily, Exa)
• Browser automation tooling (Browserbase Stagehand)
• Tool protocol layers (Mastra, Model Context Protocol)
• Observability and evaluation harnesses (W&B Weave, LangSmith)

When developers try to combine these disparate tools into a single notebook, they quickly descend into “Integration Hell”:

1. Dependency Clashes: Package A requires pydantic>=2.7, but Package B only works with pydantic<2.5.
2. API Drift: Fast-moving libraries release breaking changes weekly, rendering existing tutorials and documentation obsolete overnight.
3. Flaky Demos: Live workshop or client demos fall apart because an unhandled runtime exception or subtle type error crashes cell 14 of 20.
4. Siloed Knowledge: Every AI company provides cookbooks exclusively for their own models. There was no neutral, cross-platform hub where a developer could mix-and-match cards from different providers and be confident that the code would run.

We asked ourselves: What if an autonomous agentic system took a developer’s high-level system design, ran deep research on every individual library in the stack, synthesized the notebook, ran it inside a secure sandbox, and automatically repaired any failures?

Even more importantly: What if that agent didn’t just fix errors on the fly, but actually learned from previous runs to get smarter over time?

Team Roles & The ¡alacard! Symphony

To pull off such an ambitious vision in 24 hours, our team divided responsibilities cleanly:

• Daniel Green: Provided the foundational problem framing from his AI education background, guided the end-to-end user experience of notebook generation, contributed code, and spearheaded our public deliverables. Leveraging his deep expertise in generative video tools like OpenAI Sora, Daniel created our pitch video assets. He also generated an animated GIF for the Devpost submission thumbnail, which made ¡alacard! immediately pop in the Devpost project gallery.
• Amine Lbath: Built the core Notebook Synthesis Engine (the “Chef” agent), translating research briefs, dependency trees, and example snippets into coherent, beautifully formatted Jupyter notebooks (.ipynb) with complete narrative markdown and executable code cells.
• Csaba Tóth: Engineered the Deep Research & Technology Discovery Pipeline powered by Google ADK (Agent Development Kit). I built the multi-source parallel retrieval system across Model Context Protocol (MCP) servers and APIs, designed the LLM-as-a-Judge validation loops, instrumented end-to-end tracing into W&B Weave’s OpenTelemetry (OTEL) telemetry database, and designed the cross-run historical trace retrieval for genuine self-improvement.

(Architectural overview of ¡alacard!: coordinating Google ADK multi-MCP discovery, Chef synthesis, Daytona sandbox execution, W&B Weave OTEL telemetry, runtime healing, and cross-run self-improvement.)

Deep Research with Google ADK & Multi-MCP Parallelism

Because Google Cloud was one of the premier sponsors of WeaveHacks 2, we chose the newly released Google ADK (Agent Development Kit) as our core orchestration framework.

Google ADK provides first-class primitives for structuring agentic workflows:

• SequentialAgent: For linear, staged pipelines.
• ParallelAgent: For concurrent fan-out tasks.
• LoopAgent: For iterative discovery loops with dynamic exit conditions.
• LlmAgent: For model-driven reasoning and structured JSON output.

Our discovery pipeline began with a high-level JSON “Recipe”:

{
  "use_case": "Autonomous web research and financial data synthesis",
  "models": ["gemini-2.5-pro", "meta-llama/llama-3.1-70b-instruct"],
  "technologies": ["tavily-python", "stagehand", "wandb-weave"]
}

The discovery workflow operated in coordinated stages:

1. Technology Identification: The TechnologyIdentifierAgent analyzed the use case and broken down the input into explicit, isolated technologies, resolving transitive dependencies and verifying package names.
2. Parallel Multi-MCP Retrieval: For each identified technology, the orchestrator spawned parallel discovery workers. Using Google ADK’s McpToolset (StdioConnectionParams and SseConnectionParams), our agents connected to multiple Model Context Protocol servers simultaneously:
   • Context7 MCP: Queried official, up-to-date documentation and API references.
   • DeepWiki MCP: Extracted code patterns, repository READMEs, and implementation examples from GitHub.
   • Tavily API: Searched the live web for the newest patch notes, version advisories, and bug workarounds.
   • Hugging Face API: Pulled model cards, parameter sizes, and tokenizer nuances for any requested open-weight models.
3. Semantic Reranking: Raw search results often introduce noise. Our RerankerAgent scored each retrieved snippet against the overarching use case, discarding off-topic discussions and keeping only actionable code patterns.
4. LLM-as-a-Judge Exit Gate: Each technology ran inside a LoopAgent. Rather than using a fixed iteration count, we deployed a JudgeAgent with structured output (JudgementResult). The judge evaluated whether the gathered documentation contained sufficient installation instructions, configuration syntax, and working code snippets. If sufficient, the loop terminated; if insufficient, the judge formulated targeted follow-up queries and triggered another retrieval pass.

Once all discovery loops cleared the judge, a comprehensive Markdown research dossier was compiled and delivered to Amine’s “Chef” agent for notebook generation.

Sandboxed Execution & The Runtime “Fixer” Loop

Generating code is only half the battle. Anyone who has copied AI-generated Python code into a terminal knows that hallucinations and minor syntax mistakes happen frequently.

To ensure every ¡alacard! notebook was guaranteed to run, we integrated Daytona:

• Rather than running arbitrary user code on local machines or hackathon laptops, notebooks were dispatched into sterile, isolated Daytona cloud sandboxes.
• The notebook cells executed in sequential order, capturing stdout, stderr, cell execution times, and return values.

If any cell threw an exception (e.g. an ImportError, mismatched API argument, or runtime failure), our automated “Fixer” Agent was triggered:

1. It inspected the failed cell and its traceback.
2. It queried the W&B Weave execution trace to understand previous successful steps and current environment state.
3. It consulted Vertex AI or W&B Inference to generate a minimal, surgically targeted code patch.
4. It applied the diff into the Daytona sandbox and re-executed the cell.
5. This loop repeated until the entire notebook executed cleanly with a complete green status.

Elevating Correction to Self-Improvement: Learning from History

Here is where the true essence of the hackathon comes into play. The event was not called ErrorFixingHacks; it was called WeaveHacks: Self-Improving Agents.

There is a fundamental difference between reactive error correction and true self-improvement:

• Reactive Error Correction: An agent runs, encounters an error, reads the traceback, retries with a patch, and eventually succeeds. But when you ask it to perform the same task tomorrow, it starts from zero. It makes the exact same initial mistake, hits the exact same error, and burns the exact same tokens fixing it again.
• Self-Improvement: The agent retains memory of previous runs. When confronted with a new task, it recalls past successes and failures, proactively chooses packages and patterns that worked, avoids proven pitfalls, and executes with higher accuracy and lower latency on the first attempt.

To build genuine self-improvement into ¡alacard!, we built two foundational pillars: Deep OpenTelemetry Tracing in W&B Weave and Historical Precedence Retrieval.

1. OpenTelemetry & Structured Signal Logging in Weave

We integrated W&B Weave not just as a pretty trace viewer, but as an operational telemetry database. By utilizing OpenTelemetry (OTEL) and Weave’s @weave.op() decorators, we captured high-dimensional execution metrics across every tool call and agent decision:

• Execution status (pass / fail)
• Normalized execution latency (latency_ms)
• Error classification taxonomy (error_class)
• Model token counts (prompt tokens, completion tokens)
• Code clarity and documentation score

We formulated an explicit scalar reward function for every generated notebook run:

where:

• $\text{pass} \in {0, 1}$ indicates whether the entire notebook executed without unhandled errors.
• $\text{latency}_{\text{norm}}$ penalizes excessively slow tool calls or model inference.
• $\text{retry}_{\text{norm}}$ rewards notebooks that succeeded on the first attempt without triggering the Fixer agent.
• $\text{clarity}$ is an automated evaluation score assessing docstrings, markdown explanations, and pinned package versions.

Every run was logged to W&B Weave as a complete State-Action-Reward (SAR) tuple: (state, action, R_before, R_after, ΔR, accepted).

(W&B Weave evaluation dashboard capturing structured agentic signals, latency metrics, and reward evaluations across iterative runs.)

2. The HistoryAnalysis Agent: Closing the Self-Improvement Loop

With our OTEL telemetry database populated, we developed a HistoryAnalysis agent (tested in our wb-alacard/wandb_test repository):

When a user submits a new recipe (for example, combining stagehand with gemini-2.5-pro):

1. Before invoking the LLM or generating search queries, the system queries the Weave database for similar past runs and tool calls.
2. It retrieves the historical records: Which dependency version ranges failed? Which search queries yielded unhelpful blog posts? Which prompt templates produced code that succeeded on the first try?
3. It dynamically constructs a Historical Precedence Context injected directly into the system prompt of the Chef and Discovery agents:

“Warning: Historical runs indicate that installing package foo without pinning bar<3.0 causes an immediate ABI conflict in Python 3.11. When configuring Mastra, use explicit HTTP transport instead of SSE based on run trace_id_8f4a21.”

By learning from its own operational history, ¡alacard! progressively minimized its Fixer invocations, reduced latency, and converged on stable notebook generation patterns over time.

A Hackathon War Story: Debugging Empty OTEL Payloads

No hackathon is complete without a deep technical hurdle. Late Saturday night, while hooking Google ADK’s native OpenTelemetry exporter to W&B Weave, we ran into an exasperating bug: the trace spans were showing up in Weave with perfect timings and hierarchies, but the input and output payloads were completely blank!

As documented in our internal notes (DEBUG_OTEL_TRACES.md and WEAVE_OTEL_STATUS.md), we traced the issue to an architectural discrepancy:

1. Google ADK’s OpenTelemetry instrumentation populated GenAI standard attributes (such as gen_ai.request.model, gen_ai.request.messages, and gen_ai.response.text).
2. Weave’s default span parser expected payloads in specific Weave attribute keys or serialized event structures.
3. Furthermore, payload size truncation limits were silently dropping large notebook code blocks.

We resolved this by combining ADK’s telemetry with targeted @weave.op() wrappers that explicitly bound input prompts, returned code artifacts, and custom evaluation metadata directly into the active span attributes before flushing. Seeing the full rich payloads, token counts, and reward signals finally illuminate the Weave dashboard at 3:00 AM was an exhilarating breakthrough!

The Finals & Presenting to Eugene Cheah (RWKV)

On Sunday afternoon, the judging committee announced the finalists, and ¡alacard! was selected to present on stage at W&B Headquarters!

Presenting our work was a thrill. Among the judges sitting in the front row was Eugene Cheah. I had met Eugene previously at an AI tech meetup in the Bay Area, and I have long been a passionate follower of RWKV—the innovative architecture combining the parallelizable training of Transformers with the constant-time, constant-memory inference of Recurrent Neural Networks (which I wrote about in my post, Chasing the Next Transformer Killer: RWKV, an Underrated LLM). Getting to pitch an autonomous agentic framework in front of someone pushing the boundaries of non-Transformer LLM architectures was a wonderful full-circle moment.

While we didn’t end up on the final top-three podium, making it to the finals and demonstrating a complete end-to-end pipeline—from high-level JSON recipe, through Google ADK multi-MCP research, into Daytona sandbox execution, and closing with Weave OTEL self-improvement—was an achievement our entire team was immensely proud of.

Project Repositories & Resources

All of the code, landing page designs, and testing harnesses developed during the hackathon are open-source and available on GitHub:

• Core ¡alacard! Factory: github.com/wb-alacard/alacard — The primary repository containing the Google ADK orchestrator, Daytona sandbox executor, Fixer healing loop, and Weave instrumentation.
• Enterprise Edition: github.com/wb-alacard/alacard-enterprise — Multi-tenant architecture and persistent notebook catalog.
• Landing Page: github.com/wb-alacard/Wbalacardlanding — Project landing page and interactive recipe explorer.
• Self-Improvement & Telemetry Test Harness: github.com/wb-alacard/wandb_test — Standalone prototype for testing W&B Weave OTEL trace retrieval, LLM-as-a-Judge loops, and historical precedence steering.
• Devpost Project: ¡alacard! on Devpost
• Event Overview: WeaveHacks 2 on Luma

A massive thank you to Cerebral Valley, Weights & Biases, and Google Cloud for organizing an exceptional hackathon, and to my fantastic teammates Daniel Green and Amine Lbath for an unforgettable weekend of collaborative engineering!