AWS has been building agentic infrastructure for some time now — Bedrock, AgentCore, Strands — mostly aimed at engineers who want to build their own agent systems from scratch. Amazon Quick is a different layer of the same bet: a ready-to-use agentic workspace that targets teams directly, without requiring custom orchestration code.

This article walks through what Quick is, how its components fit together technically, how the MCP integration model works with real code, and where it sits relative to the rest of AWS's agent stack.

What Amazon Quick Is

Amazon Quick is an AI assistant for work that connects to your existing tools — Slack, Microsoft Teams, Outlook, CRMs, databases, and local files — and gives a unified layer for querying, automating, and acting across them. It launched in preview at AWS's "What's Next with AWS" event on April 28, 2026.

The product is aimed at teams, not just individual users. One person can build a custom agent scoped to a specific dataset or workflow, and the whole team benefits from it. Responses from Quick agents are grounded in your actual business data, not the underlying model's training distribution.

Under the hood, Quick is built on Amazon Bedrock AgentCore and uses the Model Context Protocol (MCP) as its standard for connecting to external tools. It runs on AWS IAM and VPC, which means it inherits the same security and compliance posture as the rest of your AWS workloads.

Product Components

Quick bundles five distinct capabilities. It helps to understand each one separately before thinking about how they compose.

Each component is available through the web app, mobile, and a native desktop app (currently in preview for macOS and Windows) that can read local files and calendar context without requiring browser access.

Where Quick Sits in the AWS Agent Stack

AWS is building in two directions at once. AgentCore is the infrastructure layer for engineers who want to compose their own agent systems — runtime, memory, gateway, observability — with any model and any framework. Quick is the product layer on top: opinionated, team-facing, and deployable without writing orchestration code.

The practical implication: if you're an engineer building internal tools or automation pipelines, you'll likely interact with both layers. AgentCore for the infrastructure wiring; Quick as a surface where non-technical teammates interact with the agents you build.

The Integration Architecture

The core question for any engineer evaluating Quick is: how does it actually connect to external systems, and what does the request path look like?

Quick uses MCP (Model Context Protocol) as its primary integration standard. This is significant because MCP is an open protocol — it means Quick agents are not locked into AWS-specific connectors, and any MCP-compatible server can be registered as a tool source.

High-Level Request Flow

The sequence below shows the full lifecycle of a single agent-triggered tool call — from the moment Quick receives a prompt through to the response returning from a downstream API.

Quick acts as the MCP client. Your MCP server exposes tools via listTools and callTool. Quick discovers them at registration time and makes them available to any agent or automation in the workspace. Authentication flows through OAuth 2.0, with support for Dynamic Client Registration (DCR) so Quick can register itself automatically without manual credential setup.

Building an MCP Server for Quick

Here is a minimal Python MCP server using the mcp SDK that exposes two tools Quick can invoke — get_ticket and list_open_tickets. This pattern works whether you host the server yourself or run it on AgentCore Runtime.

Install dependencies

pip install mcp[server] httpx uvicorn

Server implementation

# server.py
from mcp.server import Server
from mcp.server.sse import SseServerTransport
from mcp.types import Tool, TextContent
import httpx
import json
from starlette.applications import Starlette
from starlette.routing import Route

app = Server("jira-quick-integration")

JIRA_BASE_URL = "https://yourorg.atlassian.net"
JIRA_TOKEN    = "Bearer <your-token>"  # in production, load from AWS Secrets Manager


@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="get_ticket",
            description="Retrieve details for a single Jira ticket by issue key.",
            inputSchema={
                "type": "object",
                "properties": {
                    "issue_key": {
                        "type": "string",
                        "description": "The Jira issue key, e.g. ENG-1234"
                    }
                },
                "required": ["issue_key"]
            }
        ),
        Tool(
            name="list_open_tickets",
            description="List open Jira tickets assigned to a given user.",
            inputSchema={
                "type": "object",
                "properties": {
                    "assignee": {
                        "type": "string",
                        "description": "The Jira username or email of the assignee"
                    }
                },
                "required": ["assignee"]
            }
        )
    ]


