KiasuBid

System Architecture
Multi-Agent Workflow

Inspiration

Government procurement creates significant opportunities for SMEs and startups, but bidding is difficult for small teams.

A tender is not just a document to read. Teams have to identify mandatory requirements, verify company evidence, interpret amendments, assess commercial and timeline risks, and coordinate actions before a hard submission deadline.

A single corrigendum can invalidate an assessment that was correct the day before.

For startups, the challenge begins even earlier: founders may have a strong technical product but little experience translating procurement language into a credible government proposal.

We built Kiasu Bid around one question:

What happens after you find a tender?

Instead of building another chatbot that simply summarises procurement documents, we wanted an operational system that helps smaller teams Decode, De-risk, and Deliver.

What it does

Kiasu Bid is a Singapore-first AI procurement workspace for SMEs and startups.

It provides two user workflows built around the same three-stage operating model:

1. Decode — Understand the opportunity

For SMEs, Kiasu Bid turns scattered procurement documents into a structured opportunity.

It extracts and organises:

tender objectives,
mandatory requirements,
technical requirements,
evaluation criteria,
contract conditions,
deliverables, and
deadlines.

Teams can also import a user-supplied ACRA Business Profile. Kiasu Bid extracts explicit company facts such as paid-up capital, SSIC classification, and incorporation date and compares them with known tender context for an early bid-fit screen.

This is deliberately a preliminary assessment rather than an official eligibility determination.

Kiasu Bid also uses public procurement award data to provide historical commercial context such as award-price ranges, recurring patterns, and agency-level observations. These are descriptive signals—not a prediction of evaluator behaviour or bid success.

For startups, Tender Jargon Decipher translates procurement language into a plain-English action plan covering:

what the buyer wants,
required product capabilities,
eligibility evidence,
delivery phases,
payment or acceptance milestones,
deadlines,
risks, and
immediate next steps.

The goal is to turn procurement language into something a small technical team can act on.

2. De-risk — Identify what could go wrong

Kiasu Bid runs a structured multi-agent review rather than asking one model to evaluate an entire tender in a single prompt.

The core agents are:

Planner — decomposes the tender into requirements, deliverables, tasks, and review areas.
Compliance — examines mandatory requirements, evidence gaps, and relevant compliance concerns.
Commercial — reviews pricing assumptions, financial feasibility, and contractual risks.
Timeline — identifies clarification dates, submission deadlines, milestones, and schedule pressure.
Critic — independently reviews specialist findings for contradictions, missing evidence, and unsupported conclusions.

Each finding is represented with structured fields such as status, severity, confidence, supporting evidence, downstream effects, and recommended action.

This lets Kiasu Bid maintain an auditable connection between the source material and the operational state shown on the dashboard.

A key feature is corrigendum impact management.

In our main demonstration, an originally satisfied mandatory requirement changes from:

3 CISSP-certified engineers → 4 CISSP-certified engineers

Kiasu Bid:

interprets the amendment,
matches it to requirement R17,
creates a new requirement version,
preserves the previous version as superseded,
rechecks the Evidence Registry,
recalculates the operational state, and
generates recovery actions.

The bid changes from:

FEASIBLE → RECOVERABLE

while:

Critical Gates change from 8/8 → 7/8
Submission Coverage changes from 91% → 84%
Deadline Risk changes from LOW → MEDIUM

RECOVERABLE does not mean compliant. It means a critical gap exists, but a plausible recovery path remains before the submission deadline.

Kiasu Bid also represents two other important states:

BLOCKED — a mandatory gap exists with no viable recovery path under the current constraints.
UNCERTAIN — the available wording or evidence is insufficient to safely determine the state.

Instead of forcing every case into pass or fail, the system makes uncertainty explicit.

3. Deliver — Produce the right next step

Identifying a problem is not enough. Kiasu Bid turns risks into owned work.

In the CISSP example, the system identifies that a potential fourth engineer has:

CISSP certification — VERIFIED
Current CV — STALE
Availability — UNKNOWN

Kiasu Bid then generates dependency-aware recovery actions such as:

requesting updated evidence,
confirming engineer availability,
updating the manpower schedule, and
re-running R17 verification.

