Blog

Por que sistemas com um único agente não são suficientes

À medida que aplicações de IA avançam além dos chatbots tradicionais, as equipes de engenharia se deparam com um problema concreto: fluxos de trabalho corporativos complexos exigem expertise especializada, decisões dinâmicas e mecanismos robustos de recuperação de falhas — e um único agente raramente dá conta de tudo isso.

O setor financeiro é um exemplo claro. Sistemas de vigilância de mercado precisam coordenar múltiplos agentes especializados para analisar padrões de negociação, investigar atividades suspeitas e produzir relatórios completos, tudo dentro de padrões rígidos de conformidade. Para esse cenário, a AWS publicou um guia técnico detalhando como arquitetar e implantar um sistema multi-agente usando LangGraph e Strands sobre a infraestrutura AWS. O código completo está disponível no GitHub.

A divisão de responsabilidades entre LangGraph e Strands

A arquitetura proposta separa claramente as responsabilidades entre os dois frameworks. O LangGraph cuida da orquestração macro: gerencia o estado compartilhado, define o grafo direcionado de execução e garante a confiabilidade do fluxo. O Strands atua como motor de raciocínio dentro de cada nó individual, executando o loop de análise com o LLM e chamando ferramentas externas conforme necessário.

O LangGraph se destaca no controle granular de execução e no gerenciamento de estado entre agentes. Sua camada de persistência via checkpoints viabiliza recursos críticos para produção, como recuperação de falhas e interações com humano no loop. Já o Strands é agnóstico de modelo — integra-se com diferentes provedores de LLMs — e oferece observabilidade abrangente sobre cada etapa de raciocínio.

Com o lançamento do Amazon Bedrock AgentCore, colocar essa solução em produção ficou consideravelmente mais simples. A combinação dos três forma uma base sólida para sistemas agênticos prontos para ambientes corporativos.

Como o Strands executa o raciocínio nos nós

O Strands Agent opera em um loop de raciocínio que avalia continuamente as saídas das ferramentas e toma decisões com base nos resultados intermediários. Ele inclui gerenciamento de sessão e estado, além de mecanismos para evitar que a janela de contexto estoure.

No agente de vigilância de mercado, a descoberta de dados é separada da recuperação para evitar alucinações e fortalecer a solução contra ataques de injeção de SQL. Ferramentas como get_report_list e get_report_schema localizam os relatórios disponíveis, enquanto run_report constrói a consulta SQL com parâmetros validados e a executa — o LLM nunca escreve SQL diretamente. Veja a definição do agente security_monitor:

from strands import Agent, tool
from strands.models.bedrock import BedrockModel

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-6",
    region_name="us-east-1",
    max_tokens=16000,
    additional_request_fields={
        "thinking": {"type": "adaptive", "budget_tokens": 8000},
    },
    cache_prompt="default",
)

@tool
def get_report_list(agent_name: str) -> str:
    """Load the list of available reports for a specific agent.

    Args:
        agent_name: Name of the agent (e.g. 'security_monitor').

    Returns:
        str: JSON array of report objects with name and description.
    """
    reports_data = load_agent_reports(agent_name)
    return json.dumps(reports_data["reports"], indent=2)

@tool
def get_report_schema(report_name: str, query_intent: str) -> str:
    """Load column definitions for a report so you can build queries.

    Args:
        report_name: Name of the report (e.g. 'TradeActivity').
        query_intent: Description of what data to extract.

    Returns:
        str: JSON object with parameters and column definitions.
    """
    return json.dumps(load_json_report_definition(report_name), indent=2)

@tool
def run_report(
    report_name: str,
    filters: Dict[str, Any],
    limit: Optional[int] = None,
) -> Dict[str, Any]:
    """Run a predefined report. The tool validates every filter against the report's
    schema and builds a parameterised SQL query. The LLM never writes raw SQL,
    so filter values cannot be injected into the query.

    Args:
        report_name: A report from `get_report_list` (e.g. 'TradeActivity').
        filters: Equality filters keyed by column name,
                 e.g. {"symbol": "AAPL", "date": "2024-03-15"}.
        limit: Optional row cap (1..10000).

    Returns:
        dict: {'success': bool, 'data': str (CSV), 'error': str or None}
    """
    schema = load_json_report_definition(report_name)
    allowed_columns = {c["name"] for c in schema["columns"]}

    # Reject any filter field that is not in the report's allowed list of columns.
    unknown = set(filters) - allowed_columns
    if unknown:
        raise ValueError(
            f"Unknown filter field(s) {sorted(unknown)} for {report_name}. "
            f"Allowed: {sorted(allowed_columns)}"
        )

    # Build SQL with named bind parameters.
    where = " AND ".join(f"{field} = :{field}" for field in filters)
    sql = f"SELECT * FROM {schema['reportName']}"
    if where:
        sql += f" WHERE {where}"
    if limit is not None:
        if not isinstance(limit, int) or not 1 <= limit <= 10_000:
            raise ValueError("limit must be an integer in [1, 10000]")
        sql += f" LIMIT {limit}"

    return query_market_data(report_name=report_name, sql=sql, bind=filters)

security_monitor = Agent(
    model=model,
    system_prompt=SECURITY_MONITOR_PROMPT,
    tools=[get_report_list, get_report_schema, run_report],
    name="security_monitor",
)

Como o LangGraph orquestra o fluxo completo

O LangGraph sustenta a orquestração de nível de produção por meio de três pilares:

• Máquinas de estado baseadas em grafos: fluxos de trabalho são modelados como grafos direcionados — nós representam a lógica de cada agente e arestas determinam o caminho de execução, com suporte a ramificação condicional, execução paralela e roteamento dinâmico.
• Persistência de estado via checkpoints: após cada nó executado, o estado completo do fluxo é salvo automaticamente. Isso viabiliza recuperação de falhas, conversas de múltiplos turnos e investigações de longa duração.
• Confiabilidade em produção: o framework inclui estratégias de retry com backoff exponencial e observabilidade via OpenTelemetry, compatível com a maioria das ferramentas de monitoramento.

O trecho abaixo define o grafo de orquestração completo: estado compartilhado, orquestrador que seleciona os agentes especialistas, roteamento condicional entre eles e checkpoints para recuperação:

from typing import TypedDict, Optional, List, Dict, Any
from langgraph.graph import END, StateGraph
from langgraph_checkpoint_aws import AgentCoreMemorySaver

