I brought Nimra.ai into Carnegie Mellon's Agentic AI course as a product idea that already made intuitive sense to me.
RFP responses are painful. AI can help. Build a tool that uses prior answers and company knowledge to draft better responses faster.
That was a good starting point, but the course helped me see the product differently. The first version was mostly prompt-first in my head: give the model the right context, ask for the right output, review the answer. Useful, but incomplete.
The agentic framing pushed me to think in terms of workflow, state, tools, evaluation, and human checkpoints.
It also pushed me to make document reading the first-class job. The useful system is not just "answer this question." It is "read the entire RFP, RFI, grant, amendments, and addenda, then tell me what I must do before we draft anything."
From Chatbot to Workflow
The chatbot version of an RFP tool is easy to imagine:
"Answer this RFP question using our company documents."
That can work for a single question, especially if the user is patient and knows how to evaluate the answer. But an RFP response process is not one question. It is dozens or hundreds of questions, each with different risk, ownership, and source requirements.
An agentic workflow needs to break the work apart:
- Parse the RFP into discrete questions.
- Extract requirements and disqualifier watch-outs.
- Classify each question by topic and risk.
- Retrieve relevant prior answers and source material.
- Draft a response.
- Evaluate confidence and source coverage.
- Route uncertain answers for human review.
- Save approved answers back into the knowledge base.
This sounds obvious once written down, which is often the sign of a useful product insight. The tool should not be a magic text box. It should be a structured process for turning messy customer asks into reviewable, reusable answers.
Agents Need Boundaries
One of the lessons I keep relearning with AI is that autonomy is only helpful when the system has good boundaries.
For Nimra, that means the agent should be able to do a lot of work without pretending it has authority it does not have.
It can summarize a question. It can search prior responses. It can identify similar answers. It can draft language. It can flag uncertainty. It can suggest that security, legal, product, or sales should review a response.
But it should not silently invent capabilities. It should not make roadmap commitments. It should not convert vague source material into contractual certainty. It should not treat a confident sentence as the same thing as a verified answer.
That boundary is not a limitation. It is the product.
The Boring Parts Became More Important
Courses about emerging technology can sometimes push people toward the flashiest demo. What I found useful about the Agentic AI work was almost the opposite. It made the boring parts feel more important.
State management matters. What has been drafted? What has been reviewed? Which source did this answer come from? Is the answer approved or stale?
Evaluation matters. Did the answer actually respond to the question? Did it rely on source material? Did it introduce unsupported claims? Does it match the company's preferred language?
Human handoff matters. Who needs to review a security answer? Who owns implementation timelines? Who can approve legal language? When should the system stop and ask for judgment?
These are not side quests. They are what separate a useful enterprise AI tool from a neat demo.
Retrieval Is Not Enough
Retrieval-augmented generation is a good pattern for this problem, but retrieval alone does not solve it.
Finding a similar answer is helpful. Finding the right answer is better. Knowing whether that answer is still approved is better still. Knowing which product version, customer segment, or contractual posture it applies to is where the system starts to become genuinely useful.
The hard part is not only pulling text from a knowledge base. The hard part is preserving context.
An old answer might be beautifully written and completely wrong because the product changed. A technical answer might be accurate but too detailed for a procurement audience. A roadmap answer might be directionally true but unsafe to put in a formal response.
Nimra needs retrieval, but it also needs metadata, review states, and a healthy suspicion of stale confidence.
The Product Manager Lesson
The most valuable shift for me was realizing that an AI agent is a product teammate with a very unusual set of strengths and weaknesses.
It is tireless at classification, summarization, pattern matching, drafting, and checking for inconsistencies. It is also capable of being confidently wrong, over-literal, and context-blind in ways that create real risk.
That means the product manager's job is not just to decide what the AI should do. It is to decide where the AI should stop.
For Nimra, the stopping points are as important as the automation:
- Stop when the source material is weak.
- Stop when the answer touches legal or security commitments.
- Stop when a product capability is unclear.
- Stop when the model is relying on inference instead of approved knowledge.
- Stop when the response should be owned by a human.
This is not anti-AI. It is how AI becomes usable in serious workflows.
Where Nimra Goes Next
The Product School version helped me frame the customer problem. The Carnegie Mellon Agentic AI course helped me sharpen the architecture of the solution.
Nimra is no longer just an RFP response generator in my head. It is a system for managing the lifecycle of answers:
- Ingest the ask.
- Retrieve the memory.
- Draft the response.
- Expose the uncertainty.
- Route the review.
- Capture the approved answer.
- Improve the next response.
That loop is the product.
And it is why I am still excited about Nimra.ai. The opportunity is not to make people sound like they know the answer. It is to help organizations actually know what they know, say it clearly, and keep getting better each time they respond.