Why This Scope
Estimation is the highest-stakes part of pre-sales work — it directly affects pricing, staffing, and client trust. It is also the most time-consuming and inconsistent: different people produce different numbers for similar projects.
This proposal targets estimation only. Requirements analysis and risk registers are deferred.
✦ One focused output, proven end-to-end, is more useful than four shallow outputs
Input Form
Project name
Text
Project type
Dropdown — new build / feature addition / migration / integration
Tech stack
Multi-select
Scale
Dropdown — small / medium / large
Key features
Free text — short bullet list of what the system must do
Number of integrations
Dropdown — 0 / 1–3 / 4+
Deadline
Dropdown — hard / flexible / none
Additional context
Free text (optional)
Output — Estimation Sheet
Summary
Total estimated effort (person-hours) + indicative duration
Phase breakdown
Effort per phase — Discovery / Design / Development / Testing / Deployment
Role breakdown
Effort per role — BA / Frontend / Backend / QA / DevOps / PM
Key assumptions
What the agent assumed that wasn't stated in the input
Confidence rating
High / medium / low with one-line reasoning
RAG citations
Which past documents grounded the estimate
Delivered as a downloadable .md file. Cost excluded — rates vary by region, seniority, and client.
AWS Components
Bedrock (Claude)
Generates estimation output
Prompt
Controls structure, forces citation of past projects
RAG (Knowledge Base)
Retrieves relevant past estimation sheets
Guardrails
Filters sensitive content — client names, internal rates
Team Structure
V
Vinh
H
Hoat
M
Minh
🔄 Coordination Points
- Vinh + Minh — agree on agent output contract (fields, format) before backend is built
- Vinh + Hoat — agree on how estimation markdown is structured before frontend renders it
Task List
Grouped by phase. See tasks.html for the full breakdown with acceptance criteria.
Week 1–2
Infrastructure · Knowledge Base · Workflow Proposal
V
Research and propose reusable workflow/skill patterns for infrastructure, backend, and frontend
New
M
AWS infrastructure — Cognito, DynamoDB, S3, SQS, API Gateway, local dev environment
V
Knowledge base — write 5 seed estimation sheets, load into RAG, confirm retrieval
Week 3–4
Prompt Design · Guardrails · Backend API
V
Estimation agent prompt — structured output, citations, confidence rating, SSM seed
V+M
Guardrails — keyword blocklist, Bedrock configuration, test and iterate
M
Backend API — session management, SQS consumer, estimation pipeline, proposal export
Week 5–6
Frontend · Integration Testing
H
Frontend — input form, estimation result view, RAG citations, markdown download
All
End-to-end testing — full pipeline, guardrails, multi-tenant isolation, edge cases
Week 7–8
Bug Fixes · Demo · Reusable Workflow Implementation
All
Bug fixes, prompt iteration, guardrail tuning, production deploy, demo preparation
V
Implement the three agreed workflows (infrastructure / backend / frontend) and validate each against a new project brief
New
M+V
Architecture documentation — patterns proven, runbooks, what comes next
Timeline
1–2
AWS infrastructure, knowledge base, seed estimation data
3–4
Prompt design, estimation agent, backend API
5–6
Frontend, integration, end-to-end testing
7–8
Bug fixes, demo preparation, documentation
🏁 Target: working demo at end of week 8
RAG Approach
Phase 1
Seed with sample data
Write 3–5 realistic sample estimation sheets covering different project types (web app, mobile, AI integration, data pipeline). Load on day one so estimation can be tested immediately.
Phase 2
Replace with real data
As the team collects real estimation sheets and actuals, swap out the seed documents. No code changes required.
Retrieval Strategy — Hybrid Search
Use hybrid search (semantic + keyword/BM25) rather than semantic-only. Semantic search matches the meaning of the "key features" description; keyword search handles exact matches on tech stack names and integration terms. Tag every document with metadata — use filtering to narrow the candidate set before search runs.
🧠 Semantic (vector)
🔤 Keyword (BM25)
AI Engineering Concerns
1
Estimation agent will hallucinate without real data
Without real past project data, the model produces made-up numbers. This is the tool's biggest credibility risk.
- Label every estimate "AI-suggested — requires human review"
- Show RAG citations next to each figure so users see which past project it referenced
- Prioritise loading real estimation documents before any demo
2
Guardrails need careful tuning
Default Bedrock Guardrails will block legitimate content — cost figures, infrastructure details. Too strict breaks the tool; too loose is useless.
- Start with a keyword blocklist only (client names, sensitive internal terms)
- Iterate based on what gets blocked during testing
3
Prompt validation gap
Prompts written and tested against one model version may not produce the same structure on another.
- Test all prompts against Bedrock (Claude Haiku) early — do not finalise until validated on the production model
- Keep a small prompt test suite with expected outputs
Limitations
Output quality depends on input quality — vague description produces vague estimate
Human review of every estimate is required before use in client-facing pre-sales work
Requirements analysis and risk register are out of scope — deferred to a follow-on phase
Why This Works as R&D
The pattern is the real deliverable
The estimation agent + RAG pipeline covers the three core AWS AI concepts: prompt engineering, retrieval-augmented generation, and guardrails. The working tool becomes the company's reference architecture for grounded AI output.
✦ Prompt Engineering
✦ RAG + Hybrid Search
✦ Bedrock Guardrails
Scope expansion (requirements analysis, risk register, multi-agent orchestration) is straightforward once this foundation is proven.