class AgentState(TypedDict):
    query_text: str
    session_id: Optional[str]
    agent_task_map: Optional[Dict[str, str]]
    required_agents: Optional[List[str]]
    current_agent_index: Optional[int]
    # Each specialist writes its insights here
    security_monitor_insights: Optional[Dict[str, Any]]
    broker_monitor_insights: Optional[Dict[str, Any]]
    risk_monitor_insights: Optional[Dict[str, Any]]
    intel_analyst_insights: Optional[Dict[str, Any]]
    synthesizer_insights: Optional[str]

SPECIALIST_NODES = {
    "security_monitor": security_monitor_node,
    "broker_monitor": broker_monitor_node,
    "risk_monitor": risk_monitor_node,
    "intel_analyst": intel_analyst_node,
}

def route_analysts(state: AgentState) -> str:
    """Dynamic routing --- walk the required_agents list by index."""
    required = state.get("required_agents", [])
    index = state.get("current_agent_index", 0)
    if not required:
        return END
    if index < len(required):
        return required[index]
    return "synthesizer"

# Build the graph
workflow = StateGraph(AgentState)
workflow.add_node("orchestrator", orchestrator_node)
for name, node_fn in SPECIALIST_NODES.items():
    workflow.add_node(name, node_fn)
workflow.add_node("synthesizer", synthesizer_node)
workflow.set_entry_point("orchestrator")

# Conditional edges --- the orchestrator and every specialist route through
# route_analysts, which can hand off to any specialist or the synthesizer.
ALL_TARGETS = {name: name for name in SPECIALIST_NODES} | {
    "synthesizer": "synthesizer",
    END: END,
}
workflow.add_conditional_edges("orchestrator", route_analysts, ALL_TARGETS)
for name in SPECIALIST_NODES:
    workflow.add_conditional_edges(name, route_analysts, ALL_TARGETS)
workflow.add_edge("synthesizer", END)

# AgentCoreMemorySaver checkpoints the state after every node
checkpointer = AgentCoreMemorySaver(MEMORY_ID, region_name=REGION)
graph = workflow.compile(checkpointer=checkpointer)

Por que usar os dois frameworks juntos

Muitos processos corporativos precisam de fluxos rígidos e previsíveis. Depender exclusivamente do raciocínio não determinístico de um LLM para executar cada passo é um risco real. Ao mesmo tempo, etapas específicas dentro desses fluxos exigem a inteligência e a flexibilidade que só um LLM oferece. A combinação de LangGraph e Strands resolve exatamente essa tensão.

• Raciocínio localizado: o LangGraph define a orquestração de alto nível. Os agentes Strands ficam posicionados nos nós onde o fluxo realmente precisa de análise via LLM — o raciocínio autônomo é aplicado apenas onde é estritamente necessário.
• Contexto isolado por agente: agentes monolíticos perdem facilmente o fio das instruções. Ao posicionar um agente Strands em cada nó separado, a memória fica compartimentalizada. Cada agente gerencia seu próprio contexto, enquanto o LangGraph mantém o estado de sessão estruturado acessível a todos.
• Ecossistema completo: embutir o Strands no LangGraph conecta ao grafo as integrações nativas com o Protocolo de Contexto de Modelo (MCP), controles de direção, guardrails de segurança e avaliação — tudo junto com o roteamento robusto do LangGraph.

Na prática, cada especialista é um nó do LangGraph. O nó instancia um agente Strands com seu próprio prompt de sistema, ferramentas e contexto isolado, executa a tarefa atribuída pelo orquestrador e retorna uma atualização parcial de estado. O LangGraph mescla essa atualização no estado compartilhado que os outros nós leem. Veja o nó do monitor de segurança:

async def security_monitor_node(state: AgentState) -> AgentState:
    """
    Single-day activity analyst agent that assesses price, volume and tick-level trades
    """
    agent = Agent(
        name="security_monitor",
        model=analyst_model,
        system_prompt=SECURITY_MONITOR_PROMPT,
        tools=[get_report_list, get_report_schema, run_report],
        callback_handler=None,
    )

    # Pull this node's task from the shared state the orchestrator populated.
    task = state.get("agent_task_map", {}).get("security_monitor", state["query_text"])

    # Strands runs its own reasoning + tool loop; collect the agent's final text.
    chunks = []
    async for event in agent.stream_async(task):
        if "data" in event:
            chunks.append(event["data"])
    result = "".join(chunks)

    # Return shared state updates
    return {
        "security_monitor_insights": {"task": task, "business_insights": result},
        "current_agent_index": state.get("current_agent_index", 0) + 1,
    }

Implantação e infraestrutura com o AgentCore

O Amazon Bedrock AgentCore oferece um serviço totalmente gerenciado para implantar e operar agentes em escala, eliminando a complexidade de gerenciar infraestrutura enquanto entrega capacidades de nível de produção.

Runtime gerenciado

O AgentCore Runtime transforma código local de agentes em implantações nativas de nuvem com configuração mínima. O serviço é agnóstico de framework, funciona nativamente com LangGraph e Strands, e cuida do trabalho pesado de orquestração de contêineres, escalabilidade automática e gerenciamento de sessões. Veja como implantar o orquestrador usando o SDK Python do AgentCore:

# api.py --- AgentCore runtime entry point
from bedrock_agentcore.runtime import BedrockAgentCoreApp
from src.agents import Workflow

app = BedrockAgentCoreApp()
workflow = Workflow()

@app.entrypoint
async def market_surveillance_workflow(payload):
    """Invoked by AgentCore for each request. Yields streaming chunks."""
    prompt = payload.get("prompt")
    session_id = payload.get("session_id", "default-session")
    actor_id = payload.get("actor_id", "default-actor")

    async for chunk in workflow.stream_query(
        session_id=session_id,
        prompt=prompt,
        actor_id=actor_id
    ):
        yield chunk

if __name__ == "__main__":
    app.run()

# Deploy with the AgentCore starter toolkit
from bedrock_agentcore_starter_toolkit import Runtime

runtime = Runtime()
runtime.configure(
    entrypoint="api.py",
    auto_create_execution_role=True,
    auto_create_ecr=True,
    requirements_file="requirements.txt",
    region="us-east-1",
    agent_name="market_surveillance_workflow",
)
result = runtime.launch()
print(f"Agent ARN: {result.agent_arn}")

# Invoke the deployed agent
import boto3, json

