Hackathon Build

Agents propose, code decides.

July 18, 2026 · 6 min read

We built an AI system that writes client proposals, and we forbade it from doing the math.

That single design decision, more than any model choice or prompt trick, is what made Proposal Architect work. This is the story of the architecture we built for the Google for Startups AI Agents Challenge 2026, and of the rule that shaped it: agents propose, code decides.

Why proposals are a genuinely good agent problem

A commercial proposal is not one task. It is a chain of very different competencies: reading a messy brief, mapping requirements, designing an architecture, breaking the work down, estimating effort, pricing it, and writing the whole thing up in a form a client can actually evaluate. Ask a single prompt to do all of that and you get something that looks like a proposal and survives no scrutiny.

Multi-agent pipelines exist for exactly this shape of problem. Each competency becomes a specialized agent with a narrow contract; the pipeline carries state from one to the next; and the parts that must never be creative (the arithmetic) leave the model entirely.

The pipeline in six moves

The flow reads left to right: a raw client brief enters; agents ground it in company knowledge (rate tables, past projects); an architect agent drafts the solution and its work breakdown; a deterministic step computes cost and ROI in code; an adversarial critic challenges the draft; and a composer assembles the client-ready proposal, on screen and as a branded PDF.

The deterministic core

Language models are convincing at arithmetic and unreliable at it, which is the worst possible combination for pricing. So the pricing step in Proposal Architect is not an agent. It is plain Python: the model proposes structured inputs (roles, effort, assumptions), and compute_price and compute_value do the math.

The boundary is defended, not just declared. Model-authored numbers are validated before they enter the calculation: non-finite values and negative quantities are rejected outright, so a hallucinated input cannot poison the price or the ROI. The same inputs always produce the same numbers, which means a partner can audit any figure in the document back to its inputs.

This is the general rule we build by: the model proposes, the code decides. Anywhere a number carries business consequence (a price, a score, a quota), it is computed deterministically, and the model's job ends at suggesting inputs.

The critic that pushes back

First drafts are confident and wrong in subtle ways. The pipeline's answer is an adversarial critic agent whose only job is to attack the draft: unsupported claims, weak sections, inconsistencies between the architecture and the estimate. Sections that fail go back for another pass, within a bounded loop, so quality pressure is structural instead of depending on someone rereading carefully at 11 pm.

What this architecture buys

Three properties fall out of the design rather than being bolted on: traceability (every requirement in the brief maps to a section in the response, with status), auditability (every number reproduces from its inputs), and consistency (the structure of the document is enforced by the pipeline, not by mood).

The honest part

Proposal Architect was built as a hackathon system: the knowledge it grounds on is synthetic by design, and it is not (yet) a client deployment. What the build validated is the architecture: the deterministic boundary, the critic loop and the grounding pattern all survived live runs, adversarial review, and a security hardening pass.

That architecture is the point. It is the same rule we apply to everything we ship at Techmorphosys: intelligence where it helps, determinism where it counts.