Quipu

Quipu turns real-world signals into enterprise-aligned software — grounding AI agents in organization specific knowledge and orchestrating them through detection, build, deployment and production.

Comment

Inspiration

Software engineering is not just coding or development. It starts with a customer asking for something, a support team noticing the same problem repeatedly, or a production system showing signs that something is wrong. Today, these signals are often disconnected from the engineering lifecycle. Product teams collect feedback, developers work from tickets, architects design solutions, QA validates them, DevOps deploys them, and SREs monitor production — with humans stitching the entire process together. We wanted to build a system that connects these worlds. Quipu is an AI control plane that starts with the signal behind the work and follows it all the way through engineering and production. Our inspiration was not simply to build another coding agent. We wanted specialized AI agents that could act as companions to Product Managers, Architects, Developers, QA engineers, DevOps engineers, and SREs — while remaining grounded in an organization's own knowledge, standards, and engineering practices. The bigger idea was a closed loop: Real-world signal → Detection → Human decision → Engineering → Production → Evidence → Continuous feedback.

What it does

Quipu connects the product-to-production lifecycle through specialized AI agents and a deterministic orchestration layer. It can ingest signals such as customer feedback, support tickets, and production telemetry. A Detection Agent analyzes accumulated evidence and identifies opportunities or incidents. For a feature opportunity: Customer/Support Signal → Detection → Human Approval → Planning → Architecture → Code Generation → Testing → Deployment → Monitoring For a production incident: Production Telemetry → Detection → Incident Resolution → Human/Policy Authorization → Remediation → Verification → Monitoring The same SDLC pipeline is reused for both paths. Each stage produces a persistent artifact — Plan, Architecture, Code Change, Test Result, and Deployment — creating an auditable artifact lineage rather than relying on hidden agent-to-agent conversation. Quipu also provides:

  1. Enterprise knowledge grounding so agents can align solutions with organizational standards and context.
  2. Human-in-the-loop decision points before consequential actions.
  3. Evidence-first verification, where actual system state is used to validate agent claims.
  4. Workflow retry and recovery, allowing failed workflows to resume from the failed stage without recreating successful upstream work.
  5. Production monitoring and incident resolution to close the loop between engineering and production. The result is not one giant autonomous agent, but a team of specialized AI companions coordinated by a controlled engineering system.

How we built it

Quipu is built around a simple architectural principle: LLMs reason. The control plane decides. Application code verifies. The core is a deterministic OrchestrationService that controls workflow state, stage transitions, artifacts, authorization boundaries, retries, and recovery. Inside that control plane are specialized agents built with Google ADK and Gemini:

  1. Detecting Agent
  2. Planning Agent
  3. Architecture Agent
  4. Codegen Agent
  5. Testing Agent
  6. Deployment Agent
  7. Incident Resolution Agent
  8. Monitoring Agent The agents don't directly call each other. Instead, they communicate through persisted artifacts and workflow state. Our Google Cloud architecture uses:
  9. Cloud Run for the Quipu API and UI
  10. Cloud Run Worker Pool for the long-running signal consumer
  11. Pub/Sub for asynchronous signal ingestion
  12. Firestore for durable workflow, signal, detection, review, execution, and artifact state
  13. Gemini / Vertex AI + Google ADK for agent reasoning
  14. Cloud Monitoring and Cloud Logging for production telemetry
  15. Artifact Registry for container images
  16. Secret Manager for sensitive configuration
  17. Jira for engineering-system integration
  18. Agent Search to retrieve from the Knowledge base. The Knowledge Layer provides an abstraction through KnowledgeGateway, allowing agents to be grounded in organizational knowledge. The repository also contains the Google Search/Discovery Engine backend implementation, while the current default gateway remains an in-memory implementation. A major design principle throughout the system is evidence-first execution. Agents can propose what happened, but Quipu independently checks actual execution records, filesystem changes, test results, deployment state, and production telemetry wherever possible.

Challenges we ran into