client = boto3.client("bedrock-agentcore", region_name="us-east-1")
response = client.invoke_agent_runtime(
    agentRuntimeArn=result.agent_arn,
    qualifier="DEFAULT",
    payload=json.dumps({
        "prompt": "What caused the AAPL price spike at 11:00 AM on March 15, 2024?",
        "session_id": "session-001",
        "actor_id": "analyst-jane",
    }),
)

# AgentCore returns a server-sent-events stream. Parse it:
for raw in response["response"].iter_lines():
    if not raw:
        continue
    line = raw.decode("utf-8") if isinstance(raw, bytes) else raw
    if not line.startswith("data: "):
        continue
    try:
        chunk = json.loads(line[6:])
        if isinstance(chunk, str) and chunk.startswith("data: "):
            chunk = json.loads(chunk[6:])
    except json.JSONDecodeError:
        continue  # malformed chunk --- skip, don't crash
    if isinstance(chunk, dict) and chunk.get("type") == "text":
        print(chunk["content"], end="")

Memória de curto e longo prazo

O LangGraph se integra com a memória do AgentCore via pacote langgraph-checkpoint-aws. A classe AgentCoreMemorySaver gerencia checkpoints contendo mensagens do usuário, respostas da IA, estado de execução do grafo e metadados — tudo salvo automaticamente após cada nó, sem necessidade de gerenciar tabelas do Amazon DynamoDB ou lógica de serialização customizada.

Já a classe AgentCoreMemoryStore oferece memória inteligente de longo prazo: o AgentCore extrai automaticamente insights, resumos e preferências das conversas, e os agentes podem consultar essas memórias em interações futuras. Isso resolve o problema fundamental da ausência de estado — cada nova interação se baseia no conhecimento acumulado, em vez de começar do zero.

import boto3, time

REGION = "us-east-1"
control_client = boto3.client("bedrock-agentcore-control", region_name=REGION)

response = control_client.create_memory(
    name="MarketSurveillanceMemory",
    description="Memory for market surveillance multi-agent workflow.",
    eventExpiryDuration=90,  # days
)
MEMORY_ID = response["memory"]["id"]
print(f"Memory ID: {MEMORY_ID}")

# Wait for ACTIVE, with a 10-minute deadline. Creation normally takes 1-3 min.
deadline = time.time() + 600
while True:
    status = control_client.get_memory(memoryId=MEMORY_ID)["memory"]["status"]
    if status == "ACTIVE":
        break
    if status == "FAILED" or time.time() >= deadline:
        raise RuntimeError(f"Memory {MEMORY_ID} is {status!r} (expected ACTIVE)")
    time.sleep(10)

# On graph build:
checkpointer = AgentCoreMemorySaver(MEMORY_ID, region_name=REGION)
graph = workflow.compile(checkpointer=checkpointer)

# On invocation, pass thread_id and actor_id to the agent.
# These are unique identifiers for the user and session:
config = {
    "configurable": {
        "thread_id": "surveillance-session-001",
        "actor_id": "analyst-jane",
    }
}
response = await graph.ainvoke(
    {"query_text": "Which brokers were most active?"},
    config=config,
)

Observabilidade integrada

O AgentCore inclui observabilidade nativa via Amazon CloudWatch e AWS X-Ray, capturando traces de execução dos agentes, invocações de ferramentas e métricas de desempenho. Combinado com os eventos OpenTelemetry do LangGraph, é possível ter visibilidade completa — desde a orquestração macro do fluxo até chamadas individuais de LLM e etapas de raciocínio.

Conclusão

A arquitetura apresentada pela AWS combina a orquestração determinística do LangGraph com o raciocínio inteligente do Strands, implantados no AgentCore. O LangGraph cuida da coordenação de agentes, persistência de estado e recuperação de fluxo. O Strands fornece o motor de análise dentro de cada nó. Essa separação de responsabilidades permite construir sistemas sofisticados que lidam com processos corporativos complexos mantendo confiabilidade em produção.

O padrão pode ser estendido para outros cenários — pipelines de processamento de documentos, automação de atendimento ao cliente ou monitoramento de conformidade. A natureza agnóstica de modelo do Strands combinada com o gerenciamento de estado do LangGraph torna essa arquitetura especialmente valiosa para aplicações que exigem tanto flexibilidade quanto previsibilidade. Para explorar os detalhes técnicos e construir um agente de análise de mercado, acesse o repositório no GitHub.

Fonte

