build.allanninal.dev

Part 2 of 7 · Proposal generator series ~4 min read

How a proposal brief gets captured

The generator only drafts what it’s told. So the first job is making it dead easy to tell it — because the proposal you never start is the one you lose. There are three ways a brief gets in: you fill a short web form, you forward the email thread with the prospect, or you type a one-line command in Slack. The form is the obvious one. The other two exist because in real life the moment you decide to send a proposal is rarely the moment you’re sitting at a form.

Key takeaways

  • Three intake lanes feed one clean brief: a web form, a forwarded email thread, and a Slack command.
  • Forwarded threads are read by Bedrock Haiku 4.5 into a brief — client, need, budget, due date.
  • Every brief is tidied into the same shape, and anything missing is flagged before you start.
  • You always get a one-tap “start the draft” card. Nothing drafts until you tap it.
  • The clean brief is the one thing the generator reads. The lanes are just three doors into it.

Three lanes into one brief

Three intake lanes funnel into one clean brief A diagram with three vertical lane columns at the top and a single unified row at the bottom. Lane one, Web form: a salesperson opens a short form served by a Lambda Function URL and types the client name, what they need, a rough budget, and a due date; the form posts straight to the brief store. Lane two, Forwarded email: a salesperson forwards the email thread with the prospect to a dedicated address; SES writes the raw MIME to S3; a parser Lambda strips the thread to plain text and calls Bedrock Haiku 4.5 to read out a brief — client, need, rough budget, due date — and flags anything it couldn't find. Lane three, Slack command: a salesperson types a slash command with one line of brief; the command hits a Function URL, and the same Haiku tidy step turns the line into a structured brief. All three lanes converge on the same clean brief in DynamoDB, which the generator reads when you start the draft. A note at the bottom: the clean brief is the single source — the three lanes are just three doors into it. Lane 1 · form Web form • Open the short Function URL form • Type client, need, budget, due date • Posts straight to the brief store • Best for desk work Lane 2 · SES + Haiku Forwarded email • Forward thread to proposals-address • SES writes MIME to S3 • Haiku 4.5 reads it into a brief • Missing fields flagged for you Lane 3 · one line Slack command • Type a slash command, one line • Hits a Function URL endpoint • Same Haiku tidy step as Lane 2 • For the brief you remember on the go Clean brief in DynamoDB (single source) client · need · rough budget · due date · lane · by-user · status you get a one-tap “start the draft” card — nothing drafts until you tap to generator, on start The clean brief is the single source — the three lanes are just three doors into it.
Fig 2. Three lanes converge on one clean brief. The web form posts straight in; the email and Slack lanes are read by a cheap model call into the same shape. You always confirm with a one-tap card before any drafting starts.

Lane 1: the web form

The simplest lane. A short form, served by a Lambda Function URL (a plain web address that runs a small function when you submit — no heavyweight web gateway behind it). Four fields: client name, what they need (a sentence or two is fine), a rough budget, and a due date. You hit submit and the form writes a brief straight into the pg-briefs table in DynamoDB. No model call is needed here — you already typed clean fields.

This lane is for when you’re at your desk and you know exactly what you want. Most planned proposals start this way. The form is the one place the system asks for structure up front; the other two lanes do that work for you.

Lane 2: forwarded email (the lane most people actually use)

Set up a dedicated address — something like proposals@your-company.com — through Amazon SES. When a prospect emails you and you decide it’s worth a proposal, you forward the whole thread to that address and the system takes it from there. SES writes the raw message to s3://pg-raw-mime/. That write triggers a parser Lambda. The Lambda strips the email down to plain text (quoted replies, signatures, and disclaimers removed) and calls Bedrock Haiku 4.5 to read a brief out of the conversation.

The model’s job here is small and bounded: “Read this email thread. Return a brief as JSON: client name, what they need, any budget mentioned, any deadline mentioned. If a field isn’t in the text, leave it blank — do not guess.” The result becomes a clean brief with a status of “needs review.” You get a Slack card showing what it read, with any blank fields highlighted, and a button to start the draft or fix the brief first. The thread itself is kept in S3 so the generator can quote a detail from it later if it helps.

Why does a human still confirm? Because a brief the model misread is cheap to fix now and expensive to fix after it’s shaped a whole proposal. Thirty seconds of “yes, that’s right” beats rewriting a draft built on the wrong budget.

Lane 3: the Slack command

Sometimes you remember the proposal you owe someone while you’re between meetings. Lane 3 is for that. A slash command in Slack — /proposal Delgado & Co., rebuild booking flow, ~$18k, before Q4 — hits a Function URL. The same Haiku tidy step from Lane 2 turns your one line into a structured brief: client, need, budget, due date. You get the same one-tap card back in the same channel.

The Slack lane trades completeness for speed. You won’t always have the budget or the deadline in your one line, and that’s fine — the missing-field flag tells you what the draft will have to assume, and you can fill it in before or after the first draft. It exists so that “I should send that proposal” turns into an actual brief in the ten seconds you have, instead of a note-to-self that never happens.

Why everything funnels to one clean brief

Three lanes in, but only one thing the generator reads: the clean brief in DynamoDB. That’s deliberate. If each lane handed the generator a slightly different shape, every “why did the draft say that?” question would mean checking which door the brief came through. Funneling everything into one brief shape means there is exactly one record per proposal, with the same fields every time, no matter how it started. The lanes are conveniences for getting a brief in; they all pass through the same clean brief on the way.

Next post: how the generator takes that clean brief, finds your closest past proposals, computes the price, and writes all five sections in one grounded call.

All posts