Prompt

A prompt is the complete input sent to a language model: the instructions, context, constraints, and examples that together determine what the model produces, not just a question typed into a chat interface.

What a prompt actually contains beyond the question

A well-constructed prompt for proposal work contains four distinct layers: the role or persona the model should adopt, the context it needs to produce accurate output (client background, project type, relevant past work), the constraints that govern the response (word count, SF-330 section format, evaluation criteria language pulled directly from the RFP), and examples of the expected output quality. Miss any of those layers and the model works from assumptions. In a proposal context, that means invented project names, wrong teaming partner credits, or methodology descriptions that don't reflect how the firm actually works. The model doesn't know what it doesn't know, and it won't flag the gap.

Where prompt quality becomes a compliance and workflow problem

A federal design-bid-build RFP may specify that responses to SF-330 Section H address no more than five relevant projects and mirror evaluation language from the SOW. A prompt that omits those constraints produces a response that looks complete but fails on review; the compliance check falls back on the proposal coordinator, who then spends time correcting output instead of advancing the pursuit. Providing the RFP text, the evaluation criteria, and verified past project data as part of the prompt changes the output significantly. This is why prompt construction is a strategic skill in the pursuit workflow, not a task that gets delegated to whoever first opens the chat window.

Prompts as repeatable pursuit assets, not one-off inputs

Firms running 40 to 80 pursuits per year should treat their best-performing prompts the way they treat go-by narratives: saved, labeled by pursuit type, and refined after each debrief. A prompt that reliably produces a strong project approach narrative for a public transit client encodes the firm's voice, the client's evaluation priorities, and the structural requirements of that pursuit type; a generic prompt does none of that. The common mistake is building a strong prompt once, getting good output, and losing the prompt when the pursuit closes. Kantiv surfaces the verified project data, personnel records, and client history that make a prompt accurate in the first place, so teams stop reconstructing context from scratch every time they open a blank input field.

Related terms