Market surveillance agent with LangGraph and Strands on AgentCore (https://aws.amazon.com/blogs/machine-learning/market-surveillance-agent-with-langgraph-and-strands-on-agentcore/)

A maior revisão do MCP desde o lançamento

O Protocolo de Contexto de Modelo (MCP, na sigla em inglês) publicou sua especificação 2026-07-28 — a revisão mais abrangente e significativa desde o lançamento do protocolo. Com essa versão, o MCP passa a ser um protocolo sem estado (stateless), capaz de escalar em infraestruturas HTTP convencionais. Além da mudança no transporte, a nova versão introduz um sistema de extensões com governança formal, reforça a autorização com alinhamento mais próximo às práticas corporativas de OAuth 2.0 e OpenID Connect (OIDC), e estabelece garantias de ciclo de vida que reduzem rupturas futuras.

Para quem já utiliza o AgentCore Gateway, funcionalidade do Amazon Bedrock AgentCore, a adoção da nova versão é uma simples mudança de configuração via chamada UpdateGateway. Clientes existentes continuam funcionando exatamente como antes — não há nenhuma etapa por alvo. Se você já conhece as mudanças da especificação, pode ir direto para a seção Atualizando seu AgentCore Gateway.

O que muda com a nova especificação e por que isso importa

Esta versão contém mudanças incompatíveis com versões anteriores do protocolo MCP. A transição para o modelo sem estado é uma mudança estrutural que os mantenedores do protocolo consideram necessária para resolver desafios de escala em implantações corporativas. No entanto, a introdução de mudanças que quebram compatibilidade com novas versões não deve ser a norma daqui em diante. Para facilitar atualizações compatíveis com versões anteriores em revisões futuras, os mantenedores introduziram melhorias de governança na especificação: uma política de ciclo de vida de funcionalidades, um framework de extensões e um requisito de suíte de conformidade.

A atualização é opcional. Nada muda até que você e seus clientes ajam. O AgentCore Gateway anuncia as versões do protocolo que suporta por meio de um único campo de configuração. Clientes selecionam uma versão em cada requisição. Adicionar a versão 2026-07-28 a um gateway que também anuncia 2025-11-25 não altera nada para clientes que solicitam a versão mais antiga. Apenas um cliente que requisitar 2026-07-28 receberá o novo comportamento.

1. MCP agora é sem estado (stateless)

Nas versões anteriores do protocolo, toda interação HTTP com fluxo contínuo (Streamable HTTP) com um servidor MCP começava com um handshake de inicialização, no qual cliente e servidor trocavam versões do protocolo e capacidades. O servidor então emitia um cabeçalho Mcp-Session-Id que todas as requisições subsequentes precisavam carregar. Isso vinculava o cliente ao servidor que emitiu o identificador de sessão, exigindo sessões persistentes no balanceador de carga ou um armazenamento de sessão compartilhado para escalar horizontalmente.

Ao remover as sessões, servidores MCP remotos passam a se comportar como endpoints HTTPS padrão, escalando de forma limpa em cargas de trabalho corporativas. Os documentos de proposta de evolução do protocolo SEP-2575 e SEP-2567 removem esses requisitos da nova versão do protocolo. Com a versão 2026-07-28, cada requisição passa a carregar versão do protocolo, informações do cliente e capacidades do cliente dentro do parâmetro _meta, eliminando a necessidade do handshake de inicialização. Clientes que precisam descobrir o que um servidor suporta podem chamar o novo método server/discover a qualquer momento.

O resultado prático é que uma única chamada de ferramenta é completamente autocontida — não requer nenhum contexto de sessão anterior e pode ser roteada para qualquer instância de servidor.

A remoção da sessão de protocolo não impede suporte a aplicações com estado. Quando servidores precisam de continuidade entre chamadas, é possível seguir padrões estabelecidos para requisições HTTP, passando um ID explícito como parâmetro de ferramenta. Veja o exemplo abaixo de como criar um carrinho e adicionar itens a ele:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_basket
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"create_basket","arguments":{},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

Response:
{"jsonrpc":"2.0","id":1,
 "result":{"resultType":"complete","content":[{"type":"text","text":"Created basket bsk_a1b2c3"}],"structuredContent":{"basket_id":"bsk_a1b2c3"},"isError": false}}

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: add_item
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"add_item","arguments":{"basket_id": "bsk_a1b2c3", "sku": "shoes"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

O AgentCore Gateway sempre protegeu os agentes da maior parte da mecânica de sessão do MCP. Com a versão 2026-07-28, isso fica mais simples em ambos os lados: a primeira chamada de ferramenta de um agente é uma requisição autocontida, em vez de um handshake seguido de uma chamada. Cada requisição carrega um cabeçalho Mcp-Protocol-Version. O gateway serve a requisição nessa versão quando ela estiver em supportedVersions, ou a rejeita com HTTP 400 (código -32022) e lista as versões suportadas quando não estiver.

2. Roteamento, cache e rastreamento sem precisar analisar o corpo da requisição

Nas versões anteriores, a operação executada por uma requisição era opaca para qualquer intermediário entre cliente e servidor. Balanceadores de carga, API gateways e limitadores de taxa precisavam analisar o corpo JSON-RPC para determinar qual método estava sendo chamado.

A versão 2026-07-28 resolve isso de três formas:

• Cabeçalhos de intenção: Toda requisição HTTP com fluxo contínuo agora expõe sua intenção em cabeçalhos padrão: Mcp-Method e Mcp-Name (SEP-2243) viajam fora do corpo, dando aos intermediários informações suficientes para rotear, limitar e monitorar apenas na camada HTTP.
• Metadados de frescor para cache: Respostas a operações de listagem e leitura de recursos agora incluem metadados explícitos de validade, ttlMs e cacheScope, inspirados na semântica do HTTP Cache-Control (SEP-2549). Clientes podem armazenar em cache uma resposta de tools/list por uma duração conhecida sem manter uma conexão persistente.
• Rastreamento distribuído formal: A especificação agora reserva as chaves de Contexto de Rastreamento W3C (traceparent, tracestate, baggage) dentro de _meta (SEP-414), formalizando o que vários SDKs já haviam adotado na prática. Um rastreamento distribuído originado em sua aplicação pode agora se propagar por toda a cadeia de chamadas e ser renderizado como uma árvore de spans unificada em qualquer coletor compatível com OpenTelemetry.

3. Interações servidor-para-cliente sem conexões persistentes

Um protocolo sem estado ainda precisa de uma forma para o servidor se comunicar de volta com o cliente durante uma chamada. O MCP tem três dessas interações: elicitação (o servidor pede input ao usuário final), roots (o servidor solicita diretórios e arquivos disponíveis no sistema de arquivos) e sampling (o servidor pede ao modelo do cliente para gerar uma resposta).

Nas versões anteriores, entregar essas requisições significava que o servidor mantinha um fluxo SSE (Server-Sent Events) aberto de volta para o cliente. Com a nova versão, requisições iniciadas pelo servidor só são permitidas enquanto o servidor está ativamente processando uma requisição do cliente (SEP-2260). Cada prompt que um usuário vê remonta a algo que ele ou seu agente iniciou.

As Requisições de Múltiplas Rodadas (SEP-2322) substituem o fluxo de longa duração anterior. O servidor embute perguntas em um InputRequiredResult e externaliza o estado por meio de um token opaco requestState, em vez de enviar uma pergunta via SSE. Veja o exemplo:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Delete 3 files?",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "confirm": {
              "type": "boolean"
            },
            "required": ["confirm"]
          }
        }
      }
    },
    "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
  }
}

Os clientes coletam as respostas do usuário e reemitem a chamada original com as respostas e o requestState. Tudo que o servidor precisa está no payload, então qualquer instância de servidor pode retomar a operação.

4. Desacoplando extensões da especificação principal

Até agora, extensões do MCP eram um conceito informal sem governança. O documento SEP-2133 introduz um sistema formal. Cada extensão carrega um ID em formato DNS reverso, é negociada por meio de um mapa de extensões nas capacidades de cliente e servidor, vive em um repositório dedicado com mantenedores delegados e segue seu próprio ciclo de lançamento independente da especificação principal.

Uma nova Trilha de Extensões dentro do processo SEP define como uma extensão avança de experimental para status oficial. Em vez de cada nova ideia competir por espaço na especificação principal e forçar uma versão com quebra de compatibilidade, capacidades agora podem amadurecer como extensões opcionais em seus próprios cronogramas.

5. Endurecimento da autorização

Seis SEPs alinham a especificação de autorização do MCP com implantações de produção de OAuth 2.0 e OpenID Connect (OIDC). A autorização de entrada do gateway — seja IAM (SigV4) ou OAuth/JWT — não é alterada pela versão do protocolo. O mesmo vale para os provedores de credenciais de saída. Atualizar a versão do protocolo não requer alteração de credenciais ou configuração de autorizador.

