Experimenting with Custom Agents in Amazon Q

Last Tuesday started like most Tuesdays: three Slack messages from different clients, two emails with “urgent” in the subject line, and a CloudWatch alarm - all before my first coffee.

One client needed help optimizing their RDS instance. Another wanted clarification on a security group configuration before their production launch. The third was asking about best practices for the Lambda function we worked on last week.

Each request was valid. Each needed attention. But first, I had to:

• Parse what they were actually asking for
• Identify what information was missing (“Which RDS instance?” “What’s the launch deadline?” “Which Lambda functions?”)
• Prioritize based on urgency and complexity
• Context-switch between multiple different customers and AWS accounts

This is the reality of solo consulting—and it’s where my experiment with Amazon Q custom agents began.

The Consultant’s Dilemma

As an independent AWS consultant, I spend my days helping customers get the most value from their cloud environments. The variety is what I love about this work—every client engagement brings different challenges, different architectures, different problems to solve.

But that variety comes with a hidden tax: cognitive overhead.

Unstructured requests arrive constantly through multiple channels—Slack, email, phone calls. Some are simple (“Can you check this CloudWatch metric?”). Others are complex and require hours of investigation. Some are genuinely urgent. Others just feel that way.

Before I experimented with custom agents, I spent hours each week on request triage: reading between the lines, asking clarifying questions, assessing priority, and organizing my work queue. It was necessary work, but it wasn’t the high-value AWS expertise my clients were paying for.

That’s when I started asking: what if AI agents could handle the repetitive patterns in my workflow?

My Experiment: Custom Agents for Request Processing

After spending more time with Amazon Q, I realized its custom agents feature could address my specific pain points. Instead of trying to automate everything, I focused on the repetitive cognitive work that was consuming my time: understanding, structuring, and prioritizing customer requests.

The goal was simple: take unstructured input from any channel and transform it into something I could immediately act on—with all the context, gaps, and priority clearly identified.

Here’s how I structured my approach.

The Setup

My current environment revolves around Amazon Q custom agents connected through Docker Desktop’s MCP Toolkit, which acts as a centralized hub for Model Context Protocol integrations: ![[amazon-q-custom-agents.png]]From this hub, Amazon Q (CLI), Claude Desktop, and Kiro all connect to various MCP services. This centralized configuration means I don’t have to manage MCP connections separately for each tool—a huge time saver when you’re juggling multiple AI assistants.

NOTE: I’m currently working through some integration issues between my custom agents and the Docker MCP Toolkit. Consider this a live experiment.

The Request Processor: My Foundation Agent

My custom agent journey started with what I call the Request Processor. This is the workhorse of my setup.

What It Does

The Request Processor takes any unstructured customer request and:

1. Extracts the core technical question
2. Identifies the AWS services involved
3. Flags missing information that I’ll need
4. Assesses urgency based on keywords and context
5. Outputs everything in structured markdown

Why This Matters

Instead of spending 15-20 minutes per request doing mental parsing, I paste the message into the agent and get back a clear, actionable summary in seconds.

Here’s an example input:

Here's a slack message I just received from a customer: The operations team is 
no longer able to access the logging S3 bucket in the XYZ application account. They 
told me it worked just fine yesterday. Could you look at it and see what you can 
find? Just FYI, they are concerned about not being to get access to the log data 
in the bucket.

Here’s an example of the agents response:

# S3 Logging Bucket Access Issue - Operations Team

**Request ID:** s3-logging-bucket-access-issue-20251003  
**Date:** 2025-10-03  
**Priority:** High  
**Category:** Access Management / Troubleshooting  

## Request Summary

Operations team has lost access to logging S3 bucket in XYZ application account. 
Access was working yesterday but is now failing. Team needs access restored to 
retrieve log data.

## Problem Analysis

### Symptoms
- Operations team cannot access logging S3 bucket
- Access worked previously (yesterday)
- Sudden loss of access suggests recent configuration change
- Team concerned about inability to retrieve log data

