Proposal Agent, Send More Proposals, Faster

Organizations can use this proposal agent to create and respond to more proposals, respond to more RFPs, and create a lot more proposals a lot more accurately, faster. This means they can grow their business by responding to more RFPs.

The problem

Most teams are not able to respond to RFPs or client proposal requests in the way they would like, and they cannot tailor each proposal to the RFP or client requirement fast enough. They answer fewer than they want to, and they answer them later than they should.

Building every proposal requires analysis of each requirement. What those requirements mean, how to respond to them, and whether they can be met or whether there is an alternative solution. This can take hours, and sometimes several days.

A proposal built fast can also miss requirements, fail to address client requirements, or underestimate the effort.

Often the knowledge to build these proposals is encapsulated across different individuals, whether that is the account manager or the architect. For example, which past proposal is the right starting point. How that kind of job gets scoped. What a fair number looks like for it. Which parts of a request are critical to ensure a win. That sits with whoever has been doing it longest.

Writing a good proposal is often about getting how those people think and how they created a compelling proposal that can win.

What I built

I built a proposal agent that first understands requirements against the organization’s own rules. There is an ability to index past proposals, a separate function, so that body of knowledge can be reused for future proposals.

It creates a proposal based on how the organization responds, creates a solution, and builds a draft proposal based on previous knowledge for the internal team to review.

To get the core knowledge and rules, I interview the individuals who have this knowledge and turn that into archetypes that train the system. These are the rules that the system uses, including understanding whether this is a good opportunity or what disqualifies an opportunity based on those rules. How the work is scoped. What a requirement is and how it should be responded to or designed against.

Overall, the system is trained and domain tuned to each organization’s rules and how they do things, how they read the requirements, how they build it, how they validate.

The system can also be extended to go out and search for RFPs across websites or portals. This enables even more automation that can go find potential opportunities to respond to.

The person who owns the proposal gets the draft from the system. They can review it with internal stakeholders, make edits and then they can send it.

How it works

To ensure consistency in the workflow, hard gates are created using deterministic code. For Claude that means hooks. The reason for this is that AI agents often try to override the rules and the process. They also modify themselves and can modify other agents or skill code, which can lead to inconsistencies and a bypass of the process. Using gates also prevents AI agents from doing everything at once, and takes a stepped approach.

The process is designed in a way that you can imagine one person determining whether they should apply for the RFP or create a proposal, someone gathering requirements, another person evaluating those requirements and any design, another person scoping that work, and then finally writing that proposal. Imagine everyone doing this really fast. This is what enables greater accuracy and better consistency, with speed.

In addition, the system does not rebuild documents, and the way we prevent formatting from ever breaking is by restricting the system to reusing the Word file’s own XML. This way the layout, the styles and the numbering are never modified.

These proposals are kept in structured objects (JSON). This ensures consistency so the system can reuse content.

Given the proposal’s content (all or in part or new) will be written in some part by the AI, the issue is that content will sound like an AI. The system applies a voice stylistic fingerprint so that every proposal sounds like the organization. That stylistic fingerprint is built from the analysis of documents written by the organization.

In addition, the system is built so it uses the right model for the job, which improves performance and reduces cost. For example, for retrieval of information, Sonnet can be used. When heavy reasoning is needed, such as in requirements gathering and proposal generation, Claude Opus can be used.

Before the final draft, the organization can use personas, or agents, or skills that are trained on specific reviewer roles from architecture to estimators. This allows another more focused review that ensures the draft documents are accurate and ready for review.

This solution is not limited to proposals. This can be used across types of document creation processes, where there is a body of knowledge that can be reused, tacit knowledge that needs to be applied, things that need to be verified, and where it needs to be in the organization’s voice.

In practice

A client sends a formal RFP. The system evaluates the requirements, determines if it qualifies, extracts them, and builds a draft proposal for review.

A client sends an email describing requirements and they want a proposal. The system drafts from the closest proposal, sends the team a draft and clarifying questions.

A repeat client the team has worked with asks for a new engagement. The system starts from the scope built for them, carries forward what still applies.

Back to Portfolio