6. Tratamento de erros e depreciações

Nas versões anteriores do protocolo, quase tudo retornava como HTTP 200 com um erro dentro do corpo JSON-RPC, incluindo falhas de transporte. Com a versão 2026-07-28, as camadas de transporte e aplicação são separadas de forma limpa. Falhas de transporte retornam códigos de status HTTP reais. Resultados no nível de aplicação permanecem no corpo:

• Método desconhecido: Versões 2025-* retornam erro JSON-RPC no corpo com HTTP 200; versão 2026-07-28 retorna HTTP 404.
• Versão de protocolo não suportada: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32022, com lista de versões suportadas no corpo.
• Campo vinculado a cabeçalho ausente ou inconsistente: Versões 2025-* variam; versão 2026-07-28 retorna HTTP 400, código -32020.
• Capacidade de cliente obrigatória ausente: Não aplicável nas versões 2025-*; versão 2026-07-28 retorna código -32021.

A especificação também reatribui o código de erro “recurso não encontrado” do MCP-específico -32002 para o padrão JSON-RPC -32602 Invalid Params (SEP-2164). Se seu cliente corresponder ao código -32002 em algum lugar, audite esses caminhos de código.

Além disso, na versão 2026-07-28: logging/setLevel é descontinuado, e um cliente que o chama é rejeitado. Para optar pela entrega de logs, defina o campo de metadados por requisição io.modelcontextprotocol/logLevel.

Três funcionalidades principais são depreciadas sob a nova política de ciclo de vida de funcionalidades do protocolo (SEP-2577):

• Roots — substituído por parâmetros de ferramenta, URIs de recurso ou configuração de servidor
• Sampling — substituído por integração direta com APIs de provedores de LLM
• Logging — substituído por stderr para transportes stdio e OpenTelemetry para observabilidade estruturada

Essas depreciações são consultivas. Os métodos, tipos e flags de capacidade permanecem funcionais nesta versão e em qualquer versão da especificação publicada dentro de doze meses a partir dela. No entanto, novas implementações não devem depender dessas funcionalidades.

7. Suporte a esquemas JSON Schema 2020-12

Os campos inputSchema e outputSchema de ferramentas agora suportam o vocabulário completo do JSON Schema 2020-12 (SEP-2106). Esquemas de entrada mantêm o requisito de raiz type: "object", mas ganham palavras-chave de composição (oneOf, anyOf, allOf), condicionais e referências internas ($ref, $defs). Esquemas de saída não têm restrição de tipo raiz, e structuredContent pode ser qualquer valor JSON válido. Implementações não devem seguir URIs $ref externos automaticamente e devem impor limites de profundidade e tempo durante a validação.

Como decidir se você está pronto para atualizar

Antes de habilitar a nova versão, responda três perguntas:

• Seus clientes estão prontos? Seus agentes alcançam o Gateway por meio de SDKs de cliente MCP. Verifique se os SDKs que seus frameworks de agente e aplicações host usam já enviaram suporte para 2026-07-28. Os SDKs de Nível 1 (Tier 1) já deveriam ter enviado suporte durante a janela de dez semanas do candidato a lançamento. Consulte a documentação do MCP SDK para a lista atual de níveis.
• Algo que você executa depende de comportamento removido ou alterado? Audite: sessões de protocolo usadas para carregar estado de aplicação, logging/setLevel, código de cliente que corresponde ao código de erro literal -32002, e qualquer dependência de Roots, Sampling ou Logging.
• Você controla ambos os lados? Não é necessário. A seleção de versão acontece por requisição, então um gateway com duas versões serve clientes antigos e novos simultaneamente. Você pode atualizar clientes e o gateway em cronogramas independentes, em qualquer ordem.

Atualizando seu AgentCore Gateway

Para clientes do AgentCore Gateway, adotar a versão 2026-07-28 é uma mudança de configuração. Seu AgentCore Gateway pode suportar múltiplas versões do protocolo simultaneamente. Você pode adicionar 2026-07-28 à lista de supportedVersions do gateway com uma única chamada UpdateGateway. Não é necessário recriar o gateway ou fazer alterações nas configurações individuais de alvos do gateway.

O comando UpdateGateway substitui o supportedVersions pelo conjunto que você envia — ele não acrescenta. Leia a configuração atual primeiro, depois envie a lista completa que você deseja que o gateway anuncie:

# 1. Read the current configuration.
aws bedrock-agentcore-control get-gateway \
    --gateway-identifier <gateway-id>

# 2. Advertise 2026-07-28 alongside the existing version.
aws bedrock-agentcore-control update-gateway \
    --name <gateway-name> \
    --role-arn <gateway-role-arn> \
    --protocol-type MCP \
    --authorizer-type <gateway-authorizer-type> \
    --gateway-identifier <gateway-id> \
    --protocol-configuration '{
      "mcp": {
        "supportedVersions": ["2025-11-25", "2026-07-28"]
      }
    }'

O AgentCore Gateway funciona com qualquer uma das seguintes versões do protocolo: 2025-03-26, 2025-06-18, 2025-11-25 e 2026-07-28.

Confirme que a nova versão está ativa chamando seu gateway com os novos cabeçalhos:

curl -s https://<your-gateway-endpoint>/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json,text/event-stream" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/list" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Uma resposta bem-sucedida confirma que o gateway serviu a requisição na versão 2026-07-28. Uma rejeição com código -32022 significa que a versão ainda não está no supportedVersions do gateway, e o corpo da resposta lista o que o gateway atualmente anuncia.

Para reverter, basta enviar a lista sem 2026-07-28. Requisições especificando a versão removida serão rejeitadas com um corpo de resposta listando as versões que o gateway ainda suporta. Certifique-se de que os clientes que você já migrou possam fazer fallback antes de remover a versão que eles estão solicitando.

Como funciona a seleção de versão

Clientes selecionam uma versão em cada requisição, não por meio de um handshake único. Cada requisição MCP declara sua versão no cabeçalho MCP-Protocol-Version, e o gateway a honra quando está em supportedVersions:

• Uma requisição nomeando uma versão que o gateway anuncia é servida nessa versão.
• Em um gateway com duas versões (por exemplo, 2026-07-28 e 2025-11-25), uma requisição 2026-07-28 recebe o novo comportamento e uma requisição 2025-11-25 recebe o comportamento anterior.
• Uma requisição nomeando uma versão que o gateway não anuncia é rejeitada com HTTP 400 e código -32022. O corpo da resposta lista as versões que o gateway suporta.
• Uma requisição que omite o cabeçalho recebe a versão padrão, 2025-03-26. Se esse padrão não estiver no supportedVersions do gateway, a requisição é rejeitada.

Isso permite um rollout em três etapas: adicionar 2026-07-28 junto às versões existentes, migrar clientes no seu próprio ritmo e, somente após todos os clientes solicitarem a nova versão, reduzir a lista.

Se o seu gateway está na frente de um servidor MCP alvo que atualiza para 2026-07-28 antes dos seus clientes, ele traduz entre versões — um cliente 2025-* pode chamar ferramentas comuns em um alvo 2026-07-28 e receber resultados no formato esperado, sem precisar atualizar. No entanto, essa tradução não suporta atualmente chamadas de elicitação e sampling de servidores para clientes.

Conclusão

A versão MCP 2026-07-28 é a maior revisão do protocolo já feita, e foi projetada para ser a última revisão que quebra compatibilidade. O modelo sem estado dá ao MCP uma base que escala em infraestrutura HTTP comum, enquanto as Extensões MCP dão espaço para novas capacidades evoluírem em seus próprios cronogramas.

Com o Amazon Bedrock AgentCore Gateway, adicionar suporte à versão mais recente do protocolo é apenas uma chamada UpdateGateway. Para começar, consulte a documentação do AgentCore Gateway, revise a especificação MCP 2026-07-28 e seu changelog, e tente habilitar a nova versão em um gateway hoje. Para detalhes completos, veja também o changelog em relação à versão 2025-11-25 e o anúncio do candidato a lançamento no blog do MCP. Se você tiver feedback sobre a especificação, os mantenedores aceitam issues no repositório da especificação MCP. Para dúvidas sobre o AgentCore Gateway, entre em contato pelo AWS re:Post ou pelos canais habituais de suporte da AWS.

Fonte

How AgentCore Gateway supports the MCP 2026-07-28 spec (https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/)

O que mudou

A AWS anunciou que o modo Enhanced do AWS DataSync agora oferece suporte ao Amazon EFS (Elastic File System) e ao Amazon FSx for Lustre como locais de origem ou destino nas transferências de dados.

Contexto: o que é o AWS DataSync

O AWS DataSync é um serviço seguro de transferência de dados em alta velocidade, projetado para simplificar a movimentação de dados pela rede. Ele já era amplamente utilizado para migrações e sincronizações entre diferentes sistemas de armazenamento da AWS.

A diferença entre o modo Basic e o modo Enhanced

Até agora, quem precisava mover dados de ou para o Amazon EFS e o Amazon FSx for Lustre estava limitado ao modo Basic do DataSync. Com a novidade, esses mesmos clientes podem migrar para o modo Enhanced, que traz vantagens importantes:

• Processamento de dados em paralelo, aumentando a velocidade das transferências
• Remoção das limitações de contagem de arquivos
• Fornecimento de métricas detalhadas sobre as transferências realizadas

Casos de uso beneficiados

A expansão do modo Enhanced para o EFS e o FSx for Lustre abre caminho para simplificar fluxos de trabalho em cenários de grande escala, como:

• Migrações de grande volume de dados
• Treinamento de modelos de IA agêntica e aprendizado de máquina
• Computação de alto desempenho (HPC)
• Processamento de dados genômicos
• Renderização de mídia

Disponibilidade

O recurso já está disponível em todas as Regiões AWS onde o AWS DataSync é oferecido. Para começar a usar, acesse o console do AWS DataSync. Para mais detalhes técnicos, consulte a documentação oficial do AWS DataSync.

Fonte

AWS DataSync Enhanced mode now supports Amazon EFS and Amazon FSx for Lustre (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-datasync-amazon-efs-fsx-lustre/)

O que foi anunciado

A AWS adicionou uma nova capacidade ao AWS Glue Data Quality: o suporte a estatísticas de distribuição para perfilamento de dados. O recurso chega por meio de um componente chamado Distribution Analyzer, que permite gerar perfis de frequência sobre os dados armazenados nos seus pipelines — sem a necessidade de escrever código personalizado para isso.

Como funciona o Distribution Analyzer

O Distribution Analyzer é utilizado dentro da Linguagem de Definição de Qualidade de Dados (DQDL — Data Quality Definition Language), já existente no Glue Data Quality. Por meio dele, é possível gerar dois tipos de saída dependendo do tipo da coluna:

• Histogramas para colunas numéricas
• Distribuições de valores para colunas categóricas, de data e booleanas

O recurso também suporta contagens de intervalos personalizadas (custom bin counts), o que permite explorar a forma e os padrões dos dados no nível de granularidade mais relevante para cada caso de uso.

Por que isso importa para quem trabalha com dados

Entender como os dados estão distribuídos é uma etapa fundamental para construir pipelines confiáveis. Com as estatísticas de distribuição, equipes de dados conseguem identificar rapidamente assimetrias (skewness), outliers e padrões inesperados nos datasets — tudo isso sem precisar desenvolver lógica customizada para cada análise.

Outro ponto relevante é a integração nativa: o Distribution Analyzer se encaixa diretamente nos rulesets DQDL já existentes. Ou seja, é possível adicionar o perfilamento de distribuição junto com as verificações de qualidade de dados atuais, tudo em uma única execução de avaliação.

Onde os resultados ficam armazenados

As estatísticas de distribuição geradas são armazenadas no Amazon S3, o que facilita consultas futuras por meio de serviços como o Amazon Athena. Além disso, os dados também ficam acessíveis via APIs, permitindo integração com workflows de monitoramento e ferramentas de visualização, incluindo o SageMaker Unified Studio.

Disponibilidade

O recurso de estatísticas de distribuição do AWS Glue Data Quality já está disponível em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US).

Para saber mais sobre o Glue Data Quality, consulte a documentação oficial do AWS Glue Data Quality. Para começar a usar o Distribution Analyzer, acesse a documentação de Analyzers.

Fonte