The hardest part wasn't getting an LLM to generate an answer. It was building a system where multiple agents could safely participate in a real engineering lifecycle. We encountered several interesting challenges:

  1. LLM timeouts across a multi-stage workflow A single shared timeout was initially used across agents. Code generation exposed the problem when a legitimate LLM operation exceeded the shared 60-second limit. We introduced stage-specific timeout boundaries while keeping the original behavior for other agents.
  2. Reliable execution without trusting the LLM An agent saying "deployment succeeded" isn't sufficient. We designed the system so that important results are derived from actual execution state wherever possible.
  3. Recovering from partial workflows A workflow can fail halfway through the SDLC. We implemented workflow retry so that a failed workflow can be reopened at its failed stage while preserving its existing artifacts and workflow identity.
  4. Making the demo deterministic Real code generation, testing, and deployment can involve external systems and unpredictable execution times. For the hackathon, we introduced independently controlled demo modes for Codegen, Testing, and Deployment. These still produce normal workflow artifacts and are visibly marked as Demo execution, while real execution remains the default when the flags are disabled.
  5. Designing the production feedback loop Feature development and incident remediation shouldn't become two completely independent systems. We designed both to converge on the same controlled SDLC pipeline, allowing production problems to feed back into engineering work.

Accomplishments that we're proud of

We're particularly proud that Quipu evolved beyond a collection of AI agents into a production-ready control plane for engineering work. Specialized AI companions Quipu provides specialized AI companions for the different roles involved in the software lifecycle:

  1. Product → Detection & Planning
  2. Architecture → Architecture Agent
  3. Development → Codegen Agent
  4. QA → Testing Agent
  5. DevOps → Deployment Agent
  6. SRE → Monitoring & Incident Resolution Each agent focuses on a specific responsibility while the deterministic orchestration layer controls how those agents participate in the larger workflow. A deterministic control plane around LLM agents One of our biggest architectural accomplishments is separating AI reasoning from workflow control. The LLM agents reason about plans, architectures, code, tests, deployments, and incidents. The OrchestrationService remains deterministic and controls:
  7. workflow state
  8. stage transitions
  9. checkpoints
  10. artifact dependencies
  11. authorization boundaries
  12. retries and recovery
  13. execution tracking
  14. failure handling This gives us the flexibility of LLM-based reasoning without making the entire engineering lifecycle dependent on an unpredictable conversational chain. Persistent checkpoints & artifact lineage Every major stage creates a persisted artifact: Plan → Architecture → Code Change → Test Result → Deployment These artifacts form checkpoints in the workflow. If a later stage fails, Quipu doesn't have to throw away everything that happened before it. Successful work remains persisted and downstream stages can consume the existing artifacts. This gives the system:
  15. traceability
  16. Resumability
  17. Auditability
  18. Reproducibility
  19. Clear provenance between engineering decisions and their outputs Retry and recovery Failures are treated as first-class workflow states. Quipu can retry a failed workflow using the same workflow identity, reopening it at the failed stage rather than creating an entirely new workflow. For example: Architecture ✓ → Codegen ✗ becomes: Architecture ✓ → Retry → Codegen → Testing → Deployment The successful upstream artifacts remain intact. This is particularly important for agentic systems, where transient model, infrastructure, or external-service failures are expected to occur. Evidence-first execution We don't simply trust an LLM's statement that an operation succeeded. Where possible, Quipu independently derives outcomes from actual execution state. For example: generated filesystem changes are inspected rather than trusting the Codegen response test status is derived from execution records deployment status can be derived from the actual deployment state remediation verification uses production evidence rather than assuming that a remediation succeeded This creates a fundamental boundary: The agent proposes. The control plane executes. Evidence determines the outcome. Resilience and failure isolation We implemented reliability mechanisms around long-running AI workflows rather than relying on a single global timeout. Agent operations have appropriate timeout boundaries, and the system explicitly represents failures instead of allowing an individual LLM call to silently take down the entire workflow. We also implemented idempotent workflow operations, so repeated requests such as starting an already-started workflow or retrying a workflow don't accidentally create duplicate workflow state. Human-in-the-loop safety boundaries Quipu does not blindly turn an LLM recommendation into production action. Human review and authorization are explicit parts of the lifecycle, particularly around feature approval and consequential remediation. Combined with capability-gated tools and deployment safety controls, this gives organizations a controlled boundary between AI recommendation and real-world mutation. Production-oriented Google Cloud architecture Quipu is actually deployed on Google Cloud rather than existing only as a local prototype. The production architecture uses: Cloud Run + Cloud Run Worker Pool + Pub/Sub + Firestore + Gemini/Vertex AI + Google ADK + Cloud Monitoring + Cloud Logging + Artifact Registry + Secret Manager The signal ingestion path has been exercised using real Pub/Sub events and a deployed worker, with real Gemini-based detection and persistent workflow state. Enterprise knowledge grounding The Knowledge Layer gives agents access to organizational knowledge rather than treating every engineering problem as an isolated prompt. The goal is for an agent to answer not only: "What solution could work?" but: "What solution is appropriate for this organization, given its standards, architecture, policies, and existing knowledge/capabilities?" The architecture supports enterprise knowledge backends, including the Google Search/Discovery Engine integration, while the current default gateway uses the in-memory backend. Closed-loop product → production engineering Perhaps our biggest accomplishment is connecting two traditionally separate worlds. A feature can begin as: Customer signal → Detection → Human decision → Engineering → Production while a production problem can become: Telemetry → Detection → Incident Resolution → Authorized Remediation → Engineering → Verification Both ultimately use the same controlled SDLC pipeline. This means Quipu isn't simply an AI coding assistant. It is a continuous engineering control plane. Production-ready by design We deliberately designed Quipu around the requirements of a real engineering environment: durable state + asynchronous ingestion + deterministic orchestration + persistent checkpoints + artifact lineage + human authorization + evidence-based verification + timeout isolation + idempotency + retry/recovery + security boundaries + production monitoring. The result is a system designed to move beyond a hackathon demonstration toward an enterprise engineering platform.

