Alpha Mimic: Multi-Agent Biomimicry Translation Platform

~200 Word Writeup

Alpha Mimic is a multi-agent biomimicry translation platform that converts biological research papers into Engineering-Grade Biomimicry Packets (EGBPs), structured engineering specifications with physics equations, parametric designs, verification protocols, and full provenance tracking.

Users upload biological research PDFs and describe an engineering problem. Ten Gemini 3 agents across five Cloud Run microservices process the papers through a structured pipeline: extracting evidence with confidence scores, classifying mechanisms against a 12-family ontology (covering strategies from optical extraction to hydrodynamic thrust), translating biological terms to physics variables with SI units and governing equations, synthesizing multi-organism contributions into unified designs, red-teaming results through a severity-graded critique with human-in-the-loop gating, and packaging everything into a downloadable EGBP with 8-layer provenance tracing every design decision back to source papers.

Built on Google ADK with ~40 FunctionTools reading and writing to Firestore, inter-service communication via A2A protocol (JSON-RPC 2.0), and a self-correcting renderer using ADK's SequentialAgent and LoopAgent patterns for Three.js geometry generation. Gemini 3 Pro handles complex paper analysis; Gemini 3 Flash powers downstream classification, synthesis, and critique.

Alpha Mimic bridges the biology-to-engineering translation gap, turning what nature already solved into specifications engineers can actually build.

Comprehensive Writeup

Upload biological research papers. Describe an engineering problem. Ten Gemini 3 agents translate nature's solutions into Engineering-Grade Biomimicry Packets โ€” complete with physics equations, parametric designs, verification protocols, and full provenance tracking back to the original papers.


๐ŸŒฟ Inspiration

Nature has spent 3.8 billion years solving engineering problems, thermal regulation, impact resistance, drag reduction, optical extraction and the solutions are documented in thousands of biological research papers. But engineers can't use them.

The biology-to-engineering translation gap is real. A materials scientist reading a paper on termite mound ventilation sees fascinating biology but no governing equations, no SI units, no manufacturing constraints, no test protocols. The knowledge exists but the translation doesn't.

Alpha Mimic closes that gap. It doesn't just summarize papers, it builds a complete engineering translation pipeline: extracting evidence, classifying mechanisms against a structured ontology, mapping biological terms to physics variables with governing equations, synthesizing multi-source designs, red-teaming the results, and packaging everything into a standardized deliverable that an engineer can actually use.

The output isn't a chatbot response. It's an Engineering-Grade Biomimicry Packet (EGBP), a structured specification with eight layers of provenance tracking, from the original paper citation all the way through to the verification test protocol.


๐Ÿ”ฌ What It Does

Alpha Mimic is a multi-agent biomimicry translation platform. Users upload biological research papers, describe their engineering problem, and the system produces a complete engineering specification derived from biological mechanisms.

Core Pipeline

๐Ÿ“„ Paper Upload & Organism Discovery: Users upload up to 10 biological research PDFs and describe their engineering challenge (e.g., "Design a passive cooling system for data centers"). The system discovers organisms studied in the papers and displays them with their biological strategies.

๐Ÿ” Evidence Extraction: Gemini 3 Pro reads each paper, extracting mechanistic claims with citations, page references, confidence scores, organisms, and quantitative data. Each evidence unit links back to its source paper.

๐Ÿงฌ Mechanism Classification: Evidence is classified against a 12-family mechanism ontology (M01โ€“M12) covering biological strategies from graded-index optical extraction to hydrodynamic lift. Each family includes organisms, structures, functions, governing equations, physics variables, application domains, materials, manufacturing methods, and failure modes.

โšก Physics Translation: Biological terms are mapped to physics variables with SI units, governing equations, dimensionless groups, and failure modes. "Mound height" becomes "Stack height H (m)"; "thermal mass" becomes "Volumetric heat capacity ฯCp (J/mยณยทK)".

๐Ÿ”„ Domain Transfer: Mechanisms are matched to engineering application domains. The system evaluates feasibility and identifies where biological strategies have already been successfully transferred (e.g., moth-eye anti-reflective coatings achieving 0.5% reflectance for Nippon Sheet Glass).