AWS Glue Data Quality now supports distribution statistics for data profiling (https://aws.amazon.com/about-aws/whats-new/2026/07/aws-glue-data-quality-distribution-profiling)

O limite do RAG em tarefas analíticas complexas

Se você já usou Geração Aumentada por Recuperação (RAG) para analisar centenas de documentos ao mesmo tempo — como em processos de due diligence financeira ou revisões de conformidade regulatória — provavelmente já esbarrou nas suas limitações. A busca por similaridade consegue recuperar fragmentos relevantes, mas frequentemente perde as conexões que existem entre documentos diferentes.

Para ilustrar o problema, imagine uma firma de private equity avaliando uma aquisição de R$ 500 milhões. A equipe de due diligence precisa analisar demonstrações financeiras de 12 subsidiárias ao longo de 5 anos, mais de 200 contratos com fornecedores, relatórios de conformidade ambiental de 8 instalações e mais de 50 casos jurídicos. Quando um analista pergunta sobre os riscos financeiros consolidados considerando os termos atuais com fornecedores e os litígios pendentes, a busca por similaridade do RAG simplesmente não consegue montar essa resposta — as informações relevantes estão espalhadas por centenas de documentos sem nenhuma similaridade lexical entre elas.

É exatamente esse tipo de problema que a técnica TAKC (Task-Aware Knowledge Compression — Compressão de Conhecimento Orientada a Tarefas) se propõe a resolver.

O que é TAKC e como funciona

A ideia central do TAKC é usar um LLM (Modelo de Linguagem de Grande Escala) para produzir resumos mais curtos e focados em tarefas específicas — com resumos diferentes para tarefas diferentes. O ponto-chave é que documentos diferentes exigem informações diferentes dependendo do contexto de uso.

Um relatório anual comprimido para análise financeira precisa preservar receitas, margens e dados de fluxo de caixa. O mesmo relatório comprimido para uma revisão de conformidade precisa reter citações regulatórias e históricos de violações. Uma sumarização genérica tenta cobrir tudo e acaba diluindo a densidade de informação para qualquer caso de uso específico.

O TAKC comprime os documentos pela lente de uma tarefa específica: mantém o que importa e descarta o resto. Essa compressão acontece offline, uma vez por documento por tipo de tarefa. No momento da consulta, o sistema recupera a representação já comprimida em vez do documento original e responde com base nessa versão. Se a representação comprimida não tiver detalhes suficientes, um analisador de complexidade de consulta redireciona a pergunta para um nível de compressão menor, que retém mais contexto.

Diferente do RAG, o TAKC dá acesso a toda a base de conhecimento em forma comprimida — não apenas aos top-k fragmentos retornados por uma busca por similaridade. Isso preserva as conexões entre documentos, porque a compressão processa os documentos de forma integrada. A redução de tokens varia de 8x a 64x, sempre priorizando as informações relevantes para a tarefa.

Compressão em múltiplos níveis

Nem toda consulta exige o mesmo nível de detalhe. Uma pergunta como “Qual foi a receita do terceiro trimestre?” precisa de muito menos contexto do que um pedido para analisar as relações entre prazos de pagamento a fornecedores e o fluxo de caixa trimestral entre subsidiárias.

O TAKC resolve isso mantendo quatro níveis de compressão para cada tipo de tarefa:

• Leve (8x): reduz aproximadamente 87,5% do contexto. Preserva detalhes suficientes para raciocínio em múltiplas etapas e síntese entre documentos.
• Médio (16x): redução de aproximadamente 93,8%. Adequado para consultas analíticas de complexidade moderada.
• Alto (32x): redução de aproximadamente 96,9%. Atende buscas factuais e perguntas bem definidas.
• Ultra (64x): redução de aproximadamente 98,4%. Indicado para tarefas de classificação e buscas por palavras-chave.

Um analisador de complexidade de consulta roteia automaticamente cada pergunta para o nível adequado, com base em sinais como o comprimento da consulta, o tipo de pergunta e a presença de linguagem analítica. Perguntas factuais simples chegam ao cache mais comprimido; consultas analíticas complexas usam o cache menos comprimido. Tudo isso acontece de forma transparente para o usuário.

Na prática, a maioria das consultas empresariais são buscas simples que podem ser atendidas pelos níveis de maior compressão com custo mínimo. As consultas complexas, menos frequentes, consomem orçamentos maiores de contexto apenas quando necessário.

Arquitetura na AWS

A implementação roda na AWS como dois pipelines serverless desacoplados: um para ingestão e outro para consultas.

O AWS Lambda foi escolhido para computação porque cada invocação é de curta duração e orientada a eventos. O Amazon API Gateway expõe a interface de consulta como um endpoint REST. O Amazon ElastiCache Serverless cuida do cache com leituras em chaves compostas (takc:{task}:{rate}) sem necessidade de gerenciamento de shards. O Amazon Cognito gerencia emissão e renovação de tokens JWT sem código de autenticação customizado.

Pipeline de ingestão

Quando um documento chega ao Amazon S3 sob um prefixo de tipo de tarefa (por exemplo, raw-data/financial/), uma notificação de evento S3 aciona uma função AWS Lambda. Essa função divide o documento em segmentos de 256 tokens com sobreposição de 50 tokens para evitar perda de informação nas bordas. Em seguida, invoca de forma assíncrona uma função Lambda de compressão para cada segmento, permitindo processamento paralelo.

A segunda função chama o Amazon Bedrock para comprimir os segmentos nos quatro níveis de compressão. Cada chamada de compressão inclui um prompt orientado à tarefa que instrui o modelo sobre quais informações preservar. Veja um exemplo de prompt para análise financeira:

TASK: Financial analysis. Preserve revenue metrics, margins, cash flow, debt obligations, and financial risk indicators.
COMPRESSION TARGET: Reduce to approximately 1/16 of original length.
INSTRUCTIONS:
- Focus on facts and relationships relevant to the task
- Preserve numerical data and metrics
- Maintain entities and their attributes
- Keep causal relationships and dependencies
- Remove redundant or irrelevant information

O modelo sabe o que preservar porque o prompt especifica exatamente o que importa para aquela tarefa — é isso que torna a abordagem orientada à tarefa, em vez de uma compressão genérica.

As saídas comprimidas são armazenadas no Amazon ElastiCache Serverless com chaves como takc:financial:medium e têm backup no S3 para durabilidade. As entradas de cache usam TTL de 24 horas. Se uma entrada for removida ou expirar, a função de consulta recorre ao backup no S3 e repovoа o cache na leitura.

Pipeline de consulta

O usuário se autentica pelo Amazon Cognito, recebe um JWT (JSON Web Token) e envia a consulta pelo Amazon API Gateway. O AWS WAF (Firewall de Aplicação Web) fica na frente da API para limitação de taxa e proteção contra ameaças. Uma função Lambda analisa a complexidade da consulta por heurísticas, recupera o cache comprimido adequado do ElastiCache e envia o contexto comprimido junto com a consulta ao Amazon Bedrock para inferência.

As chamadas de compressão ao Bedrock — que são mais custosas — acontecem apenas uma vez durante a ingestão. O caminho de consulta é apenas uma busca no cache mais a inferência sobre o contexto comprimido.

Stack completo de serviços

O stack utiliza o Amazon Bedrock (Anthropic Claude 3 Haiku, Claude 3 Sonnet e Amazon Titan Text) para compressão e inferência. A seleção de modelo é configurável via valores de contexto do CDK sem alterações de código. O AWS Lambda (Python 3.12+) trata o processamento de dados e a lógica de consulta. O Amazon ElastiCache Serverless armazena o cache comprimido, enquanto o Amazon S3 guarda dados brutos, segmentos e backups do cache (criptografados com KMS). O Amazon API Gateway expõe os endpoints REST, e o Amazon Cognito fornece autenticação baseada em JWT. O AWS WAF protege a API com limitação de taxa e regras de segurança gerenciadas. O Amazon CloudWatch oferece monitoramento e métricas, e o AWS Key Management Service (AWS KMS) gerencia as chaves de criptografia.

Toda a infraestrutura é definida como um único stack do AWS Cloud Development Kit (AWS CDK) e implantada com um único comando.

Comparativo de custos

A tabela abaixo mostra o consumo de tokens de entrada para uma base de conhecimento de 100.000 tokens consultada 1.000 vezes por dia (tokens de saída são excluídos porque o tamanho da resposta é independente do tamanho do contexto):

• Contexto completo: 100.000 tokens por consulta → 100.000.000 tokens/dia → 100% do custo
• RAG (top-10 fragmentos): ~10.000 tokens → 10.000.000/dia → 10%
• TAKC Leve (8x): ~12.500 tokens → 12.500.000/dia → 12,5%
• TAKC Médio (16x): ~6.250 tokens → 6.250.000/dia → 6,25%
• TAKC Alto (32x): ~3.125 tokens → 3.125.000/dia → 3,1%
• TAKC Ultra (64x): ~1.563 tokens → 1.563.000/dia → 1,6%

O TAKC exige um custo inicial de compressão — chamadas únicas ao Bedrock durante a ingestão. Esse custo se amortiza em bases de conhecimento que mudam com pouca frequência e são consultadas repetidamente. Para bases de conhecimento que mudam a cada hora, o modelo de recuperação por consulta do RAG pode ser mais prático.

Quando escolher TAKC, RAG ou ambos

Cada abordagem tem seu cenário ideal:

• TAKC é mais indicado quando: as consultas exigem raciocínio entre documentos e síntese; a base de conhecimento muda diariamente ou menos; os tipos de tarefa são bem definidos; é necessário considerar o corpus completo; e a rastreabilidade da fonte não é obrigatória.
• RAG é mais indicado quando: as consultas são buscas factuais pontuais; a base de conhecimento muda a cada hora ou mais; os padrões de consulta são imprevisíveis; apenas alguns documentos são relevantes; e o usuário precisa rastrear a resposta até o documento-fonte.

Na prática, sistemas em produção frequentemente se beneficiam das duas abordagens. O RAG trata buscas rápidas com eficiência. O TAKC trata consultas analíticas onde abordagens baseadas em recuperação perdem conexões importantes. Um analisador de complexidade de consulta pode rotear entre eles. Para cargas de trabalho reguladas que exigem tanto raciocínio entre documentos quanto auditabilidade, é possível combinar TAKC para a resposta analítica e RAG para recuperar os documentos-fonte de suporte na trilha de auditoria.

Como implantar a implementação de referência

Para implantar a implementação de referência, são necessários: uma conta AWS com acesso a modelos do Amazon Bedrock, a CLI do AWS CDK, Python 3.12 ou superior e Node.js 18 ou superior.

Clone o repositório aws-samples/sample-bedrock-takc-compression e implante o stack CDK:

git clone https://github.com/aws-samples/sample-bedrock-takc-compression
cd sample-bedrock-takc-compression/cdk
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cdk deploy

Após a implantação, faça o upload de um documento para o bucket S3:

aws s3 cp your-document.pdf s3://$(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`DataBucketName`].OutputValue' \
  --output text)/raw-data/financial/

