Amazon Quick: The Day My IDE, Terminal, CRM, and Cloud Console Became One Conversation

I fixed a bug in production last Tuesday. The bug was in a React booking calendar — check-in and check-out days were being blocked, preventing same-day turnovers. Diagnosing it took 30 seconds. The fix took 3 minutes.

I never opened VS Code. I never opened a terminal. I never ran git push.

I described the problem in natural language, an agent analyzed the codebase, applied a surgical two-line fix, rebased on main, and pushed. I stayed in the same chat window where I’d been discussing ML forecasting models five minutes earlier.

This is what working with Amazon Quick feels like after a week. And it’s forcing me to rethink what “development” even means.

What Amazon Quick Actually Is

Amazon Quick is a desktop application — a conversational AI work companion that runs locally on your machine. Think of it as a persistent AI colleague that has access to your entire work surface:

• Local filesystem — reads and writes files in your allowed folders
• Outlook — email, calendar, contacts
• Slack — channels, DMs, search
• AWS APIs — all 15,000+ actions via the Agent Toolkit MCP server
• SharePoint, Asana — project management and documents
• Code execution — sandboxed Python and JavaScript
• Knowledge graph — auto-built from your communications, persists across sessions
• Scheduled agents — autonomous recurring tasks

The key architectural choice: it uses MCP (Model Context Protocol) as its universal connector layer. Any MCP server — AWS, custom, community — plugs in. Your local coding agents (Kiro, Claude Code) connect via ACP (Agent Client Protocol) for task delegation.

The Workflow Collapse

Here’s what a typical hour looks like now versus two weeks ago:

Before Amazon Quick:

1. Open Outlook — check calendar for today’s meetings
2. Open Slack — catch up on channels
3. Open CRM — check account status
4. Open VS Code — fix a bug
5. Open terminal — git commit, push
6. Open AWS Console — verify deployment
7. Open Obsidian — write meeting notes
8. Open browser — research a technical question

Eight context switches. Eight different authentication flows. Eight mental models.

With Amazon Quick:

1. “What’s on my calendar today?” — done
2. “Any important Slack messages?” — done
3. “Pull up recent activity for this account” — done
4. “Fix the calendar bug in heritage-chalet” — dispatched to Kiro, done in background
5. “List my S3 buckets” — AWS API call, instant
6. “Summarize yesterday’s meeting and draft follow-up” — done
7. “Research Chronos-2 vs XGBoost for sparse demand” — web search, synthesis, done

One interface. One authentication context. One conversation thread that maintains state across all these operations.

ACP: Delegating to Coding Agents

The most powerful pattern I’ve found is the hybrid orchestration model. Amazon Quick excels at:

• Reading and reasoning about code (fast, broad context window)
• Calling APIs (AWS, Outlook, Slack via MCP)
• Data analysis and document generation
• Planning and decomposing tasks

But it cannot run npm install, git push, or spin up a dev server. My local coding agents (Kiro, Claude Code) can.

The bridge is ACP — Agent Client Protocol. From the same chat, I dispatch a natural language instruction to Kiro:

“In /path/to/project, modify the calendar blocking logic so check-in/check-out days remain available. Run the dev server to verify. Don’t commit.”

Kiro receives this as a task, autonomously explores the code, implements the fix, tests it, and reports back. If I want it to commit and push, I just say so in a follow-up message.

The mental model: Amazon Quick is the orchestrator with broad context (email, calendar, AWS, knowledge graph). Kiro/Claude Code are the executors with deep local access (terminal, filesystem, build tools). Different superpowers, same conversation.

The Knowledge Graph: Institutional Memory

After a week of connected usage, Amazon Quick builds a knowledge graph from your Slack messages, emails, calendar events, and local files. It knows:

• Who you work with and on what projects
• What was discussed in last week’s meeting with Customer X
• What decisions were made and what’s still open
• Which documents relate to which initiatives

This compounds. Today’s meeting prep brief surfaces decisions from three meetings ago. A customer question triggers recall of a Slack thread from last month. The system develops institutional memory that individual humans lose.

The AWS MCP Server: 15,000 APIs in a Chat

The Agent Toolkit for AWS — which I wrote about in a previous post — becomes even more powerful inside Amazon Quick. Instead of wiring it into a custom Strands agent with safety patterns, it’s pre-configured and ready:

Me: "Show me my S3 buckets"
Quick: [calls aws s3 ls] -- here are your buckets, organized by project...

Me: "What's my caller identity?"
Quick: [calls aws sts get-caller-identity] -- you're authenticated via SSO with AdministratorAccess...

Me: "Check if Bedrock is available in eu-west-3"
Quick: [calls get_regional_availability] -- here's the status...

No terminal. No CLI configuration. No copy-pasting ARNs between windows.

What This Means for Developers and SAs

After a week, three shifts are becoming clear:

1. The value moves from execution to judgment

I didn’t write the calendar fix. I didn’t manually search my email. I didn’t type AWS CLI commands. I described intent and validated output.

The irreplaceable part was knowing that the fix should shift dates by +1/-1 day. The implementation was delegated. This is a fundamental shift: your value is no longer in typing speed or tool mastery. It’s in problem decomposition, quality assessment, and architectural judgment.

2. Context switching is the real productivity killer

I always knew context switching was expensive. But I didn’t realize how much cognitive load was just navigating between tools — not the actual thinking. When everything flows through one interface, the thinking becomes continuous. You’re never “loading” a new tool’s mental model.

3. The 10x engineer becomes the 100x orchestrator

The new leverage isn’t knowing more commands or frameworks. It’s:

• Decomposing problems into parallelizable agent tasks
• Writing precise instructions (prompts are the new code)
• Building reusable automation (skills, scheduled agents)
• Maintaining quality through review, not implementation

The Honest Limitations

This isn’t a puff piece. After a week, the friction points are real:

• MCP connections can drop — credential expiry, proxy restarts. When the AWS MCP goes dark, you’re back to the terminal.
• Agent delegation is not deterministic — Kiro might interpret your instruction differently than you intended. You still need to review diffs.
• Knowledge graph is not authoritative — it’s extracted context, not ground truth. Verify before acting on it.
• No offline mode — the AI models run on Bedrock. No internet, no Quick.

The Bigger Picture

Products like Amazon Quick don’t replace developers. They compress the feedback loop between intent and execution from hours to seconds. The competitive advantage shifts from “can you build it?” to “can you describe what to build clearly enough, fast enough, and validate it correctly?”

The developers who thrive will be those who embrace the orchestration layer while maintaining deep enough technical understanding to catch when the agents are wrong. The ones who struggle will be those who either:

• Refuse to delegate (and get outpaced by those who do)
• Delegate blindly (and ship broken code they can’t debug)

The sweet spot is informed orchestration. And after a week with Amazon Quick, I’m convinced this is what development looks like in 2027 for everyone — not just early adopters.

---

I’m Alexandre Agius. I build with AI agents daily and write about what works (and what doesn’t) at agiusalexandre.com. If you’re exploring agentic workflows, reach out — I’m always happy to trade notes.