### Potential Root Causes
1. **Bucket Policy Changes** - Policy may have been modified or removed
2. **IAM Permission Changes** - User/role permissions may have been altered
3. **Cross-Account Access Issues** - Trust relationships or external account policies
4. **Resource-Based Policy Conflicts** - New deny statements or policy precedence issues
5. **Service Control Policies** - Organization-level restrictions
6. **VPC Endpoint Policies** - Network-based access restrictions
...

Now I have everything I need: a clear understanding of the problem, a checklist of questions to ask, and confirmation that this needs immediate attention.

The output is markdown, so I can read it anywhere - store it in my Obsidian vault, paste it into a ticket, or reference it during troubleshooting.

The AWS Knowledge MCP Integration

Here’s a typical workflow with the agent:

The Supporting Cast: Other Agents

Once the Request Processing proved its values, I build three other additional agents to handle other workflow friction points:

Git Agent

I’m not a Git expert, but I use it every day. My interactions are straightforward: commit changes, push updates, create branches. Instead of remembering exact syntax or switching contexts to run command, I simply tell the Git agent what I need.

Example: “Review the latest changes, commit them, and push”

The agent handles Git command while I stay focused on the technical work.

Obsidian Agent

My Obsidian vault is my second brain - it’s where I store all long-term information, customer context, and technical notes. Rather than manually opening the vault and formatting notes, I let the agent handle the busywork.

Example: “Take the latest troubleshooting context from this OrbitGUARD session, create a new notes in my vault, and tag it so I can find it later.”

The agent creates properly formatted notes with appropriate tags and links, maintaining my vault’s structure without my thinking out it.

Context Logger

As with all GenAI tools, Amazon Q’s responses can drift as context windows grow large. I use the Context Logger to periodically save summaries of what we’ve accomplished in an easily digestible format - both for me and for Q in future sessions.

Example: After resolving a complex issue, I’ll say: “Great work helping me solve that problem. Let’s record what we accomplished: describe the problem, root cause, and resolution so we can reference it if similar issues come up later”

This creates a clean record I can search later, and it helps prevent me from re-explaining background context when I return to a topic days or weeks later.

The Infrastructure: Docker MCP Toolkit

You’ve probably noticed I keep mentioning Docker Desktop’s MCP Toolkit. If you haven’t explored it yet, I’d strongly recommend spending time with it.

Why Centralize MCP Configuration Matters

Here’s the problem it solves: every AI tool that supports Model Context Protocol (MCP) needs its own configuration. That means managing separate configs for Claude Desktop, Amazon Q, Kiro and any other tools you adopt.

Docker’s MCP Toolkit acts as a central hub. Configure your MCP connections once, and all your AI tools can access them. Want to add a new MCP server? Update one configuration, and it’s available everywhere.

For someone who regularly talks with customers about tool integration strategies, using the tools myself is essential. The MCP Toolkit lets me experiment rapidly without configuration overhead.

Current Setup: Amazon Q CLI, Kiro and Claude Desktop all connecting through the toolkit to various MCP servers including Obsidian, and several AWS MCP offerings.

Early Wins

With just a few focused agents and the supporting infrastructure, I’ve already seen tangible benefits:

• Request triage time reduction: I’m able to turn unstructured customer requests into something I can quickly action much faster than before
• Context switching eliminated: I stay in my problem-solving environment instead of jumping between tools
• Documentation quality improvement: Automated note-taking means better records with less effort - you still have to read them though :)
• Faster customer turnaround: More time solving problems, less time organizing work The impact has been immediate: less friction in my day, and quicker turnaround for my customers.

What’s Next?

This is just the beginning. I’ve started small with agents that address specific pain points in my daily workflow, but I’m already considering others.

What’s exciting about custom agents is the low barrier to experimentation. If you can articulate a repetitive workflow, you can likely build an agent to handle it.

My hunch: the best GenAI workflows for consultants won’t be one-size-fits-all. They’ll be tailored, composable, and deeply personal—reflecting how each of us actually works, not how we wish we worked.