๐Ÿงช Multi-Source Synthesis: When multiple organisms contribute to the solution, the system analyzes synergies and conflicts between mechanisms, calculates weighted source contributions, and develops an integration strategy that combines complementary biological approaches.

๐Ÿ—๏ธ Unified Design Generation: All synthesized mechanisms converge into ONE unified parametric design with geometry specifications, materials envelopes, manufacturing options, and performance hypotheses with explicit falsification criteria.

๐Ÿ›ก๏ธ Red-Team Critique (HITL Gating): Before packaging, the Critic Agent evaluates the design against validation rules from the ontology, flagging issues at three severity levels:

  • BLOCKING โ€” Missing critical physics variables, unaddressed failure modes, unsupported claims, safety concerns. Stops the pipeline and triggers human review.
  • WARNING โ€” Weak evidence support, scale translation uncertainties. Flagged but pipeline continues.
  • SUGGESTION โ€” Alternative materials, additional test methods. Non-blocking improvements.

When blocking issues are found, the system enters a Human-in-the-Loop approval gate. Clinicians or engineers review the critique, approve, reject, or request revision. After 3 unsuccessful revision cycles, the system escalates to human decision.

โœ… Verification Planning: The Verification Planner creates test protocols with primary and secondary metrics, baselines (non-biomimetic, naive biomimetic, commercial), minimal and high-fidelity test procedures, equipment lists, sample sizes, and pre-registered acceptance criteria.

๐Ÿ“Š Provenance Tracking: An 8-layer provenance graph traces every design decision:

  • Layer 0: Sources (organisms, papers, DOIs)
  • Layer 1: Evidence (extracted claims with citations)
  • Layer 2: Mechanisms (M01โ€“M12 hypotheses)
  • Layer 3: Physics (equations, variables, units)
  • Layer 4: Transfer (application domains)
  • Layer 5: Synthesis (combined sources)
  • Layer 6: Design (unified specification)
  • Layer 7: Verification (test protocols)

Every node in the design connects back to a specific claim in a specific paper. No orphaned decisions.

๐Ÿ“ฆ EGBP Output: The final Engineering-Grade Biomimicry Packet includes: header with problem statement, source attribution with contribution percentages, biological insights, physics translation with equations, unified design specification, quality assurance results, verification plan, and provenance graph. Available as a downloadable ZIP with all artifacts.

๐ŸŽจ 3D Visualization: A self-correcting renderer generates procedural Three.js geometry code from the design specification. A code generator writes geometry, a critic reviews it against a checklist, and they iterate up to 3 times until the code passes QA, or the system falls back to a robust template. The 3D viewer supports rotation, zoom, and parameter inspection.

Supporting Features

๐Ÿ“š Mechanism Library: Browse all 12 mechanism families with organisms, equations, variables, application domains, successful transfers, and related families. Each entry includes real-world examples (e.g., abalone nacre is 3000ร— tougher than pure aragonite; mantis shrimp dactyl clubs withstand 1500N impacts).

๐Ÿ“‹ Analysis Dashboard: View all past analyses with status, timestamps, organisms discovered, and mechanisms found. Search and filter by problem statement, organism, or mechanism family.

๐Ÿ” Analysis Viewer: Re-open any completed analysis to browse all output tabs, evidence, mechanisms, physics, synthesis, design, critique, verification, provenance, and EGBP, with the same detail as the original run.

๐Ÿฅ Service Health Monitor: Real-time health status for all backend services with adaptive polling (2-minute intervals when healthy, 30-second intervals when degraded).


๐Ÿ—๏ธ How I Built It

Architecture

Backend Services:

  • 5 Cloud Run microservices + 1 renderer service, each handling a distinct pipeline stage
  • 10 specialized AI agents orchestrated using Google Agent Development Kit (ADK)
  • Inter-service communication via Google's Agent-to-Agent (A2A) protocol using JSON-RPC 2.0
  • Real-time data persistence via Firestore with subcollection-based data model
  • PDF storage and EGBP package hosting via Firebase Cloud Storage with signed URLs