What we learned

We learned that building agentic systems is much more about orchestration and boundaries than simply giving an LLM more capabilities. A few lessons stood out:

  1. Determinism matters. LLMs are excellent at reasoning about ambiguous engineering problems, but workflow state, authorization, retries, artifact persistence, and stage transitions should remain deterministic.
  2. Agents need organizational context. A technically valid solution isn't necessarily the right solution for an organization. Enterprise standards, architecture conventions, testing practices, deployment policies, and historical context matter. That's why we designed the Knowledge Layer as a first-class part of the architecture.
  3. Evidence is more important than confidence. An agent can be highly confident and still be wrong. Wherever possible, Quipu checks reality instead of accepting the model's claim.
  4. Failure is a normal state, not an exceptional state. Real engineering workflows fail. Designing retry and recovery into the control plane is more valuable than pretending every agent call will succeed.
  5. The most interesting agentic systems are closed loops. Generating code is only one part of software engineering. The real opportunity is connecting signals, decisions, implementation, deployment, and production feedback into one lifecycle. ## What's next for Quipu Our long-term vision is to turn Quipu into a continuous engineering control plane for enterprises. The next steps include: Enterprise Knowledge at scale Connect the Knowledge Layer to enterprise search and retrieval systems such as Google Cloud's Discovery Engine so agents can reason over organizational standards, architecture decisions, runbooks, documentation, and historical engineering knowledge. Full production build pipeline Extend the workflow with automated containerization, image building, registry publishing, and deployment of generated changes — turning the current controlled deployment integration into a complete production build pipeline. Deeper incident remediation Expand the production loop so that real incidents can move from detection through diagnosis, authorized remediation, deployment, and fresh telemetry-based verification as one continuously operating loop. Richer engineering intelligence Use the accumulated signals, artifacts, decisions, incidents, and production outcomes to identify recurring engineering patterns and opportunities for improvement. More human-facing agent companions Make each specialized agent directly useful to its corresponding role — allowing a PM, architect, developer, QA engineer, DevOps engineer, or SRE to work with their AI companion while Quipu maintains consistency across the entire lifecycle. Ultimately, we want Quipu to move engineering organizations from: "AI helps me write code" to: "AI helps my organization understand what needs to change, decide how it should change, safely execute that change, and learn from what happens in production."

Built With

Share this project:

Updates

Submission history