Aguarde 2 a 3 minutos para que o pipeline de ingestão segmente e comprima o documento nos quatro níveis. Em seguida, consulte o endpoint da API:

curl -X POST $(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`ApiEndpoint`].OutputValue' \
  --output text)/query \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question": "What are the key financial risks?"}'

O sistema cuida automaticamente da segmentação, compressão em múltiplos níveis, cache e roteamento de consultas sem configuração adicional.

Para evitar cobranças contínuas após os testes, esvazie o bucket S3 e destrua o stack CDK:

aws s3 rm s3://$(aws cloudformation describe-stacks --stack-name TakcStack \
  --query 'Stacks[0].Outputs[?OutputKey==`DataBucketName`].OutputValue' \
  --output text) --recursive

cd sample-bedrock-takc-compression/cdk
source .venv/bin/activate
cdk destroy

A chave KMS é retida com uma janela de exclusão pendente de 30 dias. Para agendar sua exclusão imediatamente:

aws kms schedule-key-deletion --key-id <key-id> --pending-window-in-days 7

Conclusão

Tarefas analíticas complexas que abrangem centenas de documentos exigem mais do que recuperação de fragmentos. O TAKC oferece uma abordagem construída para esse cenário: comprima a base de conhecimento completa offline pela lente de tarefas específicas, armazene essas representações em múltiplos níveis de fidelidade e direcione o nível de compressão adequado para a complexidade de cada consulta.

A implementação na AWS usa o Amazon Bedrock para compressão e inferência, o Amazon ElastiCache Serverless para cache e uma arquitetura totalmente serverless que escala conforme a demanda. O código de referência, a infraestrutura CDK e os scripts de implantação estão disponíveis em aws-samples/sample-bedrock-takc-compression.

Referências

• Documentação do Amazon Bedrock
• Documentação do Amazon ElastiCache Serverless
• Guia de engenharia de prompts do Amazon Bedrock

Fonte

Beyond RAG: Task-aware knowledge compression for enterprise AI on AWS (https://aws.amazon.com/blogs/machine-learning/beyond-rag-task-aware-knowledge-compression-for-enterprise-ai-on-aws/)