Gemini 3 Integration:

  • Gemini 3 Pro (gemini-3-pro-preview) for the Evidence Extractor โ€” complex reasoning over full research papers
  • Gemini 3 Flash (gemini-3-flash-preview) for all downstream agents โ€” cost-efficient mechanism classification, physics translation, design synthesis, critique, and packaging
  • Gemini 3 Pro for the Renderer's code generator, complex Three.js code generation
  • Gemini 3 Flash for the Renderer's template fetcher, code critic, and finalizer

ADK Patterns:

  • Agent with FunctionTool โ€” all 5 pipeline services
  • SequentialAgent โ€” Renderer service orchestration (Template Fetch โ†’ Generate/Critique Loop โ†’ Finalize)
  • LoopAgent โ€” Renderer's self-correcting code generation cycle (max 3 iterations)
  • LlmAgent โ€” Renderer sub-agents (template_fetcher, code_generator, code_critic, finalizer)

๐Ÿค– Agent Architecture

Ingestion Service (Port 8001)

  • Evidence Extractor (Gemini 3 Pro): Reads PDFs via PyMuPDF, extracts structured evidence with claims, citations, confidence scores, organisms, and quantitative data. Also extracts and corrects paper metadata (authors, year, title) that PDF internal metadata gets wrong.

Analysis Service (Port 8002)

  • Mechanism Scout: Classifies evidence against the 12-family ontology using taxonomy search, keyword matching, and mechanism detail lookup
  • Physics Translator: Maps biological terms to physics variables with SI units, retrieves governing equations and dimensionless groups, documents failure modes
  • Transfer Agent: Matches mechanisms to application domains, evaluates feasibility, retrieves successful real-world transfers

Synthesis Service (Port 8003)

  • Synthesis Agent: Analyzes mechanism synergies across multiple organisms, calculates weighted source contributions, identifies conflicts requiring resolution
  • Design Synthesizer: Generates ONE unified parametric design with geometry type selection, materials envelope, manufacturing constraints, and performance hypotheses

Review Service (Port 8004)

  • Critic Agent: Red-teams the design against ontology validation rules, creates severity-graded critiques, triggers HITL gating for blocking issues, generates approval tokens, sends review emails
  • Verification Planner: Creates test protocols with metrics, baselines, procedures, equipment lists, and pre-registered acceptance criteria

Packaging Service (Port 8005)

  • Provenance Tracker: Builds the 8-layer provenance graph connecting every design decision to source papers
  • Artefact Packager: Generates the complete EGBP, saves to Firestore and Cloud Storage, creates downloadable ZIP with signed URLs

Renderer Service (Port 8006)

  • Template Fetcher (LlmAgent, Flash): Finds the closest geometry template for the design
  • Code Generator (LlmAgent, Pro): Writes procedural Three.js generateCustomGeometry() function
  • Code Critic (LlmAgent, Flash): Reviews code for syntax errors, function naming, and Three.js best practices
  • Finalizer (LlmAgent, Flash): Packages approved code or falls back to robust template if generation failed

ADK FunctionTools

~40+ custom FunctionTools across services, each wrapping real operations: Ingestion Tools:

  • extract_text_from_pdf โ€” Downloads PDF from Cloud Storage, extracts text via PyMuPDF
  • extract_images_from_pdf โ€” Extracts figures with base64 encoding for analysis
  • get_papers_from_library โ€” Retrieves paper metadata from user's Firestore library
  • save_extracted_evidence โ€” Persists evidence to Firestore and updates paper metadata
  • initialize_analysis_tool โ€” Creates the master analysis document

Analysis Tools:

  • get_taxonomy_tool โ€” Returns all 12 mechanism families from the ontology
  • search_mechanisms_tool โ€” Keyword search across organisms, structures, functions
  • get_mechanism_details_tool โ€” Full mechanism details including equations, variables, domains
  • get_evidence_tool โ€” Retrieves evidence from Firestore subcollection
  • save_mechanism_tool โ€” Persists mechanism hypothesis to Firestore
  • get_physics_equations_tool โ€” Returns governing equations for a mechanism
  • get_physics_variables_tool โ€” Returns biologyโ†’physics variable mappings with SI units
  • get_failure_modes_tool โ€” Returns mechanism failure modes
  • save_physics_tool โ€” Persists physics model to Firestore
  • get_application_domains_tool โ€” Returns application domains with specific use cases
  • find_mechanisms_for_domain_tool โ€” Reverse lookup: domain โ†’ applicable mechanisms
  • get_analysis_problem_tool โ€” Retrieves problem definition from Firestore
  • save_transfer_tool โ€” Persists transfer map to Firestore
  • trigger_synthesis_service_tool โ€” Sends A2A message to Synthesis Service

