Use this script as a guide for your 8-10 minute project walkthrough.
⏱️ Timestamp: 0:00 - 1:00
"Hi team, thank you for the opportunity. Today I’ll be walking you through my autonomous AI agent API.
When approaching this 60-minute sprint, I treated it exactly like a strict production ticket. I looked directly at the core requirements: build a FastAPI endpoint that takes a natural language request, autonomously creates a task list, executes those steps, generates a polished Word document, and implements exactly one major engineering improvement.
I spent the first 20 minutes exclusively on architectural planning to meet exactly those parameters—mapping out a 4-phase execution loop and defining strict security boundaries. Because I front-loaded the system design, the actual coding and testing went incredibly fast.
Now, while it is always tempting to use that extra time to bolt on extra features, I believe in strict adherence to scope. In a production environment, you don't introduce feature creep just because you finished early. You deliver a secure, robust, and flawlessly executed solution that does exactly what was asked. Let's look at the demo."
⏱️ Timestamp: 1:00 - 2:30
- Attempt a request without the API key header to show
401 Unauthorized. - Inject the API key and run the CRM project plan test.
- Method:
POST - URL:
http://127.0.0.1:8000/agent - Headers:
X-API-Key: fluid-secret-key-2026 - Body:
{
"request": "Draft a project plan for implementing a new customer support CRM system."
}"I’m testing the API here locally. First, let's look at security. An agent API without authentication is a massive vulnerability. If I try to send a request without my X-API-Key header, the system safely rejects it with a 401 Unauthorized.
Let's inject the valid key and run the first test: drafting a standard CRM project plan.
(Click Send and wait 15-18 seconds for Groq to compile)
Look at the JSON response payload. I built an execution_trace directly into the response. This gives developers real-time observability into the agent’s internal phase transitions without needing heavy external tools.
And if we open the generated Word document, you'll see it has clean, executive styling—Arial font and navy headings. I achieved this by building a custom Markdown parser that translates the LLM's output directly into native Word styles."
⏱️ Timestamp: 2:30 - 3:30
- Run the complex request.
- Method:
POST - URL:
http://127.0.0.1:8000/agent - Headers:
X-API-Key: fluid-secret-key-2026 - Body:
{
"request": "Create a technical design document for a high-availability shopping cart service, but it needs to be both extremely secure and cost-efficient under high traffic, while we don't have clear requirements on the hosting provider or database choice."
}"Now for the complex test. I asked the agent for a high-availability shopping cart architecture, but I intentionally left the hosting and database requirements completely ambiguous.
(Click Send and wait 15-18 seconds for Groq to compile)
If we look at the trace and the resulting document, you can see the agent's autonomous reasoning. It realized information was missing, and autonomously decided to evaluate and implement AWS EKS and PostgreSQL with Redis caching to successfully meet the 'high-availability' parameter."
⏱️ Timestamp: 3:30 - 5:00
"Let's talk about the architecture. The agent runs on a native Python procedural loop using Groq's llama-3.3-70b-versatile model across all phases to guarantee top-tier content quality in under 20 seconds of processing.
It executes in four phases: Planner, Drafter, Reflection, and Executor.
In Phase 4, the Executor, instead of hardcoding document rendering, the LLM uses structured tool-calling schema to invoke the document generator function. This displays a clean tool call and argument set inside our trace log, while allowing our backend to validate and sanitize parameters (like checking the filename for path-traversal) before execution.
For my mandatory engineering improvement, I implemented Phase 3: Reflection and Self-Check. One of the biggest problems with autonomous agents is that they drift from their initial plan during the drafting phase. My Reflection phase acts as an automated QA. It analyzes the markdown draft against the Phase 1 plan, identifies missing gaps, and corrects the document before it is ever sent to the file system."
⏱️ Timestamp: 5:00 - 6:00
"During development, the main issue I encountered was LLM output formatting. The Groq model is highly capable, but like most chat-tuned models, it defaults to wrapping raw JSON in Markdown code blocks. This instantly crashes standard JSON parsers.
To fix this, I built a custom strip-and-clean middleware that sanitizes the output before it hits json.loads(). If parsing still fails, the API gracefully catches the exception, logs it to the execution trace, and returns a 500 error instead of throwing a raw crash."
⏱️ Timestamp: 6:00 - end
"Finally, let's discuss tradeoffs. First, Simplicity versus Extensibility. I deliberately chose a native, single-agent loop over a heavy framework like LangChain. For a 60-minute sprint, a native loop guarantees deterministic speed.
Second is State Management. Because this is a synchronous endpoint, managing the agent's state completely in-memory was the correct choice. However, if I were deploying this in a production environment with long-running, asynchronous background tasks, I would transition to a file-based memory system—like a persistent task.md scratchpad—to ensure the agent doesn't lose context over time.
That covers the architecture, the demo, and my core engineering decisions. Thank you for your time."