Developer portfolio websites are dead.

Or at least the static ones are. In 2026, AI tooling can now easily create static websites with just a couple of prompts. So, how does a portfolio distinguish itself from all the AI slop? Simple, with more AI — but with the kind you actually build.

My goal was to move beyond the traditional resume-as-a-website. I wanted to incorporate a generative AI component that understands my engineering profile and can answer complex user queries about me.

I also wanted to learn to build and deploy LLM functionality end-to-end.

The Architecture

Three Tier Architecture — Frontend, Backend and Agent

As with any new project, it is best to keep it as simple as possible. The frontend is built with Next.js, and the backend utilizes FastAPI. This is all as usual and needs no further discussion.

The Agent is powered by the Strands Agent framework. It is an agent orchestration layer that abstracts away a lot of the complexity of calling an LLM via an API. It handles things such as tool calling via the agent loop, state, session management, and a lot more. It is also model and provider agnostic, so any of the available frontier models can be used, though it has a native integration into AWS Bedrock.

Other orchestration layer solutions do exist, such as LangChain or CrewAI. However, Strands has a native AWS integration that makes it really easy to deploy to the cloud.

I initially tried to integrate the Agent into the same microservice as the backend, and was running into quite a few dependency conflicts, so I split them up into separate microservices.

Deployment

I didn’t really expect the website to receive a whole lot of traffic all the time, only bursts of usage whenever someone happens to stumble upon it. Though I did want it to handle the load if I do eventually end up getting some traffic. Hence, I decided to go for a fully serverless setup.

The frontend is hosted on AWS S3 as a static website, the backend API is all run on a single AWS Lambda, and the Agent is hosted on AWS Agentcore Runtime, which calls Bedrock under the hood.

DynamoDB is used as a serverless DB, and it’s used for a few purposes. Firstly, it hosts all my blog posts in order to make them available to both the frontend for the user to view and also to the Agent so that it can answer questions about my blog. Secondly, it is used by the Strands Framework to do session management and persist chat history. I plan to use the stored chat conversations to do evals and understand how users use the chatbot.

You’ll notice that there are actually two lambda endpoints. I had to add a second “chat” lambda purely to achieve streaming responses from the Model all the way through to the UI for the user.

Streaming

LLMs generate “tokens” which represent subsections of words or groups of words. They also generate tokens sequentially, which means that for large texts, it can take a while for them to generate the entire output. Hence, to improve the UX, AI Engineers send each token to the user as it comes out of the model. This process uses a method called “response streaming” to send each token as it is generated.

The architecture required two levels of streaming, first, from the Model to the Backend, and then from the Backend to the UI.

The former was straightforward to achieve via the Strands Framework. The following snippet demonstrates this.

agent = Agent(
    system_prompt=system_prompt,
    session_manager=session_manager
)

stream = agent.stream_async(user_message, session_id=session_id)
async for event in stream:
  clean_event = # Code to process the event and clean
  if clean_event:
     yield clean_event

This allows the Backend to receive each token from Bedrock as it’s generated.

The process to get the tokens from the Backend to the UI was more complicated. This was largely because API Gateway doesn’t support streaming. It only supports HTTP requests that follow a request and response pattern. This limited the UI to having to wait for the entire response from the backend before it could be shown to the user.

The solution here was simply to use Lambda Function URLs. This is a simple feature of AWS Lambda that assigns a HTTPS url that can be used to invoke the Lambda. This method does support streaming and even has a larger max timeout of 15 minutes (compared to API Gateway’s limit of 29s) that can be taken advantage of to stream large responses. The tradeoff with this approach is the lack of robustness of features that come with API Gateway, such as rate limiting, WAF, and API management.

Therefore, a 2 lambda solution was appropriate in this case. One lambda in front of API Gateway would serve the UI with blog, auth and other functionality. The other would be exclusively responsible for handling chat requests and streaming the responses back to the UI.

Sample code to setup a streaming lambda URL in Serverless framework with Lambda Web Adapter:

apiStream:
  handler: run.sh  # Lambda Web Adapter will handle the FastAPI app
  timeout: 300  # 5 minutes for long streaming responses
  layers:
    - Ref: PythonRequirementsLambdaLayer
    # Lambda Web Adapter Layer for response streaming support
    - arn:aws:lambda:${self:provider.region}:753240598075:layer:LambdaAdapterLayerX86:25
  environment:
    AGENT_SERVICE_URL: arn:aws:bedrock-agentcore:ap-southeast-2:136079914867:runtime/website_agentV2-ZY35by5UAQ
    AWS_LAMBDA_EXEC_WRAPPER: /opt/bootstrap  # Use Lambda Web Adapter wrapper
    AWS_LWA_INVOKE_MODE: response_stream  # Enable Lambda Web Adapter streaming mode
  url:
    cors:
      allowedOrigins:
        - 'https://sushensatturu.com'
      allowCredentials: false
    invokeMode: RESPONSE_STREAM  # Enable response streaming

