Turning Proposal Automation Into a Project-Aware AI Search System

Worked with stakeholders from a planning and consulting firm to turn a broad proposal-automation idea into a production AI retrieval system for finding and reusing past project knowledge.

My role: I was the sole engineer and customer-facing technical lead, responsible for discovery, scoping, architecture, implementation, stakeholder demos, user updates, and iterative delivery.

Results

I delivered an internal AI assistant that made the client’s historical project archive easier to search and reuse.

• Built a production AI assistant for querying the client’s document library in natural language.
• Cut the time spent writing proposals in half, based on stakeholder feedback.
• Reduced reliance on senior staff for tribal knowledge.
• Used stakeholder demos, update emails, and observed failure cases to guide the roadmap.

Proposal automation was too broad to build first

The client’s original goal was fulling automating proposal writing but this combined several different problems:

• understanding proposal structure
• finding past work
• selecting relevant examples
• generating polished content

I recognized that trying to automate the full workflow immediately would create unecesary risk and delay value to the client. Instead I proposed narrowing the first phase to something that:

• was small enough to build quickly
• addressed a significant pain point
• made progress towards the original goal

Full proposal automation was the exciting version of the project, but it was too broad to build all at once. I wanted the client to get value sooner, while still moving towards their ultimate goal.

Search created value before automation

• Interviewed stakeholders and reviewed past proposals to understand where AI could fit into the workflow.
• Identified a concrete pain point: finding relevant past projects was slow and important.
• Chose search because it was useful on its own and necessary for future proposal generation.
• Scoped the first system around an AI assistant with a centralized file store and natural-language search.
• Used that first deliverable to create a practical path from knowledge retrieval toward deeper automation.

Search became the right first wedge because it solved an immediate problem without requiring the entire proposal-writing process to be automated. It gave users faster access to the historical material they already relied on, while creating the knowledge layer future automation would need.

Users asked about projects, not documents

While reviewing the client’s feedback and usage I identified an implicit requirement that users had not asked for directly: a project model.

Users often asked questions like:

• “Which projects involved RCMP facilities?”
• “Which projects included test fits?”

The system handled these quetions poorly because it did not understand projects as entities.

This was a major product insight: the client’s work required tribal knowledge that was implicit in the structure surounding the documents but not captured in them directly.

For the system to be useful I had to make this implicit knowledge visible to the agent.

Feedback turned failures into the roadmap

I reviewed stakeholder testing to identify issues such as:

• Work from external contractors was misattributed as work completed by the client.
• Relevant projects were excluded because standard retrieval only returned the top matches.
• The assistant answered questions about one project using documents from another.
• Project context was often misattributed because projects often referenced each other.

I translated those failures into a roadmap: better search, better context awareness, and dedicated list-query support. The project improved through repeated feedback rather than a fixed initial specification.

Project context became the real product

The architecture changed because the product requirement became clearer: the assistant needed to reason over the client’s project history, not just retrieve text. That prompted me to make several changes:

• Added project metadata such as client, location, personnel, and dates.
• Added query expansion and project-field search.
• Built a project-topic lookup tool that grouped evidence by project, filtered weak matches, and summarized relevant results.
• Used evaluations to tune the system and improve chunk quality, recall, precision, and relevance over time.

The hard part was not simply connecting an LLM to a set of documents. The hard part was exposing enough of the project context around those documents for the assistant to answer the kinds of questions stakeholders actually asked.

Lessons Learned

This project reinforced that the most important AI requirements are often implicit. The client asked for proposal automation, but real usage showed that the first hard problem was project-level understanding: connecting documents, snippets, metadata, and prior work into something the assistant could reason about.