Synthesis Tools:

  • get_analysis_data_tool โ€” Retrieves all pipeline data from Firestore subcollections
  • get_mechanism_synergies_tool โ€” Analyzes synergies between mechanism families
  • calculate_contributions_tool โ€” Computes weighted source contribution percentages
  • save_synthesis_tool โ€” Persists synthesis result
  • generate_geometry_tool โ€” Creates parametric geometry specification
  • create_design_tool โ€” Builds unified design with deduplication
  • save_design_tool โ€” Persists unified design
  • trigger_review_service_tool โ€” Sends A2A message to Review Service

Review Tools:

  • get_design_for_review_tool โ€” Retrieves design with all supporting data
  • get_validation_rules_tool โ€” Gets ontology validation rules for a mechanism
  • create_critique_tool โ€” Creates severity-graded critique
  • save_critique_tool โ€” Persists critique to Firestore
  • create_hitl_request_tool โ€” Generates approval tokens
  • send_email_tool โ€” Sends HITL review emails via SendGrid
  • create_protocol_tool โ€” Generates verification test protocol
  • save_protocol_tool โ€” Persists verification plan
  • trigger_packaging_service_tool โ€” Sends A2A message to Packaging Service

Packaging Tools:

  • get_complete_analysis_tool โ€” Retrieves all data for final packaging
  • build_provenance_tool โ€” Constructs 8-layer provenance graph
  • save_provenance_tool โ€” Persists provenance graph
  • generate_egbp_tool โ€” Creates the complete EGBP specification
  • save_egbp_tool โ€” Saves EGBP to Firestore and Cloud Storage
  • create_package_tool โ€” Generates downloadable ZIP with signed URL

Renderer Tools:

  • get_geometry_templates_tool โ€” Returns available Three.js geometry templates
  • get_mechanism_geometry_mapping_tool โ€” Maps biological mechanisms to 3D geometry strategies
  • generate_threejs_code_tool โ€” Fallback template-based code generation

A2A Protocol

Services communicate via JSON-RPC 2.0 messages following Google's Agent-to-Agent protocol:

  • Each service exposes an agent card at /.well-known/agent-card.json
  • Inter-service calls use RemoteA2aAgent from the ADK
  • Service discovery via environment variables (Cloud Run URLs in production, localhost in development)
  • Messages carry analysis_id, from_service, to_service, and action-specific payloads
  • 300-second timeout for long-running agent operations

Mechanism Ontology

The knowledge backbone: 12 mechanism families (M01โ€“M12) with structured data:

ID Family Example Organisms
M01 Graded-Index Optical Extraction Firefly, Moth, Glasswing Butterfly
M02 Hierarchical Fracture Deflection Abalone, Mantis Shrimp, Bone
M03 Impact Energy Distribution Woodpecker, Turtle Shell, Coconut
M04 Reversible Dry Adhesion Gecko, Tree Frog, Spider
M05 Drag Reduction via Riblets Shark, Dolphin, Sailfish
M06 Superhydrophobic Surfaces Lotus, Water Strider, Namib Beetle
M07 Structural Coloration Morpho Butterfly, Peacock, Jewel Beetle
M08 Passive Thermal Regulation Termite, Elephant, Camel
M09 Self-Healing Materials Human Skin, Sea Cucumber, Tree Bark
M10 Acoustic Dampening Owl, Moth Wings, Spider Silk
M11 Puncture Resistance Porcupine Fish, Armadillo, Pangolin
M12 Hydrodynamic Lift/Thrust Humpback Whale, Boxfish, Penguin

Each family includes: organisms with Latin names and notable features, structures, functions, scale levels (nano/micro/meso/macro), failure modes, governing equations with formulas, physics variables with biologyโ†’engineering mappings and SI units, dimensionless groups, application domains with specific use cases, materials by category, manufacturing methods, primary and secondary metrics with measurement methods, baseline types, test methods, successful real-world transfers with companies and improvement data, related families, and keywords.