Each action can carry an owner, due date, priority, and dependency.

The resulting Human Decision Packet consolidates grounded findings, unresolved questions, and required actions so the team can make an informed decision about whether to proceed, improve the bid first, request clarification, or stop.

Kiasu Bid supports the decision process. It does not make the final commercial or legal decision on behalf of the user.

For startups, Deliver also includes a structured proposal-preparation workflow.

The Guided Proposal Builder asks founders focused questions about areas such as:

architecture,
scalability,
cybersecurity,
implementation,
maintenance,
governance,
risks, and
measurable outcomes.

Instead of simply generating a proposal from nothing, it critiques weak answers, asks follow-up questions, and turns the founder's own responses into a structured preparation draft.

Tender milestones can then be organised into an actionable submission and project plan.

How we built it

Kiasu Bid uses a hybrid architecture combining LLM interpretation, deterministic verification, persistent state, and human checkpoints.

The backend is built with Python and FastAPI.

SQLAlchemy and SQLite maintain persistent state including:

requirements,
requirement versions,
evidence,
assessments,
tasks,
recovery actions, and
audit history.

For semantic interpretation, we integrated Amazon Bedrock using Amazon Nova Lite.

LLM responses are not trusted as unrestricted free-form outputs. They are converted into structured data and validated before entering the operational workflow.

Pydantic is used to enforce structured schemas, while deterministic application logic handles areas such as:

mandatory counts,
evidence status,
critical gates,
requirement versioning,
deadline logic,
task dependencies, and
operational feasibility.

LangGraph coordinates stateful workflows around tender changes and agent execution.

The frontend is built with React, TypeScript, Vite, and Tailwind CSS.

Kiasu Bid also supports document ingestion for selectable-text:

PDF,
DOCX,
TXT, and
Markdown files.

The result is a system where AI helps interpret procurement language, but deterministic logic and human review remain responsible for operational state.

System Architecture

Kiasu Bid deliberately separates AI interpretation from deterministic operational logic.

Tender / Corrigendum / Company Evidence
↓
Document Ingestion & Interpretation
↓
LangGraph Orchestrator
↓
Requirement Extraction & Versioning · Evidence Registry · Specialist Agent Review
↓
Critic Review
↓
Deterministic Verification Engine
↓
Operational State Engine
→ FEASIBLE
→ RECOVERABLE
→ BLOCKED
→ UNCERTAIN
↓
Recovery & Task Planner
↓
Human Checkpoint
↓
SQLite Audit & Version History
↓
FastAPI API Layer
↓
React / TypeScript Interface
↓
Decode · De-risk · Deliver

Why we designed it this way

We deliberately avoid allowing the language model to directly determine whether a mandatory procurement requirement is satisfied.

The LLM is best used for interpreting language: identifying what a clause means, detecting changes, extracting structured facts, and resolving semantic relationships.

Operational decisions require different guarantees.

Structured model outputs therefore pass into deterministic logic that evaluates:

numeric thresholds,
qualification counts,
evidence completeness,
critical gates,
deadlines,
dependencies, and
recovery feasibility.

This produces four explicit operational states:

FEASIBLE — current evidence supports all critical gates.
RECOVERABLE — a critical gap exists, but a viable recovery path remains before closing.
BLOCKED — a mandatory gap has no viable recovery path under the known constraints.
UNCERTAIN — the available wording or evidence is insufficient for a safe determination.

Material changes are versioned and tied back to supporting evidence.

This allows Kiasu Bid to explain not only what changed, but also why the bid state changed.

Multi-Agent Workflow

The Tender Lab uses a focused five-agent workflow instead of asking one model to perform every type of bid review.

Planner
↓
Compliance · Commercial · Timeline
↓
Critic
↓
Evidence-backed Findings
↓
Human Decision Packet

The Planner first decomposes the opportunity and assigns focused work to the specialist agents.

The Compliance Agent reviews mandatory requirements and supporting evidence.

The Commercial Agent examines pricing assumptions, financial feasibility, and contract risk.

The Timeline Agent identifies clarification dates, submission deadlines, dependencies, and delivery milestones.

Their findings are then passed to the Critic, which independently examines the combined output for:

contradictions,
missing evidence,
unsupported conclusions, and
unresolved human decisions.

Only after this review are the findings consolidated into the human decision layer.

Challenges we ran into

Making AI outputs operationally safe

A convincing AI explanation is not enough in procurement.

If an LLM incorrectly concludes that a mandatory requirement is satisfied, the consequence may be much more serious than a bad summary.

We therefore separated semantic interpretation from deterministic verification.

The model can interpret the requirement, but operational state is calculated separately using structured evidence and explicit rules.

Handling amendments without destroying history

A corrigendum should not simply overwrite the previous tender requirement.

We needed versioned requirements so Kiasu Bid could preserve:

what the requirement used to say,
what it says now,
which assessment belonged to each version, and
exactly why the bid state changed.

In the CISSP demonstration, R17 version 1 remains visible as SUPERSEDED, while version 2 becomes the current requirement.

This makes the change auditable rather than silently replacing history.

Distinguishing missing evidence from actual failure

One of the most important design problems was deciding what to do when some evidence exists but is incomplete.

For example, Engineer D may hold a valid CISSP certification while his latest CV is stale and his availability has not been confirmed.

Calling this fully compliant would be unsafe.

Calling it impossible would also be wrong.

This led us to model RECOVERABLE and UNCERTAIN as first-class operational states rather than forcing every case into a binary pass/fail result.

Keeping the demo reliable while using live AI

Hackathon environments, temporary credentials, external services, and model calls can fail.

We therefore separated deterministic demo behaviour from live interpretation and clearly label execution state where appropriate.

The core verification logic does not depend on pretending that a failed model call was a successful one.

This was particularly important for making the demonstration reproducible while still validating the live Amazon Bedrock path.

Grounding agent findings in evidence

Multi-agent systems can easily become several models agreeing with one another without adding reliability.

We wanted the agents to operate against shared evidence rather than simply passing prose between themselves.

That required us to maintain structured evidence references and expose the provenance behind material findings.

The Critic could then review both the conclusions and the evidence supporting them.

Building for two different user groups

An established SME and a student startup face very different procurement problems.

SMEs may already understand their service but lack dedicated bid, compliance, legal, and pricing teams.

Startups may not understand procurement language at all.

We therefore created separate SME and startup experiences while keeping a shared underlying model:

Decode → De-risk → Deliver

This let us reuse procurement intelligence without forcing both user groups through the same interface.

What we learned

The biggest lesson was that agentic AI becomes significantly more useful when it is connected to state, evidence, deterministic rules, and human checkpoints.

Procurement is not primarily a summarisation problem.

It is a decision-coordination and change-management problem.

A tender evolves. Evidence changes. Deadlines move closer. Amendments invalidate assumptions. Different specialists reach different conclusions.

The system therefore has to remember what happened before, understand what changed, and propagate that change into the next operational decision.

We also learned that uncertainty should be represented explicitly.

A system that says:

"We do not yet have enough evidence."

can be more useful—and safer—than one that always tries to produce a confident answer.

Technically, the project gave us practical experience with:

stateful LangGraph workflows,
Amazon Bedrock integration,
structured LLM outputs,
Pydantic validation,
deterministic rule engines,
evidence provenance,
requirement versioning,
dependency-aware recovery planning, and
human-in-the-loop agent systems.

What's next for Kiasu Bid

Kiasu Bid is currently a hackathon prototype demonstrating the feasibility of an evidence-backed procurement workflow.

Our next step is to turn it into a pilot-ready workspace.

Planned extensions include:

deeper SME-to-prime-contractor opportunity routing,
richer organisation-level evidence management,
broader official policy and procurement-source retrieval,
stronger proposal collaboration workflows,
direct calendar synchronisation and automated reminders,
multi-user access control,
larger tender and corrigendum evaluation datasets,
broader testing across procurement categories, and
pilots measuring tender-triage time against manual workflows.

We are also exploring a planned SME-to-MNC Subcontracting Router that could decompose tenders that are too large for one SME into bounded work modules that can be proposed to a larger prime contractor.

The long-term goal is not to automate the procurement professional or remove human control.

It is to give small teams some of the operational capacity that would otherwise require a much larger bid, compliance, commercial, and project-management function.