*Edit: API Gateway added streaming support in November 2025, which was after this app was built.

Prompt Engineering and Agent Tools

Now that the infrastructure is dealt with, we get to look at the fun stuff, prompt engineering the Agent in order to get useful output. I wanted as little static content as possible in the base system prompt, with the option for the agent to pull more information via tools. The approach keeps the total token usage to a minimum and only pulls in relevant information when needed.

I broke the system prompt into roughly 3 sections:

Instructions

You are an AI assistant representing Sushen Satturu, a Software Engineer based in Melbourne, Australia.

YOUR ROLE:
You help visitors learn about Sushen Satturu’s background, skills, work experience, projects, and blog content in an engaging and informative way.

PERSONALITY & TONE:
- Professional yet approachable and friendly
- Knowledgeable and enthusiastic about technology
- Helpful and conversational
- Accurate and detail-oriented

SUSHEN’S BIO:
<My Bio Information>

This briefly and succinctly sets the main directive of the Agent and also provides the baseline information about me so that the Agent has an understanding of who I am.

2. Formatting requirements

- **BREVITY IS CRITICAL** — Keep all responses SHORT (2–4 sentences typical)
- Only provide extended detail when explicitly requested
- **ALWAYS format your responses using Markdown**
- Use proper Markdown syntax for:
- **Bold** text for emphasis
- *Italic* text for subtle emphasis
- `code` for technical terms, file names, and inline code
- Bullet lists with `-` or `*` (prefer over long paragraphs)
- Links with `[text](url)` format
- ```code blocks``` for multi-line code examples

The LLM output is rendered using `ReactMarkdown` so the agent must output Markdown text.

Note the “Brevity Is Critical” instruction; this was added after some testing where the LLM was generating large chunks of text (AI Slop), which did not add a lot of value to the final response.

3. Tools for knowledge retrieval

AVAILABLE TOOLS:
You have access to comprehensive tools for querying:
- Profile & About: get_about_me(), get_skills(), get_education()
- Work Experience: get_work_experience(), get_experience_details()
- General: get_contact_info(), get_resume_summary()
- Blog: list_recent_blog_posts(), get_blog_post()
- Projects: list_projects(), get_project(project_id)

These tools allow the agent to retrieve relevant information only when it’s needed, when prompted by the user.

The final prompt and tools setup was done through quite a bit of experimentation and tweaking. In building this, I’ve learnt some heuristics and guidelines for prompt engineering, which I’ll write about in the future.

Let’s look at some results!

Results

It’s clear from this example that the chat can answer basic questions about me and also maintain context across messages in a single session.

In this example, the agent demonstrates awareness of the user’s current page. It knows which blog post to retrieve and summarize.

This example demonstrates the agent’s ability to pull information from multiple tools to answer the user’s question.

Security and Usage

Since this chatbot is live on my public website, I spent a fair amount of time thinking about the security of the chatbot.

I wanted to avoid receiving a massive AWS bill for LLM token usage. Therefore, I implemented a simple rate limiter on the backend to restrict the number of chat requests per minute. It’s currently at 20 requests per minute, which should be able to handle one or two concurrent users at a time. I also downgraded the model used from Claude Sonnet 4.5 to Claude Haiku 4.5 in order to really keep the costs down. I did notice a significant downgrade in the quality of the answers provided by the smaller model, but it was enough to cover the basic usage of the chatbot while significantly reducing costs. Lastly, I added a cost alert to the AWS Costs and Billing management service to send me a text if the usage ever gets beyond a certain threshold.

I added other sensible security measures, such as the AWS WAF and GuardDuty, to protect against all the other common security vulnerabilities.

Conclusion

This was a fun project that taught me quite a lot about LLM and agent development. Dealing with the challenges at the model level, such as prompt engineering, tool usage, and model selection. To solving problems at the infrastructure layer, such as architecture, streaming, and security, I now have a solid understanding of deploying Generative AI functionalities end-to-end.

If you’d like to take a look at the code it is available on my GitHub.

There are a lot more problems in this space that I plan to investigate in the future, such as:

Agent Evals
LLM Session and Context Management
Multi-Agent Architecture
AI Data Analysis

Stay tuned while I explore these topics further!

Ask about Sushen