Data Model

25+ Pydantic models defining the complete data schema:

  • AnalysisRecord โ€” Master document with status tracking, agent run logs, and output references
  • EvidenceUnit โ€” Claims with citations, confidence scores, modality, page references
  • MechanismHypothesis โ€” Classification with supporting evidence linkage and competing hypotheses
  • PhysicsModel โ€” Variables, equations, dimensionless groups, scale levels, failure modes
  • TransferMap โ€” Application domain candidates with feasibility assessment
  • SynthesisResult โ€” Source contributions, synergies, conflicts, integration strategy
  • UnifiedDesign โ€” Parametric geometry, materials envelope, manufacturing constraints, performance hypotheses with falsification criteria
  • Critique โ€” Severity-graded issues, HITL tracking, retry counting
  • VerificationPlan โ€” Metrics, baselines, test protocols, acceptance criteria
  • ProvenanceGraph โ€” Nodes and edges across 8 layers
  • EngineeringGradeBiomimicryPacket โ€” Final artifact bundle

Frontend

React + TypeScript + Vite + Tailwind CSS with:

  • Real-time Firebase listeners for pipeline progress
  • Adaptive service health polling (2-minute/30-second intervals)
  • 11 output tabs (Problem, Sources, Evidence, Mechanisms, Physics, Synthesis, Design, Critic, Verification, Provenance, EGBP)
  • Three.js 3D viewer with procedural geometry rendering
  • Google Authentication via Firebase Auth
  • Paper upload to Firebase Cloud Storage
  • Analysis history with search, filter, and re-open
  • Mechanism Library browser with 12 families
  • Dynamic organism discovery from uploaded papers

Google Product Integration

โ˜๏ธ Google Cloud:

  • Cloud Run: Hosts 6 microservices (ingestion, analysis, synthesis, review, packaging, renderer)
  • Firestore: Real-time analysis data, evidence, mechanisms, designs, provenance, user papers
  • Firebase Cloud Storage: PDF uploads, EGBP packages with signed download URLs
  • Firebase Authentication: Google Sign-In for user management
  • Google Agent Development Kit (ADK): Multi-agent orchestration with Agent, SequentialAgent, LoopAgent, LlmAgent, FunctionTool
  • A2A Protocol: Inter-service agent communication via JSON-RPC 2.0
  • Vertex AI: Powers ADK agents with Gemini 3 Pro and Gemini 3 Flash

๐Ÿ› ๏ธ Google Developer Tools:

  • Google AI Studio: Prototyping agent prompts and ontology design

๐Ÿ’ช Challenges I Ran Into

๐Ÿง  Analysis ID Propagation: The hardest bug was agents losing the analysis_id between tool calls. Because ADK agents receive messages as strings, the agent had to parse JSON, extract the ID, and carry it through every tool call. This required explicit "STEP 0: Parse the JSON and extract analysis_id" instructions in every agent prompt, with concrete examples showing exactly how to use the ID.

๐Ÿ”„ Sub-Agent Consolidation: Initially designed as 10 separate ADK Agent instances, the architecture proved more reliable when each service used one root agent with combined instructions for its sub-stages. True ADK sub-agent delegation (SequentialAgent, LoopAgent) worked well for the renderer but added complexity for the text-based pipeline services where sequential prompt execution was more predictable.

๐Ÿ“‹ PDF Metadata Lies: PDF internal metadata is unreliable, the "author" field often contains the publishing software name ("Arbortext Publisher"), and "creationDate" is the PDF export date, not the publication year. The fix: never trust PDF metadata for bibliographic data, let the AI agent extract real authors and year from the paper content itself.

๐ŸŽฏ Mechanism Deduplication: When multiple organisms share the same mechanism family (e.g., three organisms all classified as M08), the design tool needed to create unique identifiers (M08-elephas, M08-camelus, M08-odontotermes) while the agent kept passing duplicate "M08,M08,M08" strings. This required explicit extraction instructions showing agents exactly how to build the mechanism string from the array.

๐Ÿ”— A2A Cold Starts: Cloud Run services have cold start delays of 10-30 seconds. A2A calls between services would timeout during these delays. The fix: 300-second HTTP timeouts on inter-service calls, warm-up pings on frontend load, and adaptive health polling that detects degraded services early.

