Tenderstack

Tenderstack is a multi-agent framework that produces tender, RFP, and ITT responses from a firm's own bid library. Thirteen specialist agents across five teams ingest historic bids, research buyers and competitors with source-cited findings, draft evidence-backed responses, and learn from every outcome. It runs inside an agentic coding CLI such as Claude Code or Codex, not as a SaaS product. This page is the developer documentation for setting it up and understanding it.

Introduction

You bring a historic bid library, won and lost responses, case studies, methodology documents, pricing sheets, and a live tender to respond to. The framework ingests the library into a tagged, linked Obsidian knowledge base, parses the tender into structured requirements gap-checked against that library, researches the buyer and named competitors, designs a technical solution from site evidence, prices the bid, drafts win themes, an executive summary, and section responses, checks coverage against the buyer's document inventory, and exports to .docx for human review. When the result comes in, a feedback pipeline updates win-theme performance counters and synthesizes cross-bid knowledge so the next bid starts stronger.

Every claim in a draft traces to a chunk of the firm's own library, and every research finding carries a source URL. Where the library cannot answer a requirement, the gap is flagged rather than papered over.

The project is source-available under the PolyForm Noncommercial 1.0.0 license: free to use, modify, and share for noncommercial purposes, with commercial use licensed separately. It is not an OSI-approved open-source license. The source is maintained privately; a public overview lives at github.com/matteux-star/tenderstack-showcase.

Agent teams

Thirteen agents are grouped into five teams. Each agent owns its database tables and its step in a pipeline; none writes another's state.

Requirements

Python 3.10 or later, with pyyaml, python-docx, and pypdf installed from runtime/requirements.txt. An agentic coding CLI: built and tested against Claude Code and Codex; a tool that cannot spawn real subagents falls back to a single-session mode that loses the framework's isolation and parallelism. Web search access is needed only by the two research agents; every other agent works offline against your own documents and database.

Setup

# 1. Clone the repository and open it in your agent CLI
claude        # or: codex

# 2. Ask the agent to run through setup.md
#    An interactive first-run wizard: it verifies the environment,
#    installs the Python dependencies, initialises the database
#    (init_db.py refuses to overwrite an existing one), and confirms
#    real subagent spawning before any work starts.

# 3. Describe what you need
#    "Ingest these three won bid responses into the library."
#    "Respond to this ITT from Example Academy Trust."
#    "Log the feedback from the Ridgeway bid. We lost."

Runtime layer

runtime/cli.py is the only entry point to the database and the filesystem. Every agent calls it through the shell: around 55 subcommands, each printing JSON to stdout and exiting non-zero with a message on stderr on failure. No agent writes raw SQL or hand-built frontmatter, which is how thirteen independently prompted agents share one database and one filesystem without corrupting each other's work.

Behind the CLI: db.py holds the mechanical database functions, vault.py and wiki.py write and read the two markdown stores, extract.py turns .docx and .pdf sources into plain text, and docx_export.py renders a finished draft back to Word for human review.

Data model

Seventeen SQLite tables, each owned by a single agent, join from one root: the bids row. Requirements, bid decisions, research findings, solution designs, price offerings, drafted content, and verification findings all hang off it, with CHECK constraints and indexes defined in db/schema.sql.

Two markdown stores sit beside the database. vault/ holds the ingested library, chunked by meaning and tagged against a controlled taxonomy; wiki/ holds cross-bid synthesized knowledge. Both are Obsidian vaults: YAML frontmatter, markdown body, [[wikilinks]], with graph view and backlinks when opened in Obsidian. Vault answers "what is in our library"; wiki answers "what we have learned across bids".

Pipelines

Pipeline 1 produces a bid response in eleven steps: ingest, RFP analysis, the bid or no-bid decision, technical solution design, buyer and competitor research in parallel, pricing, a section inventory of every document the buyer requires, drafting, a final coverage check against that inventory, and Word export. The pipeline stops at the bid or no-bid gate if the answer is no.

Pipeline 2 is the self-improvement loop, run when a result and the evaluator's feedback arrive. A fixed sequence with no lead role: ingester stores the feedback and sets the outcome, verifier checks every evaluator marker against what was actually submitted, overseer updates win-theme win rates and writes pattern notes, and knowledge-curator folds the lessons into the wiki. Pattern notes written here become playbook content that feeds the next Pipeline 1 run.

Project memory wiki

The wiki is the cross-bid memory: decision post-mortems, buyer profiles, competitor dossiers, sector playbooks, and methodology patterns, six topic folders in all. knowledge-curator writes second-order knowledge only, connecting what other agents already recorded; "insufficient data" is a valid section. The sector playbook is the highest-value artifact: after a few bids in one sector it holds which win themes actually win, which evidence types evaluators reward, and which gaps recur. bid-writer receives matching wiki pages automatically in its drafting context, and a weekly CI job flags stale pages.

Two honest gaps, tracked on the roadmap: the orchestrator role remains a stub filled by AGENTS.md, and there is no compliance review pass yet.