AI Proposal Generator: How We Built a Real One on Top of a Knowledge Base
An AI proposal generator is a system that produces complete commercial proposals (final document, prices, scope, the company's format) from the business's real knowledge: its inventory, its rates, its historical proposals and its team's criteria. The difference between a generator you can actually work with and one that produces generic text with a letterhead is not the language model: it is the knowledge base underneath.
This guide covers how we built a real one: the proposal generator we developed for Envision, a media agency operating in Argentina and the rest of LATAM, on top of its own knowledge base. It is not a "connect ChatGPT to a template" tutorial: it is the real architecture, layer by layer. With this system, a proposal that used to take hours of manual assembly comes out in minutes, with the usual format and the agency's real data.
The problem: commercial knowledge lived in no system
Envision builds media plans: advertising investment proposals combining media (out-of-home, radio, digital) by city, with rates, specs and strategy. Before the build, that process looked the way it does in most service companies:
Inventory and rates lived in spreadsheets, with versions only some people knew which one was current.
Historical proposals were files in folders, they existed, but nobody could ask them anything (“what did we propose to this client last year?” was archaeology, not a query).
Commercial criteria lived in heads, which mix works for which campaign type, which arguments convince, what got corrected last time.
Every proposal went through design, the sales team depended on another area to produce the final document, with the bottleneck that implies.
This diagnosis is the starting point of almost every AI knowledge base project: the information exists, but it is stored, not available. The proposal generator was the chosen entry point because it attacks the most repetitive, most senior-hours-expensive process in the commercial area.
Why a generic SaaS does not solve this
Searching for "AI proposal generator" returns almost exclusively SaaS tools: you write a prompt or fill a form and the AI writes a nice-looking proposal. For a freelancer needing a presentable document, they are enough. For a company whose business is the proposal (a media agency, a consultancy, a construction firm), the problem is different:
| Criterion | Generic proposal SaaS | Own generator on a knowledge base |
|---|---|---|
| Business knowledge | None: writes from the prompt | The company's real inventory, rates and specs |
| Data and prices | You type them into every proposal (or it invents them) | Come from the source of truth, always current |
| Format | The tool's templates | The company's exact template (PDF and Excel) |
| History | Every proposal starts from zero | Retrieves similar approved proposals as reference |
| Learning | Does not learn from your corrections | Every approved proposal and every piece of feedback feeds the base |
| Ownership | Your proposals in a third party's cloud | The client owns the instance and its data |
The decisive row is the first one. A language model without access to the company's knowledge can only do one thing: invent with elegance. In a commercial proposal, an invented price is not an aesthetic error, it is a contractual problem. That is why the right question is not "which AI writes best?" but "where does it get the data from?".
The architecture: three layers, bottom-up
The system we built for Envision has three layers, and the order matters: the generator is what you see, but the knowledge base is what makes it trustworthy.
The knowledge base (the brain)
A Postgres database with pgvector where the structured commercial knowledge lives: media inventory, historical proposals with their feedback, style guide and criteria. It is the concrete implementation of what we call the company brain.
The query layer (retrieval)
Hybrid search (semantic + Spanish full-text) that finds the relevant knowledge for each request, with citations to the source.
The generator (the application)
A Next.js web app where the sales team loads the campaign parameters and gets the finished proposal in the agency's real format, in PDF and Excel, without going through design. PDF generation runs with Chromium on the server itself, so the final document is identical to the template the agency was already using.
The generator build took 4 to 6 weeks. The knowledge base was set up as the foundation of the same project: it is the pattern we use in all cases of this kind, where the first useful microservice seeds the brain that later feeds everything else.
The knowledge base from the inside
A hybrid data model: typed tables + generic chunks
The most important modeling decision was not forcing everything into one format. The schema has two levels:
First-class tables for what the business knows with structure: proposals (client, campaign, year, cities, strategy, approval state), feedback events and the media inventory. These tables are queried with deterministic SQL: "the latest approved proposals for this client" does not need AI, it needs a WHERE.
Generic documents and chunks for unstructured knowledge: each piece is split into text fragments with their embedding (a 1,536-dimension vector), filter metadata (source type, client, date, state) and a reference to the original source for citation.
This separation has a key reliability consequence: proposal assembly never depends on semantic search. If the embeddings subsystem fails, semantic search degrades; the generator keeps generating, because its hard data comes from the typed tables.
Different chunking for each source type
A common mistake in RAG projects is cutting the whole corpus with the same scissors. Each source type has a natural granularity:
Historical proposals → one natural-language “card” per proposal (client, campaign, mix, feedback received), because raw JSON embeds poorly and the card describes what a salesperson would ask.
Inventory items → one chunk per media item: they are already atomic.
Meeting transcripts → windows of 500 to 800 tokens by conversation turns, with ~100-token overlap and timestamps in the metadata.
Long documents (policies, briefs, contracts) → recursive fragments of ~800 tokens, with page and section for citing.
Everything lands in the same chunks table, so retrieval is a single query no matter which source the knowledge came from.
Knowledge has versions
A 2024 rate is not false information: it is expired information. The schema versions every document with a state (current / superseded / archived) and validity dates: when a new rate comes in, the previous one is not deleted, it is marked as superseded. Default search only returns current knowledge; historical queries can explicitly request the archive. Without this, the most elegant system in the world ends up quoting with old prices, which is the fastest way to lose the sales team's trust.
Ingestion: the generator feeds itself
The biggest risk of a knowledge base is not technical, it is maintenance: if loading it requires manual discipline, it dies within months. The engineering solution was turning the generator itself into the base's main feeder:
Every approved proposal is ingested automatically. The approval event triggers card creation, embedding computation and the write to the base. The team does not “load knowledge”: it works, and the knowledge stays.
Ingestion is best-effort, never blocking. If the embedding computation fails, the proposal approval does not fail: the chunk is marked as pending and a backfill process picks it up later. A knowledge base must never be able to break the workflow that feeds it.
External sources come in via loading scripts, runnable on demand or by cron, with the same chunking and versioning pipeline.
The cultural rule we installed with the system is simple: if it was not recorded, it does not exist for the system. The technical design serves that rule, not the other way around. The full process of this approach (source discovery, structure, ingestion, querying, adoption) is developed in how to create an AI knowledge base.
Hybrid retrieval: because vector search alone is not enough
A sales team's real queries are mostly lexical: client names, media names, cities, specific rates. Exactly the terrain where pure vector search fails and full-text search shines. That is why the query layer combines both from day one:
Semantic search with pgvector (HNSW index, cosine distance) for conceptual questions (“what mix did we propose for launch campaigns?”).
Spanish full-text search (Postgres tsvector) for the exact stuff: names, codes, rates.
Fusion via Reciprocal Rank Fusion, which combines both rankings without per-client weights to calibrate: each result contributes according to its position in each list, not according to scores that are not comparable to each other.
Metadata filters in the query itself (source type, client, current-only) and a cap of 6 to 8 fragments per query, with a per-document chunk limit so a single file does not monopolize the context.
We chose HNSW over ivfflat as the vector index for a practical reason: HNSW builds well even when the table starts almost empty, which is the reality of every new knowledge base. And we deliberately left out everything that is over-engineering at this scale: no reranker, no query decomposition, no dedicated vector database. Each of those pieces has a documented trigger ("add if X happens"), not a default place.
Guardrails: how it avoids making things up
A system that writes commercial proposals has one obligation above all others: do not invent. The build's concrete guardrails:
An “I don't know” guard before calling the model. If the search finds no fragments with sufficient relevance, the system answers “I didn't find that in the base” without invoking the LLM. It is the cheapest hallucination mitigation there is: the invented answer that never gets generated does not need to be detected.
Citations per claim. Every answer from the query layer references the documents it came from. Traceability over coverage: we prefer an honest “I don't know” to a fluent answer with no source.
A log of every query (question, retrieved fragments, scores, answer): it is the dataset used to tune the guard's threshold and evaluate retrieval quality with real usage data, not intuition.
Controlled degradation. If the entire knowledge base goes down, the generator keeps working through its deterministic path. AI improves the system; it is never its single point of failure.
Hard data never comes out of the model. Prices, media and specs are read from the tables; the language model writes and structures, it does not quote from memory.
Engineering decisions you do not see in the demo
Three architecture decisions that define whether this is a product or a proof of concept:
Single-shot before agentic. The query agent does one retrieval and one model call (Claude, via API), instructed to cite and say "I don't know". A multi-step agentic loop on top of an immature retrieval is the classic recipe for the demo that impresses and hallucinates three months later. The search function is already shaped as a tool: scaling to agentic is future configuration, not a rewrite.
No premature infrastructure. At tens of events per month, a message queue is dead weight: states in the database itself plus a periodic backfill do the same job with one less moving piece.
The client owns it from day one. The instance, the configuration and the data belong to Envision; the model API keys are the client's (consumption goes straight to their account, no intermediation). What remains as our intellectual property is the reusable engine: the schema, ingestion and retrieval pattern we are already replicating in other builds.
What gets built next: the brain is already seeded
The proposal generator is the first microservice on the knowledge base, not the last. With the brain set up and feeding itself, every new module rests on the same foundation: a query chat for the sales team ("what did we propose to this client and what feedback did they give us?"), a unified client history, meeting processing into the base. Each piece is decided and built separately, in whatever order the business prioritizes.
That is the model we defend for any mid-sized company: do not buy "a transversal AI platform"; pick the process that hurts the most, build the tool that solves it and leave the knowledge base set up underneath. If you want to evaluate whether your company has a case like this, the knowledge base pillar explains how to recognize it; and if you prefer to discuss it directly over your case, let's talk.
Frequently Asked Questions
What is an AI proposal generator?+
Isn't a generic proposal SaaS enough?+
How does the AI use the company's real data?+
What is the knowledge base and why does it go under the generator?+
How does the system avoid inventing prices or data in a proposal?+
How long does it take to build a custom proposal generator?+
Does your team lose hours assembling proposals?
We build you a generator on top of your own knowledge base
With your rates, your history and your format. Free intro call to understand your process, implementation quoted by scope.
Artículos Relacionados
AI Company Brain: What It Is and How It Works
Centralize your company knowledge in a base that answers with AI, connected to your systems.
RAG for companies: when it makes sense and when it doesn't
What RAG is, when it beats other options and how it gets implemented in a company.
How to Create an AI Knowledge Base: the Real Process
The real process for creating an AI knowledge base, step by step.