๐ŸŽจ 3D Generation Reliability: LLM-generated Three.js code is brittle. The self-correcting SequentialAgent โ†’ LoopAgent pattern (generate โ†’ critique โ†’ iterate, max 3 cycles) with template fallback ensures the 3D viewer never shows a broken scene, even when Gemini produces invalid geometry code.


๐Ÿ† Accomplishments I'm Proud Of

Technical:

  • Built a genuine multi-agent pipeline with 10 agents, ~40+ FunctionTools, and A2A inter-service communication, not a prompt wrapper
  • Designed a structured ontology of 12 mechanism families with governing equations, physics variables, and real-world transfer examples that agents actually use for classification
  • Implemented a self-correcting renderer using ADK's SequentialAgent and LoopAgent patterns with template fallback
  • Created 25+ Pydantic models defining a production-grade data schema with proper validation, enums, and nested relationships
  • Achieved 8-layer provenance tracking from source paper to verification protocol โ€” no orphaned design decisions

Domain Knowledge:

  • Encoded genuine biomimicry knowledge: real organisms, real equations, real SI units, real application domains, real successful transfers with company names and improvement percentages
  • The ontology isn't lorem ipsum, it's a structured knowledge base that could serve as the foundation for a real biomimicry engineering tool

Architecture:

  • 5 microservices + renderer deployed on Cloud Run with proper A2A protocol, health monitoring, and CORS
  • Frontend-to-backend integration using real A2A JSON-RPC 2.0 messages, not REST wrappers
  • HITL gating with approval tokens, email notifications, and retry counting for production safety

๐Ÿ“š What I Learned

๐Ÿค– Google ADK Depth: ADK's FunctionTool pattern is powerful for grounding LLM agents in real data โ€” the key insight was that agents need tools that both read and write, creating a feedback loop through Firestore. The SequentialAgent and LoopAgent patterns in the renderer taught me how to build self-correcting AI systems.

๐Ÿ”— A2A Protocol: Implementing JSON-RPC 2.0 inter-service messaging showed me the future of multi-agent architectures โ€” agents as services that discover and communicate with each other via agent cards. The protocol is simple but the implications for composable AI systems are enormous.

๐Ÿงฌ Domain Engineering: Building the mechanism ontology was the most intellectually rewarding part. Translating biological knowledge into structured data (equations, variables, failure modes, application domains) required deep reading across biology, physics, and materials science. The ontology became the backbone that made every agent smarter.

๐Ÿ“ LLM Reliability Patterns: LLM outputs are probabilistic. Every agent needed defensive JSON parsing, explicit step-by-step instructions, concrete examples, and save-tool verification. The renderer's generateโ†’critique loop is a pattern I'll use in every future LLM system.


๐Ÿ”ฎ What's Next for Alpha Mimic

Immediate Enhancements:

  • Gemini multimodal: Send paper figures directly to Gemini Pro for visual analysis (SEM micrographs, cross-section diagrams, material structure images)
  • Autonomous A2A cascade: Enable the full agent-to-agent pipeline where services trigger downstream services autonomously without frontend orchestration
  • Expanded ontology: Grow from 12 to 30+ mechanism families covering additional domains (biomechanics, sensing, camouflage, water collection)

Long-Term Vision:

  • CAD integration: Export parametric designs directly to SolidWorks, Fusion 360, or OpenSCAD
  • Literature discovery: Automatically search for relevant papers given an engineering problem, rather than requiring manual upload
  • Collaborative workspace: Multiple engineers annotating and refining EGBP outputs together
  • Verification tracking: Connect test protocol outputs back to the design, closing the loop from paper to prototype to measured performance

Research Directions:

  • Evaluate EGBP quality against expert biomimicry translations
  • Study whether structured provenance tracking increases engineer trust in AI-generated designs
  • Explore whether the ontology can be crowd-sourced and expanded by the biomimicry research community

๐Ÿงฌ 10 agents, 5 services, 12 mechanism families, 8 layers of provenance, but at its core, Alpha Mimic does one thing: turns what nature already solved into something engineers can actually build.

Built With

Share this project:

Updates