@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    headers = {"Authorization": JIRA_TOKEN, "Content-Type": "application/json"}

    async with httpx.AsyncClient() as client:
        if name == "get_ticket":
            key = arguments["issue_key"]
            resp = await client.get(
                f"{JIRA_BASE_URL}/rest/api/3/issue/{key}",
                headers=headers
            )
            resp.raise_for_status()
            data = resp.json()
            summary = data["fields"]["summary"]
            status  = data["fields"]["status"]["name"]
            return [TextContent(type="text", text=f"{key}: {summary} [{status}]")]

        elif name == "list_open_tickets":
            assignee = arguments["assignee"]
            jql = f"assignee={assignee} AND status != Done ORDER BY updated DESC"
            resp = await client.get(
                f"{JIRA_BASE_URL}/rest/api/3/search",
                headers=headers,
                params={"jql": jql, "maxResults": 20}
            )
            resp.raise_for_status()
            issues = resp.json().get("issues", [])
            results = [
                f"{i['key']}: {i['fields']['summary']}"
                for i in issues
            ]
            return [TextContent(type="text", text="\n".join(results) or "No open tickets found.")]

    raise ValueError(f"Unknown tool: {name}")


# Wire up SSE transport for Quick compatibility
sse = SseServerTransport("/messages/")

async def handle_sse(request):
    async with sse.connect_sse(
        request.scope, request.receive, request._send
    ) as streams:
        await app.run(streams[0], streams[1], app.create_initialization_options())

starlette_app = Starlette(
    routes=[Route("/sse", endpoint=handle_sse)]
)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(starlette_app, host="0.0.0.0", port=8080)

A few design constraints to be aware of when building for Quick:

• Each MCP tool call has a 300-second hard timeout. Operations that exceed this fail with HTTP 424. Keep individual tool calls narrow and fast.
• The tool list is treated as static after registration. If you add or remove tools on the server, the Quick admin must re-establish the connection to pick up changes.
• Quick supports both Server-Sent Events (SSE) and streamable HTTP as transports. Streamable HTTP is preferred for new implementations.

Registering the MCP Server in Quick

Once your server is running and publicly reachable over HTTPS, registration in Quick takes the following path:

Quick Console → Integrations → Add Integration → MCP

Fields:
  Server URL:        https://your-mcp-server.example.com/sse
  Auth type:         OAuth 2.0 (or Service, or None)
  Client ID:         <from your identity provider>
  Authorization URL: https://auth.example.com/oauth/authorize
  Token URL:         https://auth.example.com/oauth/token

If your identity provider supports OAuth Dynamic Client Registration, Quick will auto-register and you skip the manual client ID step entirely. Quick sends an initial unauthenticated request to the MCP server; if it receives a 401 with a WWW-Authenticate header containing a resource_metadata URL, it fetches the metadata document and proceeds with DCR automatically.

Once registered, Quick calls listTools at startup and exposes every discovered tool to agents and automations in the workspace.

The AgentCore Gateway Option

For teams that don't want to write and operate an MCP server from scratch, Amazon Bedrock AgentCore Gateway provides a managed alternative. You point Gateway at a Lambda function or an OpenAPI spec, and it handles the MCP wrapping, auth, logging, and semantic tool discovery automatically. If you use it, Quick never calls your internal APIs directly — everything flows through Gateway's auth and routing layer, as shown in the sequence diagram above.

The semantic search capability is worth noting specifically. When an agent has access to dozens or hundreds of tools, passing the full tool list on every turn wastes context and causes the model to pick the wrong tool. Gateway's built-in x_amz_bedrock_agentcore_search tool lets Quick find the right tool by semantic similarity rather than scanning the entire registry each turn.

Practical Considerations

A few things worth keeping in mind before integrating:

Tool scope matters. When agents are given too many tools simultaneously, selection accuracy degrades — the model reasons over too many options per turn and picks incorrectly more often. Keeping each agent or MCP server to a focused set of 3–5 tools produces better results than exposing everything through one endpoint. This is a known pattern in multi-agent architectures and applies equally to Quick agents.

The 300-second timeout is real. Design each tool call to complete a single, bounded operation. Avoid chaining multiple downstream API calls inside a single tool invocation. If you need a multi-step workflow, model it as separate tools and let the agent orchestrate the sequence.

Local context on the desktop app. The desktop app reads local files and calendar events directly, without upload. For engineers who work primarily in terminals and local editors, this is a meaningful integration point — meeting context, local documentation, and recent file changes are all available to the assistant without any configuration.

MCP interoperability. Because Quick uses MCP as the standard, the same MCP server you build for Quick can also be consumed by Claude Code, Amazon Q Developer, and other MCP-compatible clients. The integration contract is portable.

References

1. Amazon Quick — Product overview and features
2. Integrate external tools with Amazon Quick Agents using MCP (AWS ML Blog, Feb 2026)
3. MCP integration — Amazon Quick User Guide
4. Amazon Bedrock AgentCore — Overview and documentation
5. Introducing Amazon Bedrock AgentCore Gateway (AWS ML Blog)
6. Top announcements of the What's Next with AWS, 2026 (AWS News Blog, Apr 2026)