DEV Community: Jonathan Wong

Autonomous Tool Orchestration & Multi-Capability Agent Systems with Amazon Bedrock AgentCore & Strands SDK

Jonathan Wong — Tue, 10 Nov 2026 17:04:39 +0000

Part 4 of the series: “Engineering Next-Gen AI Agents: Reflections on the Future AWS Agent Engineer Nanodegree”

In Part 3, we explored prompt-driven intent routing and automated LLM-as-a-judge evaluations within a single managed harness. While single-prompt routing works well for targeted domain tasks, enterprise AI solutions demand multi-modal tool integration, cross-session long-term memory, secure code execution, and external platform connectivity.

In Project 2 of the Future AWS Agent Engineer Nanodegree , we built an end-to-end, autonomous AI Customer Support Agent deployed on Amazon Bedrock AgentCore Runtime. Built using a single Strands SDK Agent instance and the bedrock-agentcore-starter-toolkit, this agent acts as an intelligent, multi-tool orchestration hub for an e-commerce platform—integrating REST APIs, vector databases, persistent memory, and isolated code sandboxes into a unified conversational runtime.

The complete project source code and implementation files are available on my GitHub repository: https://github.com/jonanata/ai-support-agent

Below is an architectural breakdown of how these components integrate to solve real-world customer support challenges.

Architectural Blueprint & Component Synergies

Modern customer support requires far more than basic text generation. Our agent unifies five distinct AWS and Bedrock capabilities into a single conversational entry point:

How the Components Work Together:

AgentCore Gateway & Model Context Protocol (MCP): Exposes backend AWS Lambda functions (order tracking, refund processing) as standardized tools via REST endpoints managed by API Gateway. The agent discovers these tools dynamically at runtime using MCP docstrings and schema definitions.
Bedrock Knowledge Base (RAG): Connects to an S3 bucket storing unstructured catalog data (product_catalog.txt). The search_knowledge_base tool queries Bedrock’s vector search to retrieve grounded policy and warranty facts.
AgentCore Memory: Provides persistent, cross-session context. Using a custom MemoryHook, user facts and preferred communication styles are automatically prepended to incoming prompts and saved back to the memory store after each turn.
AgentCore Code Interpreter: Runs exact numerical math—such as points redemptions, tier calculations, and tiered discounts—inside an isolated, secure Python execution sandbox to avoid LLM arithmetic errors.
AgentCore Browser Tool: Grants the agent real-time web access to inspect external URLs when information isn’t available in internal databases.

Deep Dive: Implementation Highlights

The application entry point is built using the Strands SDK and registered with Bedrock AgentCore Runtime. For example, in the main.py:

from strands import Agent, tool
from bedrock_agentcore.runtime import BedrockAgentCoreApp

# 1. Register the application with Bedrock AgentCore Runtime
app = BedrockAgentCoreApp()

# 2. Define the asynchronous entry point decorated with @app.entrypoint
@app.entrypoint
async def invoke(payload, context=None):
    user_input = payload.get("prompt")

    # ... setup tools, hooks, and clients ...

    # 3. Instantiate the Strands SDK Agent
    agent = Agent(
        model=model,
        tools=tools,
        hooks=[hook],
        system_prompt="You are a helpful Amazon customer support AI."
    )  

    # 4. Invoke the agent and return the response
    response = agent(user_input)  
    return response

Model Context Protocol (MCP) Tool Loading

Instead of manually mapping API calls, the agent connects directly to the AgentCore Gateway URL over MCP to discover available tools:

GATEWAY_URL = "https://<alias>.gateway.bedrock-agentcore.us-east-1.amazonaws.com/mcp"  
client = MCPClient(lambda: streamable_http_client(url=GATEWAY_URL))  
with client:  
    gateway_tools = client.list_tools_sync()  
    tools.extend(gateway_tools)

Cross-Session Memory Hook

To maintain continuity without cluttering prompt state, we subclassed HookProvider to intercept conversation events:

MessageAddedEvent: Retrieves facts from namespaces (e.g., cs_agent/{actorId}/facts) and prepends Customer Context: to the prompt before invocation.
AfterInvocationEvent: Writes completed conversation pairs back to AgentCore Memory asynchronously.

class MemoryHook(HookProvider):
    def retrieve_customer_context(self, event: MessageAddedEvent):
        # Fetches semantic facts & preferences from AgentCore Memory
        # Prepends memories directly into the user message frame
        ...
    def save_support_interaction(self, event: AfterInvocationEvent):
        # Commits (USER, ASSISTANT) message pairs to memory after turn completion
        ...

Exact Calculations with Code Interpreter

For complex tier structures, relying on LLM text generation risks rounding errors. The calculate_loyalty_discount tool executes pure Python arithmetic within code_session(REGION):

@tool
def calculate_loyalty_discount(loyalty_points: int, tier: str, order_total: float, product_category: str = "standard") -> str:
    code = f"""
import json
earn_rates = {{"standard": 1, "device": 2, "fresh": 5}}
tier_rates = {{"Silver": 0.00, "Gold": 0.10, "Platinum": 0.15}}
# Performs exact point conversion, tier discounting, and remaining point totals...
print(json.dumps(result))
"""
    with code_session(REGION) as code_client:
        response = code_client.invoke("executeCode", {"code": code, "language": "python", "clearContext": True})
        for event in response["stream"]:
            return json.dumps(event["result"])

Setup Guide: Configuring the AWS Components

Before deploying the agentic runtime, you must configure and tie together the underlying AWS resources, including the API Gateway, Lambda functions, Bedrock Knowledge Base, and AgentCore Memory.

AgentCore Gateway & Model Context Protocol (MCP)

How Real-Time Dynamic Tool Discovery Works

Instead of hardcoding backend API routing or manually maintaining tool definitions in code, the AI agent relies on Model Context Protocol (MCP) capabilities built directly into the AgentCore Gateway.

When the Strands SDK Agent starts up, it connects to the GATEWAY_URL endpoint over MCP and performs a standard tools/list handshake:

Dynamic Schema Discovery: AgentCore Gateway queries its registered targets (both API Gateway REST stages and standalone Lambda functions).
Docstring & Operation Mapping: For API Gateway routes, the Gateway inspects the configured OpenAPI operation names (get_order, get_customer_orders, get_customer). For standalone Lambda functions like refund_processor, it inspects the attached MCP JSON tool schema.
LLM Tool Binding: The Gateway aggregates these descriptions into structured MCP tool definitions (including typed argument schemas and descriptions) and returns them to the agent runtime.
Real-Time Execution: When a user asks “Where is order ORD-001?”, the LLM evaluates the available tools, matches the user intent to get_order, generates the input parameters ({"order_id": "ORD-001"}), and sends a tools/call request to the Gateway. The Gateway automatically routes the payload to the underlying API Gateway REST endpoint, which triggers the corresponding AWS Lambda function behind the scenes.

Step-by-Step Setup

Step 1: Deploy the Lambda Functions
- Create two separate Lambda functions using the Python 3.12 runtime in the AWS Lambda console: order-tracker and refund-processor (please refer to starter/lambda/ folder).
- Attach an execution role with basic Lambda permissions for CloudWatch Logs and note each function’s ARN.
Step 2: Configure the API Operations
- Open API Gateway -> Create API -> REST API.
- Create the resources and GET methods configured as Lambda proxy integrations with the order-tracker Lambda function according to the mapping table below.
- Deploy the REST API to a stage (such as prod) and copy your REST API ID and stage name.

| Method and Resource | Operation Name | Description |
| GET /orders/{order_id} | get_order | Fetch order status details |
| GET /customers/{customer_id}/orders | get_customer_orders | List all orders for a customer |
| GET /customers/{customer_id} | get_customer | Retrieve customer profile details |

Step 3: Set up the AgentCore Gateway
- Navigate to Amazon Bedrock -> AgentCore -> Gateways and create a Gateway named CustomerSupportGateway using a NONE authorizer.
- Add the targets mapping to your infrastructure according to the mapping table below.
- Copy the resulting Gateway URL (ending with /mcp).

Validation

To confirm that the Gateway tools are accessible via the Model Context Protocol, run the MCP Inspector CLI tool:

npx @modelcontextprotocol/inspector

Connect to your Gateway URL and confirm that all configured tools (get_order, get_customer_orders, get_customer, and refund_processor) are listed properly.

Bedrock Knowledge Base (S3 Vector Search)

To provide grounded product and policy answers, we configure a Managed Knowledge Base backed by an S3 bucket.

Step 1: Upload starter/product_catalog.txt to your S3 bucket.
Step 2: Open Amazon Bedrock AgentCore -> Built-in tools -> Knowledge Base -> Create Managed Knowledge Base named CustomerSupportKB.
Step 3: Configure the setup parameters according to the table below:

Step 4: Sync the data source and copy your generated Knowledge Base ID.

Validation

Open the Bedrock console -> Knowledge Bases -> CustomerSupportKB -> Test tab, and query: “What is the return policy for electronics?” (Expected: a result detailing the 15-day return window).

AgentCore Memory

To ensure multi-turn contextual continuity and long-term user recall across separate sessions:

Step 1: In the Bedrock console, navigate to AgentCore -> Memory and create a resource named CustomerSupportMemory.
Step 2: Configure the memory strategies using the schema below:

| Strategy Type | Strategy Name | Namespace Template |
| Semantic extraction | customer_facts | cs_agent/{actorId}/facts |
| User preference | customer_preferences | cs_agent/{actorId}/preferences |

Step 3: Wait until the memory state becomes ACTIVE, then copy the Memory ID.

Putting Configs Together

Once provisioned, input your collected GATEWAY_URL, KB_ID, and MEMORY_ID directly into the configuration block of main.py:

GATEWAY_URL = "https://<alias>.gateway.bedrock-agentcore.<region>.amazonaws.com/mcp"
KB_ID = "<Your-Knowledge-Base-ID>"
REGION = "us-east-1"
MEMORY_ID = "<Your-Memory-ID>"

Lifecycle Deployment Flow: Config -> Build -> Deploy -> Test

Deploying an autonomous agent requires a systematic sequence using the bedrock-agentcore-starter-toolkit:

1. Configure Runtime

To initialize the deployment environment and establish metadata mapping for your AWS account, execute the configuration command via the toolkit:

uv run agentcore configure \
  --entrypoint main.py \
  --name customer_support_agent \
  --deployment-type direct_code_deploy \
  --runtime PYTHON_3_13 \
  --disable-memory

Parameter Breakdown

| Flag / Option | Purpose & Description |
| --entrypoint main.py | Specifies the root script containing the @app.entrypoint ASGI application handler (main.py). |
| --name customer_support_agent | Defines the unique identifier name for the agent within the local configuration registry. |
| --deployment-type direct_code_deploy | Tells the toolkit to bundle and push raw source code directly to Amazon S3 rather than building heavy container images, accelerating iteration cycles. |
| --runtime PYTHON_3_13 | Configures the managed serverless execution runtime environment version on AgentCore. |
| --disable-memory | Disables automated toolkit memory provisioning. This ensures the agent uses the custom CustomerSupportMemory resource explicitly configured in main.py. |

Anatomy & Impact of the Generated `.bedrock_agentcore.yaml` File

Running the configuration command generates a local hidden state tracking file named .bedrock_agentcore.yaml in your project root. This file acts as the central control plane for all subsequent toolkit interactions.

Here is how its key sections affect your deployment:

Source & Entrypoint Mapping (agents block): Specifies the exact absolute path to entrypoint and source_path. When you run agentcore deploy, the toolkit references these paths to bundle your code files and upload them to the designated S3 bucket (s3://bedrock-agentcore-codebuild-sources-...).
AWS Infrastructure Binding (aws block): Automatically records your target AWS account, region (us-east-1), and the execution_role ARN (e.g., arn:aws:iam::783469453888:role/AmazonBedrockAgentCoreSDKRuntime-...). This ensures that any command you execute targets the correct AWS environment without requiring manual environment variable exports every time.
Runtime State Tracking (bedrock_agentcore block): Once deployed, this section stores the generated remote resource identifiers, including the agent_id (e.g., customer_support_agent-nUpbKY5Ff2) and the full agent_arn. Subsequent commands like agentcore invoke read these identifiers to route payloads directly to your active remote agent runtime.

2. Deployment

uv run agentcore deploy

Deployment Mechanics & Runtime Initialization

When you execute agentcore deploy, the toolkit and Amazon Bedrock AgentCore execute a structured provisioning workflow behind the scenes:

Source Bundling & S3 Upload: The toolkit bundles your local project directory (including main.py and local dependencies) and pushes the archive up to the designated S3 source bucket specified in your .bedrock_agentcore.yaml configuration (s3://bedrock-agentcore-codebuild-sources-...).
Container Provisioning & Runtime Activation: Amazon Bedrock AgentCore reads the deployment specification (PYTHON_3_13, direct_code_deploy, platform linux/arm64) and provisions a managed serverless execution container instance.
Agent Warm-Up & ASGI Bootstrapping: Inside the remote container, AgentCore pulls your uploaded source files from S3 and mounts the execution environment. It spins up the ASGI server registered by your BedrockAgentCoreApp instance (app = BedrockAgentCoreApp()) from main.py. Once the ASGI application binds to the runtime port and completes its internal initialization, the deployed agent (referenced by its unique agent_id) goes into an Active state, ready to receive incoming invocations and handle asynchronous event loops.

3. Configure IAM Permissions

uv run setup_permissions.py

This script reads .bedrock_agentcore.yaml to locate your execution role name and runtime ID. It uses this mapping to safely attach inline IAM policies granting your deployed agent access to Bedrock Knowledge Bases, AgentCore Memory namespaces, and the Browser session pool.

4. Integration Testing & Real-World Validation

To verify autonomous execution across subsystems, we executed structured test invocations against the live runtime endpoint:

Test 1: Backend Integration (MCP & Lambda)
- Command: agentcore invoke '{"prompt": "Can you track order ORD-001?", "customer_id": "CUST-123", "session_id": "t1"}'
- Validation: Agent routes request via AgentCore Gateway to order-tracker Lambda, returning status, carrier (UPS), tracking number (TRK987654321), and estimated delivery.
Test 2: Cross-Session Long-Term Memory Recall
- Session A: agentcore invoke '{"prompt": "Hi, I am Jane. I prefer concise responses.", "customer_id": "CUST-123", "session_id": "s-A"}'
- (Wait 30s for background memory extraction)
- Session B (New Session): agentcore invoke '{"prompt": "Do you remember my name and communication preference?", "customer_id": "CUST-123", "session_id": "s-B"}'
- Validation: Agent successfully recalls “Jane” and formats its response concisely without needing prior prompt context in session s-B.
Test 3: Knowledge Base RAG Retrieval
- Command: agentcore invoke '{"prompt": "What are the benefits of the Platinum loyalty tier?", "customer_id": "CUST-123", "session_id": "t3"}'
- Validation: Retrieves grounded facts from S3 vector index (free same-day shipping, 15% discount, priority support).
Test 4: Sandbox Code Execution
- Command: agentcore invoke '{"prompt": "I am a Gold member with 4250 points. Calculate my discount on a $150 standard order.", "customer_id": "CUST-123", "session_id": "t5"}'
- Validation: Executes sandbox Python script, correctly applying 4,000 redeemed points ($40) + 10% Gold tier discount, yielding the exact mathematical total and remaining point balance.

Business Value & Engineering Takeaways

Integrating multi-agent tools directly into enterprise workflows generates distinct operational metrics:

| Technical Component | Business Problem Solved | Business ROI Impact |
| AgentCore Gateway (MCP) | Siloed legacy APIs requiring custom integration code | Standardizes backend integration; reduces API connector dev time by ~60%. |
| AgentCore Memory | Repetitive user context switching & disjointed support tickets | Increases First Contact Resolution (FCR) by remembering customer facts across channels. |
| Code Interpreter | Mathematical hallucinations in financial/discount calculations | Eliminates billing errors with 100% deterministic calculation precision. |
| Bedrock Knowledge Base | Hallucinated support policies & outdated documentation | Grounded RAG responses ensure zero compliance/policy drift. |

Advanced Architecture Extension: Production Integration & Runtime Trade-Offs

Note: The following integration and architectural analysis go beyond the baseline requirements of the original project spec, exploring production-ready deployment patterns for enterprise environments.

Finding Your AGENT_RUNTIME_ARN

Once your agent is deployed via the starter toolkit, you can retrieve its unique Amazon Resource Name (ARN) either through the AWS CLI or the management console:

Via AWS CLI: aws bedrock-agentcore list-agent-runtimes --region us-east-1
Via AWS Console: Navigate to Amazon Bedrock -> AgentCore -> Runtimes , select your deployed agent (customer_support_agent), and copy the Agent Runtime ARN from the overview panel. It follows the format: arn:aws:bedrock-agentcore:<region>:<account-id>:runtime/<agent-name>-<hash>. You can also find it locally in your project’s .bedrock_agentcore.yaml configuration file.

Production Integration: Invoking AgentCore from a FastAPI Backend

Instead of executing your agent solely through local CLI commands, you can wrap it inside a production microservice using FastAPI and the AWS SDK (boto3). Your backend acts as an API gateway that securely proxies requests to the managed AgentCore container runtime:

import json
import boto3
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(title="Customer Support API Gateway")

# Initialize the Bedrock AgentCore boto3 client
bedrock_agentcore_client = boto3.client("bedrock-agentcore", region_name="us-east-1")
AGENT_RUNTIME_ARN = "arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/customer_support_agent-nUpbKY5Ff2"

class ChatRequest(BaseModel):
    prompt: str
    customer_id: str
    session_id: str # Requires valid session tracking format

@app.post("/api/v1/support/chat")
async def invoke_agent(request: ChatRequest):
    try:
        payload = {
            "prompt": request.prompt,
            "customer_id": request.customer_id,
            "session_id": request.session_id
        }

        # Programmatically invoke the remote AgentCore runtime
        response = bedrock_agentcore_client.invoke_agent_runtime(
            agentRuntimeArn=AGENT_RUNTIME_ARN,
            runtimeSessionId=request.session_id,
            payload=json.dumps(payload)
        )

        response_body = response["body"].read().decode("utf-8")
        return {"status": "success", "data": json.loads(response_body)}

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Architectural Decision: Why Bedrock AgentCore Runtime over AWS Lambda?

While an AWS Lambda function (even utilizing 10GB container images) can technically host agent logic and the Strands SDK, it introduces severe architectural friction for autonomous agentic workflows.

| Evaluation Dimension | AWS Lambda (Container / Zip) | Amazon Bedrock AgentCore Runtime | Architectural Impact |
| Execution Timeout | Hard-capped at 15 minutes (29 seconds for synchronous API Gateway). | Built for long-running, persistent agent sessions. | Agentic loops requiring multiple reasoning steps or human-in-the-loop pauses can time out prematurely on Lambda. |
| State & Memory | Fully stateless; requires manual boilerplate code to persist data across turns (e.g., DynamoDB). | Native, built-in support for memory hooks, semantic fact extraction, and cross-session management. | AgentCore eliminates custom CRUD boilerplate for conversation state and user preference tracking. |
| Cost & Billing Model | Billed for the entire duration the function execution runs. | Optimized for agent workloads; billed based on active execution. | AI agents spend significant time idling while waiting for LLM tokens or external API tools. Lambda bills you for that wait time; AgentCore does not. |
| MicroVM Isolation | Shared multi-tenant execution environment per container instance. | Isolated microVM execution environment per runtime container. | Enhanced security segregation when executing dynamic tool calls or untrusted code snippets. |

What’s Next

In Part 5, we will build a production-grade multi-agent customer support system using Amazon Bedrock AgentCore and the Strands Agents SDK.

About the Author

Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.

Connect with me on LinkedIn

The post Autonomous Tool Orchestration & Multi-Capability Agent Systems with Amazon Bedrock AgentCore & Strands SDK appeared first on Behind the Build.

Prompt-Driven Routing & Managed Agent Architecture with Amazon Bedrock AgentCore

Jonathan Wong — Tue, 03 Nov 2026 20:12:11 +0000

Part 3 of the series: “Engineering Next-Gen AI Agents: Reflections on the Future AWS Agent Engineer Nanodegree”

In Part 2 of this series, we covered the foundational phase—the AWS AI Practitioner Challenge and rapid prototyping using AWS PartyRock. While low-code sandboxes are great for early proof-of-concepts, enterprise production systems require strict control, robust state management, and rigorous evaluation frameworks.

Crossing into Project 1 of the Future AWS Agent Engineer Nanodegree , the engineering stakes were raised significantly. The objective was to build an enterprise-grade customer support chatbot for an online shop using the Amazon Bedrock AgentCore managed harness.

Unlike traditional rule-based chatbots that rely on explicit condition nodes, if-else logic, or hardcoded classification pipelines, this application routes incoming customer intents entirely through system prompt engineering.

Here is a deep-dive breakdown of how the architecture was built, tested, and systematically evaluated using automated LLM-as-a-judge metrics.

1. Architectural Overview & System Flow

The pre-provisioned infrastructure leverages a cloud-native serverless architecture consisting of the AgentCore Gateway , AWS Lambda , Amazon DynamoDB , and Amazon S3.

Core Architectural Components

Amazon Bedrock AgentCore Gateway: Acts as the managed entry point and orchestration harness for the LLM runtime. It manages session context, wraps tool definitions, and enforces system prompt boundaries.
AWS Lambda & Simple RAG: The backend logic executes inside AWS Lambda. The function injects a localized FAQ.json document into the prompt payload to serve as a lightweight Retrieval-Augmented Generation (RAG) knowledge base.
Amazon DynamoDB: Serves as the high-throughput, low-latency operational data store for filed bug reports.
- Why DynamoDB over MySQL? For semi-structured operational logs like bug reports—where individual records may vary in metadata fields (e.g., varying browser flags or client environments)—DynamoDB’s schemaless document model offers instant, key-value writes without the schema migration overhead or connection pool management required by traditional relational databases like MySQL.

High-Level End-to-End Workflow

Before diving into execution details, the project lifecycle follows a strict three-stage engineering loop:

Build Phase: Configuring the core system prompt, integrating the Lambda action groups, and setting up the DynamoDB persistence layer.
Test Phase: Deploying test harness suites (harness-tests.json) to validate intent classification and tool execution against edge cases.
Evaluation Phase: Running automated LLM-as-a-judge evaluations using Amazon Nova Pro to score generation correctness.

To understand how user inputs move through the runtime system, the architectural flow is mapped below:

2. Infrastructure Sanity Check: Testing Lambda & DynamoDB

Before crafting the core prompt, we performed an isolated infrastructure verification test using the AWS Lambda console to ensure the backend toolchain and database persistence were functioning.

Lambda Test Event Payload

We triggered the underlying bug-reporting Lambda function using a structured JSON test event containing the three required bug metadata fields:

{
  "description": "The checkout page crashes when I click the Pay button",
  "stepsToReproduce": "1. Add an item to the cart. 2. Go to checkout. 3. Click Pay.",
  "environment": "Chrome 120 on macOS Sonoma"
}

Verification via DynamoDB Console

A successful execution returns a JSON payload containing a newly generated ticketId and a "status": "OPEN".

To verify data persistence:

Navigate to the Amazon DynamoDB Console -> Explore items.
Select the bug-report-tool-stack-bug-reports table.
Click Run to execute a table scan.
The newly created item appears with its unique ticketId, timestamp, description, environment details, and initial OPEN state.

3. Core Mission: Prompt-Driven System Routing (`system_prompt.txt`)

The core challenge of this project was enforcing strict routing behavior without hardcoded conditional logic. The system prompt acts as both a state machine and a guardrail controller.

Below is the full production system prompt (system_prompt.txt) engineered for the application:

You are the customer support assistant for an online shop.

For every customer message, you must first classify it into exactly ONE of the following three categories.  
Make the classification BEFORE doing anything else.

------------------------------------------------------------
1. BUG REPORT
------------------------------------------------------------
The customer says something on the website or app is broken, malfunctioning, or not working as expected.

You MUST collect all three required fields:

1. description — Description of the bug, in the customer’s own words  
2. stepsToReproduce — Steps someone should follow to reproduce the issue  
3. environment — Customer’s environment (browser, OS, device)

Rules:
- Customers rarely provide all three up front.
- If any item is missing, ask for EXACTLY ONE missing item at a time.
- Do NOT call the create_bug_report tool until ALL THREE fields are collected.
- Once all three are gathered, call the tool with:
    - description
    - stepsToReproduce
    - environment
- After the tool succeeds, it returns a ticketId.
  You MUST tell the customer their ticket ID and inform them the engineering team will follow up.

------------------------------------------------------------
2. PLATFORM QUESTION
------------------------------------------------------------
Questions about orders, shipping, returns, refunds, payments, products, accounts, or privacy.

Rules:
- Answer ONLY using the FAQ document provided.
- NEVER invent policies.
- If the FAQ does NOT contain the answer, reclassify the message as Category 3.

------------------------------------------------------------
3. ANYTHING ELSE
------------------------------------------------------------
Any message that is NOT a bug report and NOT answerable from the FAQ.

Rules:
- Politely explain you cannot help with that here.
- Refer the customer to the human support line at 1‑800‑555‑0199 (Mon–Fri).

------------------------------------------------------------
GENERAL RULES
------------------------------------------------------------
- Always be polite and concise.
- Never fabricate information.
- Routing is a STRICT classification problem: pick ONE category only.
- Category definitions must be applied crisply.
- Follow the bug‑report checklist exactly and ask for missing items ONE AT A TIME.

--- FAQ document ---
{{FAQ}}

Key Design Highlights of the System Prompt:

Explicit Intent Ordering: Mandates that the LLM performs internal classification before choosing an output strategy.
Single-Question Collection Strategy: Prevents the LLM from overwhelming users by enforcing a strict rule: “ask for EXACTLY ONE missing item at a time”.
Strict Fallback Mechanisms: Eliminates hallucinated store policies by forcing any unanswerable platform question to fall back to Category 3 (Human Support Routing).

4. Constructing the Test Harness (`harness-tests.json`)

To evaluate the agent’s behavior across edge cases, we constructed a test suite in harness-tests.json. Each test item defines an id, a customer prompt, and an expected intent description that serves as the ground-truth reference for evaluation:

{
  "tests": [
    {
      "id": "t1_bug_report_full",
      "prompt": "The checkout page crashes when I click the Pay button. Steps: 1. Add an item to the cart. 2. Go to checkout. 3. Click Pay. Environment: Chrome 120 on macOS Sonoma.",
      "expected": "create a bug report"
    },
    {
      "id": "t2_bug_report_missing_environment",
      "prompt": "I can't upload my profile picture; it shows an error. Steps: Go to account settings and try uploading any image. Environment: not provided.",
      "expected": "ask for missing environment"
    },
    {
      "id": "t3_platform_question_shipping",
      "prompt": "How long does shipping take to New York?",
      "expected": "answer from FAQ"
    },
    {
      "id": "t4_platform_question_refund",
      "prompt": "Can I return an item if I lost the receipt?",
      "expected": "answer from FAQ"
    },
    {
      "id": "t5_anything_else_general_chat",
      "prompt": "Can you recommend a good laptop for gaming?",
      "expected": "refer to human support line"
    },
    {
      "id": "t6_anything_else_not_supported",
      "prompt": "Can you delete my account permanently?",
      "expected": "refer to human support line"
    }
  ]
}

Executing the test suite pairs the model’s actual response against the reference response. For instance, running a test on an incomplete bug report yields:

{
  "prompt": "the app crashes every time I try to upload a file...",
  "referenceResponse": "Acknowledges the issue and asks for steps to reproduce...",
  "modelResponses": [
    {
      "response": "I'm sorry to hear about the crash. Could you tell me...",
      "modelIdentifier": "my-support-chatbot"
    }
  ]
}

5. Automated Evaluation via Amazon Bedrock Evaluations

Relying on manual spot-checks is insufficient for enterprise deployment. We automated quality assessment using Amazon Bedrock Model Evaluation Jobs , using Amazon Nova Pro (amazon.nova-pro-v1:0) as an LLM-as-a-Judge evaluator model.

AWS CLI Evaluation Job Command Breakdown

The evaluation command utilizes a set of robust configuration blocks:

--evaluation-config: Defines the automated evaluation parameters. It points to a dataset configuration located on S3 (output_eval_dataset.jsonl) under a general task type, specifies the evaluation metric (Builtin.Correctness), and designates Amazon Nova Pro (amazon.nova-pro-v1:0) as the independent judge model via evaluatorModelConfig.
--inference-config: Points to the precomputed inference output (my-support-chatbot) generated by our test harness runs.
--output-data-config: Specifies the destination S3 bucket path where evaluation reports and logs will be written.

aws bedrock create-evaluation-job \
  --job-name support-chatbot-eval-run-1 \
  --role-arn <BedrockEvalRoleArn> \
  --evaluation-config '{
    "automated": {
      "datasetMetricConfigs": [{
        "taskType": "General",
        "dataset": {
          "name": "support-chatbot-eval-dataset",
          "datasetLocation": {
            "s3Uri": "s3://<EvalDatasetBucketName>/output_eval_dataset.jsonl"
          }
        },
        "metricNames": ["Builtin.Correctness"]
      }],
      "evaluatorModelConfig": {
        "bedrockEvaluatorModels": [{
          "modelIdentifier": "amazon.nova-pro-v1:0"
        }]
      }
    }
  }' \
  --inference-config '{
    "models": [{
      "precomputedInferenceSource": {
        "inferenceSourceIdentifier": "my-support-chatbot"
      }
    }]
  }' \
  --output-data-config '{"s3Uri": "s3://<EvalDatasetBucketName>/results/"}' \
  --region us-east-1

Analyzing Results in the Console

Once the job completes:

Navigate to Amazon Bedrock Console -> Assess -> Evaluations.
Open support-chatbot-eval-run-1.

As shown in the evaluation report dashboard:

Metrics Summary: The system achieved a normalized Correctness score of 1.00 across all test prompts.
Generation Metrics Breakdown: The distribution histogram shows that 100% of the prompts (6 out of 6) hit the maximum score of 1.0, confirming that prompt-driven routing, FAQ retrieval, missing item collection, and fallback handoffs operated with 100% precision.

Key Takeaways for Tech Leaders

System Prompts ARE Business Logic: Deterministic routing doesn’t always require rigid state machines. Well-structured prompt guardrails can handle multi-category intent routing gracefully.
Evaluation-Driven Development: Treating LLM testing with the same discipline as traditional CI/CD unit testing—using precomputed test suites and automated LLM-as-a-judge scoring—is essential before deploying AI agents to production.

In Part 4 , we will step beyond single-agent routing into AI Support Agent using Amazon Bedrock AgentCore and the Strands SDK.

The post Prompt-Driven Routing & Managed Agent Architecture with Amazon Bedrock AgentCore appeared first on Behind the Build.

Foundations & Rapid Prototyping: Inside the AWS AI Practitioner Challenge

Jonathan Wong — Tue, 27 Oct 2026 00:12:24 +0000

Part 2 of the series: “Engineering Next-Gen AI Agents: Reflections on the Future AWS Agent Engineer Nanodegree”

In my previous post, I shared the milestone of completing the Future AWS Agent Engineer Nanodegree , sponsored by the AWS AI & ML Scholars Program. But before diving into complex multi-agent architectures and production-grade tool orchestration, every scholar had to build a rock-solid foundation.

The program was structured into two distinct parts:

The Challenge Phase (AWS AI Practitioner Challenge)
The Nanodegree Phase (Future AWS Agent Engineer Track)

In this installment, we look at how the journey began, starting with foundational AI learning and rapid prototyping.

Step 1: The Challenge Phase & AWS AI Practitioner Learning Plan

The gateway into the scholarship was the AWS AI Practitioner Challenge. Rather than diving straight into raw code and backend API configuration, the program kicked off with structured, self-paced training mapped directly to the AWS AI Practitioner Learning Plan.

For experienced engineers and technology leaders, this phase served as an essential baseline refresh on how AWS approaches cloud-native artificial intelligence. It covered:

The core spectrum of foundational models available on AWS.
Responsible AI frameworks, security, and governance in cloud environments.
The foundational mechanics of Retrieval-Augmented Generation (RAG) and prompt engineering before scaling up to autonomous agents.

Step 2: From Theory to Application with AWS PartyRock

To graduate from the Challenge Phase and secure a spot in the selective Nanodegree track, participants had to transition immediately from theory to execution by building functional generative AI applications.

The tool of choice for this rapid prototyping phase was AWS PartyRock (powered by Amazon Bedrock)—a generative AI app-building playground that allows creators to rapidly build working functional prototypes without getting bogged down in boilerplate code.

Building in PartyRock wasn’t just about playing with prompts; it forced a shift in mindset regarding application composition :

How do you structure multi-step prompt chains to guide an LLM toward a specific output?
How do you combine multiple models and widgets to create a cohesive user experience?
How can rapid cloud prototyping validate a product concept before writing a single line of production code?

I documented the deep-dive architectural review and lessons learned from building those initial PartyRock applications in my previous write-up:

Read the full breakdown: What We Learned from Building Two PartyRock Apps

Crossing the Threshold: Into the Nanodegree

Successfully completing the PartyRock build projects marked the finish line of the Challenge Phase—and the ticket into the highly competitive Future AWS Agent Engineer Nanodegree program (reserved for top performers in the cohort).

Clearing this initial hurdle proved that rapid prototyping and cloud-based AI literacy were fully locked in. But it also set the stage for a massive leap forward: moving away from single-window prompt interfaces and static playground apps into stateful, tool-wielding, autonomous agent engineering.

What’s Next in the Series?

Now that the foundational baseline was established, the real engineering work began.

In next article , we will cross into Part 2 of the program, exploring Amazon Bedrock AgentCore , building a customer support chatbot with active API action groups, and designing an AI support agent equipped with real memory and tool execution.

The post Foundations & Rapid Prototyping: Inside the AWS AI Practitioner Challenge appeared first on Behind the Build.

Engineering Next-Gen AI Agents: Reflections on the Future AWS Agent Engineer Nanodegree

Jonathan Wong — Sun, 25 Oct 2026 03:22:49 +0000

I’m excited to share a milestone. I’ve completed the Future AWS Agent Engineer Nanodegree, sponsored by the AWS AI & ML Scholars Program.

This journey took me through the AWS AI Practitioner Challenge, PartyRock builds, and three hands‑on AgentCore projects, including a customer support chatbot, an AI support agent, and a multi‑agent e‑commerce RAG system. Real agents. Real Bedrock tools. Real engineering.

Thank you to Amazon Web Services (AWS) and Udacity for the opportunity to dive deep into next‑generation AI agent development.

Over the next few weeks, I’ll be releasing a short article series documenting my AWS AI exploration journey, breaking down the architecture, key technical lessons, and practical takeaways from each project.

AWS AI & ML Scholars: AWS AI & ML Scholars

The post Engineering Next-Gen AI Agents: Reflections on the AWS & Udacity Nanodegree appeared first on Behind the Build.

Level Up Your AI Skills with Microsoft AI Skills Fest 2026: Ends June 12!

Jonathan Wong — Wed, 10 Jun 2026 17:11:47 +0000

If you’re looking to strengthen your AI capabilities — whether in AI agent development or AI business leadership — the Microsoft AI Skills Fest is the perfect place to start.

The event brings together everything you need to grow your AI career:
Curated Learning Playlists
Explore structured Playlists such as AI agent development and AI business leadership. Each path gives you focused, practical content to build real skills.
Learn New Knowledge at Your Own Pace
Every Playlist includes high‑quality modules so you can learn new AI knowledge and stay ahead in this fast‑moving field.
LinkedIn Live Sessions + Playback
Join Microsoft Learn expert‑led LinkedIn Live sessions covering technical deep dives, business strategy, and certification prep. If you miss a session, simply watch the LinkedIn Live playback anytime.

A Complete One‑Stop Learning Journey

Microsoft AI Skills Fest gives you a fully guided pathway from learning to certification — all in one place:

Choose your learning path
Pick the Playlist that matches your goals, whether technical or leadership‑focused.
Learn through curated modules
Build practical, job‑ready AI skills through structured lessons and real‑world scenarios.
Join or replay the exam prep session
Attend the LinkedIn Live exam prep session — or watch the playback whenever it fits your schedule.
Unlock your free exam voucher
Complete a Playlist and receive a free Microsoft certification exam voucher.
Earn your certification
Pass the exam and gain recognized proof of your AI expertise.

A smooth, end‑to‑end journey — from learning → preparation → certification → recognition.

If you’re building your AI career in 2026, this is one of the best zero‑cost opportunities to gain structured learning, expert guidance, and an official Microsoft certification.

Start your learning journey before June 12:

AI Skills Fest – AI Skills Navigator

The post Level Up Your AI Skills with Microsoft AI Skills Fest 2026: Ends June 12! appeared first on Behind the Build.

Pre-AI Lessons in the AI Era: Why Hard Work Breaks Projects Without Transparency

Jonathan Wong — Wed, 27 May 2026 04:12:10 +0000

The previous article solved the first major dysfunction: no common language between business and engineering. Once the team aligned on shared concepts, invisible tasks stopped derailing the roadmap.

But another problem remained, one that appears in almost every engineering team, especially in the AI era:
The team is full of hardworking experts…
yet the project still breaks. Why?

Hard work is not the engine of delivery when a team cannot see the system they are collectively building. In software engineering, untracked effort does not accelerate progress; it accelerates chaos. This timeless principle forms the foundation of modern engineering governance. As organizations integrate autonomous artificial intelligence into production pipelines, this human lesson becomes a fundamental survival requirement.

The Human Dysfunction: Hard Work Without Transparency

Project failure rarely stems from a lack of effort. It occurs when a team of hardworking experts operates in isolation, blinding themselves to overlapping system dependencies.

The Network Effect of Modern Features

Modern software features are no longer isolated updates. They exist as interconnected networks across multiple technical layers:

Front-End Interactions: User interfaces and state management.
Microservices: Backend business logic and API endpoints.
Workflow Automation: State machines and server-side pipelines.
Messaging Systems: Event brokers and publish/subscribe schemas.

When complexity becomes a network, individual heroism fails. Optimization at the individual level, without systemic visibility, breaks collective architecture.

Blindness, Communication Debt, and Lone-Wolf Isolation

Without a shared infrastructure for visibility, engineering teams succumb to severe operational friction:

Wasted Coding Effort: Engineers guess dependency readiness and build unnecessary defensive wrappers, temporary bypasses, and redundant fallback logic.
Communication Debt: Teams default to peer-to-peer inquiries to track deployments, schemas, and API states. This turns engineers into manual message routers, creating significant communication overhead.
The Lone-Wolf Engineer Problem: Many engineers love building things independently; it is a core part of the craft. However, in a multi-component system, a lone-wolf engineer is like a novelist trying to write a shared universe alone. Traditional sales team management tactics fail when applied to engineering because sales relies on individual quotas, whereas engineering requires collective architecture. When engineers optimize for personal productivity instead of team alignment, the system breaks.
Business Blindness: Stakeholders lose track of completed, blocked, or in-progress work, rendering project roadmaps inaccurate.

The Turning Point

Introducing structured transparency via Jira and Stand-ups

The remedy is structured transparency, establishing clear visibility engines rather than adding administrative overhead.

Jira as a Single Source of Truth: Centralizes requirements, blocker statuses, integration timelines, and staging environments into a universally accessible ledger.
Daily Stand-up Meetings: Consolidates technical clarifications into a single daily synchronization point, resolving blockers and dependencies at once.

The Results

Restoring transparency transforms raw effort into measurable progress:

Elimination of Waste: Redo cycles drop because engineers sequence tasks against real-time statuses rather than assumptions.
Stabilized Timelines: Cross-component integration becomes highly predictable, allowing business roadmaps to align with actual deployment metrics.

The AI Era: Scaling the Hardest-Working Teammate

This paradigm is highly relevant to contemporary development teams utilizing AI agents. AI agents represent the hardest-working teammates available, operating 24/7 to generate code, tests, and workflows instantaneously.

However, the foundational rule remains unchanged: speed without transparency does not scale.

The AI Problem: Exponential Chaos

When transparency is omitted, AI agents do not merely repeat human mistakes. They multiply them at machine scale.

[Missing Governance] ──► AI Agent Isolation ──► Machine-Velocity Hallucination ──► Systemic Implosion

Unbounded Output Velocity: Agents generate codebase modifications faster than human review cycles can evaluate them.
Contextless Chaining: Autonomous agents chain sequential tasks together without verifying broader architectural context.
Hallucinated Assumptions: When information is missing, an agent generates plausible-sounding but technically incorrect assumptions, mistaking a hallucination for a valid path forward.
Absence of Interpersonal Alignment: Humans resolve misunderstandings via direct conversation. AI agents cannot attend meetings, listen to context changes, or instinctively track updated deployment dependencies.

Applying Scrum to AI Agents: Transitioning to Agentic Traceability

To safely integrate AI agents, Scrum frameworks must evolve from human communication rituals into automated machine-governance guardrails.

Human Scrum Ritual	Agentic Scrum Evolution	Technical Implementation Guide
Sprint Planning	Runaway Execution Control	Establish strict scope caps, token budgets, repository access boundaries, and directory-level file permissions.
Daily Scrum	Asynchronous Log Triage	Dedicate 15 minutes to auditing anomaly dashboards, identifying logic loops, monitoring confidence metrics, and flagging reasoning drift.
Definition of Done	Mandatory Traceability	Require automated Chain-of-Thought logs, step-by-step decision validation, model-driven scoring, and schema contract compliance.

The Transparent Execution Loop

This updated methodology introduces a continuous verification loop:

Lock Interface Boundaries: Humans define and lock OpenAPI schemas, AsyncAPI payloads, and event contracts during planning.
Parallel Agent Execution: Specialized agent personas (Front-End, API, Messaging) write code concurrently against these immutable boundaries.
Real-Time Automated Validation: Specialized automation agents evaluate every commit instantly, flagging contract breaches and hallucinations directly on the Scrum board.

What It Means for Your Business

For executive leadership, this shift alters engineering dynamics from human capacity management to systematic AI orchestration.

Failing to establish agentic visibility introduces severe operational risks:

Broken integration pipelines
Wasted compute capital via runaway token consumption,
Unstable code quality.

Conversely, businesses that implement structured machine governance unlock the true potential of AI velocity, maintaining safe, predictable, and continuous software delivery.

Key Takeaways

Visibility Trumping Effort: Unchecked output from isolated human engineers or autonomous AI agents results in systemic code waste.
Agents Multiply Dysfunction: Because AI operates at machine velocity, a lack of transparency causes projects to fail much faster and with greater complexity.
The Paradigm Shift: Modern engineering management must pivot from a model based on human trust and verbal updates to one built on automated traceability and rigorous verification logs.

Conclusion

The core challenge of the AI era is not building harder-working models but managing the vast amount of code they generate. Yesterday’s lesson remains today’s reality: teams succeed only when they build in the open. By evolving Scrum from human-centric rituals into automated machine guardrails, organizations transform raw AI velocity into verifiable, production-grade progress.

What’s Next

In the next article of Pre AI Lessons in the AI Era, we will look beyond transparency and examine how other pre‑AI fundamentals become essential guardrails as your software ecosystem evolves. This past project reveals exactly how we must rethink knowledge management, release management, and customer success when AI agents join the engineering workflow.

These lessons are no longer optional. They are the structural foundations that keep an AI‑accelerated organization stable, predictable, and aligned.

The next chapter will explore how these disciplines transform — and why they matter more than ever in the AI era.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post Pre-AI Lessons in the AI Era: Why Hard Work Breaks Projects Without Transparency appeared first on Behind the Build.

The AI Revenue Illusion: Fixing Maturity Errors to Prepare for the B2AI Future

Jonathan Wong — Sun, 24 May 2026 06:06:28 +0000

Every week, companies ask the same question: “Can you add AI to our business?”, “Will AI help cut costs?”

The request is common. The readiness is not.

Most businesses want AI because they believe it will automate everything, reduce headcount, and cut costs. But AI does not work that way. It depends heavily on business maturity, process clarity, and data consistency. To understand what AI can actually do, we must first look at where a business sits on the maturity curve.

The Real-World Business Maturity Model

This model describes how businesses actually operate, not how they imagine they operate. The truth is simple: AI helps individuals at low maturity, helps the business at mid maturity, and becomes the product itself only at high maturity.

Here is how AI usefulness changes across the five levels of maturity, mapping directly to your organizational capabilities:

1. Ad hoc Stage (Low Maturity)

Capability Involved: None (No system integration)
The Reality: Work is manual, inconsistent, undocumented, and entirely dependent on individuals.
How AI Helps: It serves strictly as a personal productivity tool. Because AI cannot integrate with underlying business systems at this stage, it helps individuals summarize emails, rewrite documents, generate ideas, create templates, assist with research, and draft reports.
The Bottleneck: AI cannot help the business entity because workflows are undefined, data is scattered, and nothing is standardized. AI cannot automate chaos.

2. Repeatable Stage (Low-to-Mid Maturity)

Capability Involved: Light Automation (Manual Triggers, No ML)
The Reality: Teams begin doing tasks in similar ways, but processes are still not formally documented or deeply integrated.
How AI Helps: It assists small teams in aligning on process by drafting Standard Operating Procedures (SOPs), summarizing meetings, standardizing templates, and supporting small, manually-triggered data tasks.
The Bottleneck: AI still cannot support core company operations because data remains inconsistent and systems are completely siloed. It helps people work better, but it does not run the business.

3. Defined Stage (Mid Maturity)

Capability Involved: Automation + Machine Learning
The Reality: This is the milestone where data becomes structured enough that AI finally helps the business operational layer.
How AI Helps: AI transitions from a personal assistant to a workflow enhancer. It pairs rule-based automation with statistical pattern recognition to extract data from invoices, classify corporate documents, summarize customer conversations, enrich features for analytics, and assist in data pipelines (ETL).

4. Managed Stage (Mid-to-High Maturity)

Capability Involved: AI-Enabled Workflows (AI Supports, Does Not Replace)
The Reality: Systems are fully integrated, data pipelines are reliably established, and KPIs are measurable.
How AI Helps: AI becomes an enterprise-wide business capability. It actively supports and enhances entire operational workflows without replacing the core human processes, providing predictive organizational insights, supporting executive decision-making, and scaling customer experience improvements.

5. Optimized Stage (High Maturity)

Capability Involved: AI Product (AI is the Core Value)
The Reality: AI transitions from a supportive background layer to the actual product and value engine of the company.
How AI Helps: Only at this highly optimized stage can a company successfully build proprietary AI-driven analytics platforms, intelligent autonomous agents, predictive engines, and conversational interfaces where AI represents the core product offering.

AI Usefulness & Capabilities

The table below synthesizes how business maturity aligns with technological capabilities and real-world execution:

Automation vs. AI in the Real World

Most clients mistakenly believe that AI = Automation = Cost Reduction. In reality, they are entirely different mechanisms that work better together:

Automation is deterministic. It strictly follows rules and executes predictable tasks.
AI is probabilistic. It interprets patterns to predict, classify, summarize, or generate.

Automation Can Exist Without AI

A well-designed, rule-based system can fully automate accounting workflows, P&L calculations, inventory reordering, payroll, compliance checks, and data validation. These systems do not need AI; they simply need operational clarity, strict rules, and predictable inputs.

The Blueprint: An AI-Enabled Business

Many clients believe they need to build an AI Product because investors ask about it, competitors talk about it, and the market rewards AI narratives.

However, the correct answer is rarely to build an AI product. The correct answer is to build an AI-enabled business. AI should accelerate your workflow, not replace it.

Example: An accounting automation product runs entirely on deterministic rules. AI acts as the accelerator by extracting raw data from invoices, summarizing transactions, and classifying expenses. The product itself is not AI; the product is accounting automation. AI is simply the engine behind it.

Modern AI Tools Supporting Daily Workflows

Achieving an AI-enabled business flow is easier than ever because modern tools drastically reduce the technical barrier to adoption. Instead of writing custom code for basic tasks, teams can use configuration-driven platforms to analyze data, streamline productivity, or build internal workflows instantly.

ChatGPT by OpenAI (Personal & Team Productivity Sandbox):
- Capability: Serves as a versatile natural language interface for individual or team-wide ideation, writing, and unstructured data structuring.
- Real-World Example: A marketing executive copy-pastes a chaotic, 2,000-word transcript from a brainstorming session into ChatGPT and prompts: “Turn this mess into a structured product brief with a clear background, key feature bullets, and five potential taglines.” Within ten seconds, ChatGPT delivers a highly organized document ready to share with the creative team.
PartyRock (Rapid Prototyping & Sandbox Testing):
- Capability: A free, zero-code environment powered by Anthropic Claude that allows anyone to upload unstructured data (up to 120,000 characters) to extract summaries, trends, and structures.
- Real-World Example: A marketing coordinator uploads a massive CSV file containing raw customer feedback from a recent product launch. Within seconds, they build an app that separates the data into positive vs. negative sentiment, drafts personalized email responses for the frustrated customers, and translates the feedback into structural feature requests for the product engineering team.
Data Analysis with Amazon Q (Enterprise Insights):
- Capability: Merges completely unrelated enterprise datasets using plain English, backed by AWS Nova and Anthropic Claude.
- Real-World Example: A regional sales manager asks, “Compare our Q3 CRM pipeline data in Salesforce with the actual product usage logs sitting in our AWS database to show me which accounts are at risk.” Amazon Q automatically writes the backend queries, merges the datasets, and outputs a prioritized customer churn risk report.
Chatbot Creation via Bedrock & Lex (Instant Knowledge Bases):
- Capability: Automatically builds an intelligent, data-aware chatbot without writing any custom code.
- Real-World Example: An HR team drops 400 pages of scattered PDF employee handbooks, health insurance policies, and compliance guidelines into an Amazon S3 bucket. AWS automatically spins up a secure vector database, links it to Claude, and deploys an internal chat interface where employees can instantly ask, “What is our policy on paternity leave for international transfers?”
AWS SageMaker (Enterprise Machine Learning & Custom AI Products):
- Capability: Provides a fully managed infrastructure for building, training, fine-tuning, and deploying proprietary machine learning models and large language models (LLMs) at scale.
- Real-World Example: A fintech company uses SageMaker to train a custom fraud-detection model on tens of millions of historical transaction logs. The proprietary model is deployed into their live production pipeline, flagging suspicious credit card charges with millisecond latency and running custom reinforcement learning loops to continuously adapt to new fraud patterns.

Tool Alignment Across the Business Maturity Spectrum

Different tools require different levels of data consistency and infrastructure maturity to be useful. The table below maps where these modern tools fit, ensuring you don’t deploy an advanced tool onto a chaotic foundation:

| Business Maturity Stage | Capability Involved | Recommended Modern AI Tools | How the Tool Operates at This Level |
| Ad hoc | None (Siloed Individual Productivity) | ChatGPT , Claude Pro, Gemini Advanced | Used entirely as a sandbox app for individual tasks (e.g., rewriting drafts, brainstorming, summarizing emails). No system integrations required. |
| Repeatable | Light Automation (Manual triggers, no ML) | PartyRock , Notion AI, Microsoft Copilot (Basic) | Used by small teams to build ad-hoc templates, draft recurring SOP guidelines, and summarize specific meeting transcripts manually. |
| Defined | Automation + Machine Learning | Amazon Q , Document AI, Zapier AI | Securely connects to structured, documented company datasets. Automatically extracts data fields from documents and transforms them to fit defined business rules. |
| Managed | AI-Enabled Workflows (AI supports, does not replace) | AWS Bedrock + Lex , Salesforce Einstein, HubSpot AI | Integrated deeply into live corporate pipelines (CRMs, ERPs, S3 Buckets). AI automatically monitors live data, updates records, and triggers automated follow-up sequences. |
| Optimized | AI Product (AI is the core value) | AWS SageMaker , LangChain, Custom API Frameworks | Used to build, fine-tune, and deploy proprietary AI algorithms and autonomous agents that directly serve external customers and B2AI systems. |

AI Must Add Revenue Value, Not Just Cut Costs

The market does not reward companies that use AI merely to reduce headcount; it rewards companies that use AI to generate new revenue.

Take Cloudflare as a prime example. When they announced AI-related restructuring, the market punished them because the move looked like basic, short-sighted cost-cutting rather than a play for new product value or top-line revenue growth. AI should expand your capabilities and uncover hidden markets, not just shrink your payroll.

But what is the next major revenue channel unlocked by AI? More importantly, what is the cost of falling behind?

If your business views AI strictly as an internal efficiency tool, you are setting yourself up for a massive, structural loss. While you focus on shaving pennies off your operational costs, the paradigm is shifting entirely. The real business threat, and the biggest financial opportunity, is no longer about making your human staff faster. It is about capturing a massive, unmapped ecosystem of programmatic buyers.

The Strategic Shift: From AI Ready to Agent Ready

Most companies ask, “Are we AI ready?” That is no longer the right question.

Traditional AI Readiness focuses purely on internal efficiency, like cleaning data, documenting workflows, laying automation foundations, and upgrading integration maturity. While these steps are necessary, they are no longer sufficient.

The real transformation is occurring externally: Your next customer may not be human; your next buyer may be an AI agent. This is the massive commercial shift from being AI Ready to being Business-to-AI (B2AI) Ready .

AI Ready: Focuses Internally (Optimizes Employee Workflows)
B2AI Ready: Opens Externally (Exposes Machine-Readable Surfaces)

What Business-to-AI Ready Actually Means

An “AI Agent buyer” is not a futuristic concept; it is an active economic channel utilizing specialized infrastructure landing today. Rather than navigating the web like a human, autonomous agents operate as independent software actors driven entirely by logic, policy, and strict parameters to execute transactions instantly.

To capture this automated market, your business must expose machine-readable surfaces (such as structured APIs and clear schemas) that autonomous software can seamlessly understand, trust, and interact with. Instead of rewriting your entire codebase, becoming “Agent Ready” means architecting your digital pipeline to support the modern, agent-native tech stack:

Cryptographic Identity (KYC for Software): Integrating with open standards like the x402 protocol to instantly parse machine-readable mandates, verify an agent’s provenance, and authenticate its authority to act on behalf of a human or enterprise.
Handling Programmatic Paywalls: Structuring your web endpoints to serve native machine-facing feedback, such as encountering an HTTP 402 (Payment Required) status code, which an agent’s reasoning loop can interpret automatically.
Enterprise-Grade Agent Payments: Ensuring your systems can natively interact with managed financial substrates like Amazon Bedrock AgentCore Payments to settle transactions via identity-bound wallets, enforce programmable spending limits, and process friction-free microtransactions.
Data-Driven Discovery: Replacing emotional branding hooks with flawless, highly structured product catalogs and metadata metadata. Agents select vendors based on verifiable trust signals, strict performance metrics, and policy constraints rather than catchy logos or visual marketing.

The Third Commercial Channel

B2AI introduces a completely new revenue stream, transforming how we view market access:

B2C (Business-to-Consumer): Selling directly to human individuals.
B2B (Business-to-Business): Selling to human-led organizations.
B2AI (Business-to-AI): Selling directly to autonomous software agents.

Key Takeaways

Maturity Dictates Utility: AI serves individuals at low maturity, enhances business workflows at mid maturity, and powers core products only at peak maturity.
Stop Automating Chaos: AI is probabilistic (pattern-based) and cannot fix broken workflows; deterministic (rule-based) automation must be established first.
The Revenue Imperative: The market punishes companies using AI merely for headcount cost-cutting. True value lies in deploying AI to expand top-line capabilities.
The B2AI Paradigm Shift: Internal “AI Readiness” only lowers operational expense. External “Business-to-AI Readiness” builds machine-readable infrastructure to capture the emerging economy of autonomous software buyers.

The post The AI Revenue Illusion: Fixing Maturity Errors to Prepare for the B2AI Future appeared first on Behind the Build.

The New Customer Is Not Human: Business-to-AI (B2AI)

Jonathan Wong — Thu, 21 May 2026 22:07:53 +0000

Why Business-to-AI (B2AI) is Your Company’s Next Essential Commercial Channel

For two decades, corporate strategy assumed a single, immovable truth: every digital transaction begins with a person. That baseline assumption is breaking.

AI agents are emerging as independent economic actors that evaluate options, negotiate, authenticate, and pay. This is not a speculative future. The infrastructure is landing today in Coinbase’s x402 open-payment standard, Amazon Bedrock AgentCore Payments, and Cloudflare’s bot-friendly security surfaces. The customer at the other end of your digital pipeline is no longer guaranteed to be human. As Forbes captures the shift clearly: “In the not too distant future agents will account for most transactions online.”

This is not a technical footnote. This is the birth of a brand-new commercial engine that Forbes calls fintech’s next billion-dollar category : Business-to-AI (B2AI).

The Third Commercial Channel

The internet structure gave us Business-to-Consumer (B2C) and Business-to-Business (B2B). AI introduces the third lane: Business-to-AI (B2AI).

B2C Channel: Individual Consumers (Driven by Emotion & UX)
B2B Channel: Corporate Procurement (Driven by Sales Cycles)
B2A Channel: Autonomous AI Agents (Driven by Logic & Policy)

In this model, your buyer is an autonomous agent. It does not browse, look at advertisements, or get stuck in traditional multi-month enterprise sales cycles. It evaluates parameters, makes a decision, and executes the transaction instantly.

If agents are on track to account for most online transactions, your company’s commercial stack must evolve immediately to capture them. B2AI is not a niche feature; it is a fundamental platform shift.

The Business to AI Stack

Business to AI is not a future concept. The stack is already here. Identity, payments, and interaction surfaces have all begun shifting toward agent‑native design. If these pieces feel far apart today, it is only because they were built by different companies — but architecturally, they form a single system. The distance is not conceptual. It is only temporal.

Identity and Trust: KYC for Software

If agents are going to transact, they require cryptographic proof of identity. The x402 protocol—an open standard championed by the Linux Foundation along with Coinbase, Stripe, and Cloudflare—is the first major attempt to solve this.

Built on top of the native web status code HTTP 402 (Payment Required), x402 delivers:

Cryptographic Identity : Secure verification of the agent’s provenance.
Authenticated Authority : Clear proof that the agent can act for a human or business.
Programmable Spending : Hardcoded parameters that govern what an agent can purchase.
Machine-Readable Mandates : Transparent instructions that standard web servers can instantly parse.

This is Know-Your-Customer (KYC) compliance engineered for autonomous software. Without native machine identity, there is no trust. Without trust, automated payments stall.

Enterprise-Grade Agent Payments

Moving payments from a theoretical concept to enterprise architecture requires a managed substrate. AWS filled this gap by launching Amazon Bedrock AgentCore Payments, the first enterprise-ready payment layer designed for AI agents. This service allows developers to move away from building custom checkout billing logic for AI workflows.

[Agent Execution Loop] 
       │
       ▼
Encounters Paywall (HTTP 402) 
       │
       ▼
AgentCore Intercepts ──► Authenticates Wallet (Stripe Privy / Coinbase CDP)
       │
       ▼
Executes Stablecoin Settlement (USDC) ──► Delivers Cryptographic Receipt to Endpoint

AgentCore Payments embeds financial rails natively inside the agent’s reasoning loop. Backed by Stripe’s Privy infrastructure and Coinbase, it features identity-bound wallets, spending guardrails, full loop observability, and supports friction-free microtransactions that would otherwise be wiped out by legacy credit card processing fees.

The Shift in Interaction Surfaces

As technology leaders, we must recognize that interaction surfaces shift cyclically, and the payment flow moves with them:

Desktop → mobile → cloud agents → ambient AI

Every time this surface shifts, the formula of intention, authentication, and channel changes with it. We have actually been optimizing for bots for decades via Google Search. Search Engine Optimization (SEO), schema markups, and XML sitemaps are forms of negotiation with a non-human crawler. The critical modern difference? The bot no longer just reads your site; it has a wallet, it reasons, and it buys. The interaction surface is no longer a graphical user interface (GUI); it is an API.

Stack In Conceptual Layers

Layer	Core Concept	Purpose	Example
Identity Layer	KYC for Agents	Establishes who the agent is, what authority it has, and how it authenticates.	Coinbase x402 — cryptographic identity, programmable spending rules.
Transaction Layer	AgentCore Payments	Enables the agent to act economically — pay, receive, and record transactions safely.	AWS AgentCore — identity‑bound wallets, spending guardrails, observability.
Interface Layer	Interaction Surfaces	Defines how agents and services communicate — the “face” of Business‑to‑AI.	Cloudflare bot‑friendly APIs, Google Search as early machine‑facing surface.

Why B2AI is a Top-Line Priority

Smashing the “Efficiency Wall”

The legacy corporate tech stack was explicitly engineered to keep automated agents out. Forbes calls this structural bottleneck the Efficiency Wall : “The ceiling has always been the person at the keyboard.” Traditional operational systems relied entirely on human limitations—a person had to manually approve invoices, sign wires, and click submit.

This created a structural barrier where scaling corporate operations required scaling human headcount. B2AI entirely removes this barrier. Software agents scale like cloud compute, not like employee payroll.

Corporate Capital is Moving Rapidly

Enterprise leaders are no longer just looking at AI as a tool for efficiency; they are reallocating real budgets toward agentic execution:

25% of enterprises will deploy functional AI agents in 2025, spiking to 50% by 2027.
44% of corporate finance teams expect to actively use agentic AI by 2026.
56% of leadership teams plan to expand their AI investment capital by at least 10%.

The High Price of Financial Inaction

Forbes makes the case directly: the next billion-dollar fintech category is being built for the agentic era. In an industry where digital payments account for hundreds of billions of dollars, agentic commerce is the newest expansion vector. Traditional financial services and enterprises that fail to adapt their corporate architecture risk losing an estimated $170 billion in cumulative profit over the next decade. Conversely, early market adopters can capture a four percentage point increase in net returns.

What Matters to a Business in the Business to AI Era

When the customer becomes a machine, the core fundamentals of product, marketing, and corporate strategy are rewritten from scratch:

Product Context: Machine-Understandable Inventories AI agents select products based on structured metadata, policy constraints, compatibility, and strict performance metrics. If your product, catalog, or service cannot be flawlessly parsed by software, your company will simply never be selected.
Marketing Strategy: Data Over Emotion Traditional marketing relies on storytelling, visual branding, and emotional hooks. In a B2AI world, marketing transforms into data engineering driven entirely by highly structured data feeds, verifiable trust signals, and real-time performance metrics.
Customer Loyalty: Cryptographic Reputation AI agents are entirely stateless and impervious to brand affinity or catchy logos. True customer retention shifts toward immutable contracts, seamless API integrations, operational reliability, and cryptographic reputation scores.
Customer Accountability: Programmable Mandates Who is accountable when an automated agent commits capital? Enterprise security requires that accountability must be hardcoded into the workflow via spending limits, programmable mandates, complete audit trails, and instant revocation rights.

The Two-Sided B2AI Operating Model

To successfully navigate this landscape, your enterprise must architect for a dual-sided marketplace:

Side	Description	What It Means
Side1	Inbound Sales	Your AI agent sells to their AI buying agent. The buyer is software, not a human.
Side2	Outbound Action	Your company manages the agents acting on your behalf. These agents execute tasks, decisions, and transactions.

The Inbound Side : Your enterprise system must expose machine-readable catalogs, negotiate automatically within strict policy bounds, and natively integrate with agent payment rails. This is a challenge of protocol design, not human marketing.
The Outbound Side : Your business must maintain ironclad control over the software agents acting on your behalf. This requires deploying secure identity issuance, setting strict spending guardrails, and enforcing exception approval workflows.

Just as your enterprise once required an Identity Management System for employees, your organization now requires a comprehensive Agent Management System.

Conclusion: The Next Platform Shift

Every time the interaction surface moves, the entire flow of global commerce and capital moves with it. The modern interaction layer is no longer a human screen; it is an active API.

The companies that win the next decade will be those that expose clear AI-facing surfaces, issue secure identities to software, and treat agents as first-class economic actors. Enterprise leaders still designing exclusively for human-to-human transactions will spend the coming years explaining why their architecture targeted the wrong end of the transaction.

The post The New Customer Is Not Human: Business-to-AI (B2AI) appeared first on Behind the Build.

Private, Sovereign Agents in Your Pocket: The Rise of USB-Deployed Local LLMs with AWS Strands

Jonathan Wong — Wed, 20 May 2026 01:30:23 +0000

Artificial intelligence is undergoing a massive architectural shift. While cloud-hosted API models dominated the initial wave of enterprise AI adoption, a combination of rising cloud costs, shifting privacy regulations, and advancements in open-weight models has catalyzed an alternative movement: fully localized, portable AI agents.

Deploying an autonomous AI agent locally, or even storing it completely on a bootable or portable USB drive, is no longer a tech enthusiast’s hobby. It is a highly practical architecture for modern data analysts and security-conscious enterprises.

The Strong Case for Local LLMs

For a long time, the convenience of API endpoints overshadowed local execution. However, major shifts in economics, security, and model capability have flipped the script.

SaaS Price Plan Volatility: Major cloud AI providers continuously adjust their commercial enterprise tiers. Many organizations have faced unexpected price plan changes, making high-volume document processing and continuous data ingestion prohibitively expensive on a per-token model. Local deployment offers predictable infrastructure costs where you pay for the hardware once, and your marginal token cost is zero.
Privacy and Supply Chain Attacks: Sending sensitive data like financial records, internal roadmaps, or intellectual property to a third-party cloud endpoint exposes corporations to data leaks and severe downstream supply chain vulnerabilities. Operating completely locally guarantees that data never leaves your infrastructure boundaries.
Bypassing Regional Blocks and Geo-Restrictions: Cloud AI APIs are often restricted, gated, or altogether blocked in specific countries or corporate network zones due to geopolitical compliance and local regulations. Running a model locally bypasses all geographic restrictions entirely, ensuring your AI tools remain completely accessible anywhere in the world regardless of regional IP filtering.
Modular Freedom and Custom Mixing: Cloud APIs lock you into a single provider’s walled garden and specific model versions. Local execution allows you to swap out your underlying model file instantly, test fine-tuned variants, or even mix entirely different model architectures (like using a coding model for data synthesis and a conversational model for summaries) tailored exactly to different use cases.
The Capabilities of Open-Weight Models: Models like Alibaba’s Qwen family have evolved dramatically. Middle-tier open models ranging from 7B to 14B parameters can execute highly complex tasks, follow structured JSON formats perfectly, and write accurate analytics code out of the box.
True Offline Autonomy: Local models function completely disconnected from the open web. For remote field research, high-security air-gapped networks, or maritime operations, local LLMs provide uninterrupted operational continuity.

Why Portable USB Deployment?

Portability bridges the gap between local power and accessibility. Storing your local LLM engine, tools, and orchestration dependencies on a fast, external USB drive unlocks distinct advantages.

Cross-Environment Agility: A portable USB allows an analyst or developer to plug their entire AI environment into a secure workstation, a home desktop, or a field laptop without tedious, repetitive software installation loops.
Zero-Footprint Auditing: When combined with secure or sandboxed container environments, a USB setup can run operations purely in temporary memory space. Once unplugged, no trace of the underlying processed data is left behind on the host operating system.

How a USB‑Based LLM Uses the Host GPU

A common point of confusion is how a software stack running off an external drive handles heavy computational matrix math. A USB-based LLM does not rely on the USB drive itself to crunch numbers. Instead, it utilizes standard local inferencing engines to negotiate access with the host machine’s hardware.

Driver Interfacing: When plugged in, the local inference engine queries the host machine’s operating system via standard APIs such as NVIDIA CUDA for GeForce/RTX cards, Apple Metal for Mac Silicon, or ROCm for AMD.
VRAM Allocation: The engine reads the quantized model file straight from the USB drive and directly loads those weights into the host machine’s high-speed Graphics Video RAM.
Execution: Once loaded into the host GPU’s memory, the intense mathematical operations happen locally at massive parallel speeds. The USB drive is only used for initial loading and logging output.

Setting Up the Local LLM Server

To enable the portable USB environment to utilize the host computer’s computing power, both the host hardware and your USB software engine must align correctly.

Host Computer Requirements

GPU Drivers: The host machine must have appropriate graphics drivers installed. This means NVIDIA CUDA for Windows/Linux workstations, AMD ROCm or Vulkan for AMD setups, Intel OneAPI or Vulkan for Intel discrete graphics, and Apple Metal (built-in natively) for macOS devices.
GPU Acceleration Runtime: The local backend software must explicitly support hardware offloading. In this architecture, we use a portable build of llama.cpp.
VRAM Capacity: The chosen LLM must fit within the host machine’s available Video RAM. Heavy weights must be quantized (compressed) to prevent memory overflows.

What Happens in Practice

High-End Workstation (e.g., RTX 4090): Plugging your USB into a dedicated workstation loads the model entirely into ultra-fast VRAM, yielding extreme inference speeds ranging from 50 to 120 tokens per second.
Standard Work Laptop (No Discrete GPU): If plugged into a machine lacking a dedicated graphics card, the llama framework automatically falls back to CPU execution. The agent still works completely offline, though at a noticeably slower computational speed.
Apple Silicon MacBook (M-Series): Plugging the drive into a Mac leverages Apple’s unified memory architecture via Metal, resulting in fast, efficient acceleration without needing a massive desktop GPU.

Llama Portable Server Example Setup

To make the entire system completely self-contained on your USB drive, follow this structural organization:

Download the Server Binary: Visit the official ggerganov/llama.cpp releases page on GitHub. Download the pre-compiled portable zip file matching your host operating system (such as the split zip containing llama-server.exe with CUDA or AVX support for Windows). Extract these files directly onto a folder on your USB drive.
Download the Model File: Navigate to Hugging Face and search for the Qwen repository containing GGUF formats. Download a balanced, quantized model file such as qwen2.5-7b-instruct-q3_k_m.gguf. This specific format offers low memory usage while maintaining high reasoning accuracy.
Establish the Portable Folder Structure: Organize your files on the USB drive exactly like this to keep paths clean:

[USB Drive Root]
└── llama_portable/
    ├── bin/
    │   ├── llama-server.exe
    │   └── (other runtime dll/binary files)
    └── models/
        └── qwen2.5-7b-instruct-q3_k_m.gguf

Launch the Engine: Open your terminal, navigate into your bin folder, and execute the following unified initialization command:
llama-server.exe –model ..\models\qwen2.5-7b-instruct-q3_k_m.gguf –ctx-size 8192 –gpu-layers 22 –threads 8 –temp 0.7 –port 8080 –log-disable
- –model: Tells the server exactly where to find your stored Qwen GGUF file.
- –ctx-size 8192: Expands the memory window to 8,192 tokens, allowing the agent to read larger Excel spreadsheets.
- –gpu-layers 22: Offloads 22 layers of the neural network directly into the host machine’s GPU VRAM. Adjust this number up or down depending on how much memory the host GPU possesses.
- –threads 8: Allocates 8 CPU cores to handle processing tasks if VRAM spills over.
- –temp 0.7: Stabilizes the model’s creativity for consistent data analysis formatting.
- –port 8080: Locks the local endpoint port to 8080, matching the target address used by our AI framework.
- –log-disable: Disables messy debugging text in the terminal window to keep the screen clean.

How AWS’s AI Strands Framework Can Run Natively Locally

Amazon Web Services developed Strands, an elegant, open-source, code-first AI agent framework designed to simplify complex tool orchestration. While built by AWS, Strands is completely model-agnostic and runs beautifully in 100% offline environments.

Instead of routing traffic to the cloud-hosted Amazon Bedrock API, Strands allows developers to instantiate a model class and intentionally override its endpoint URL. By pointing this parameter to your local port where your local Llama.cpp or Ollama server is running, Strands treats your local Qwen model exactly like a cloud endpoint. It automatically reads function schemas, handles single-query tool selection, and executes python actions locally without a single byte ever reaching the internet.

A Practical Excel‑Analysis Example

Consider a scenario where a financial auditor needs to process an asset ledger. Rather than sending this sensitive data up to a cloud model, they plug in their USB drive.

The user asks: “What is the mean average of our Revenue column?”

Using Strands, the system maps this flow internally using exactly one query turn.

The user asks the question.
Strands passes the available tool descriptions to the local Qwen model.
Qwen recognizes it needs to compute numerical fields, auto-selects the math tool, and extracts the target column parameter alongside the metric tool configuration.
The local Python backend triggers a native pandas function against the local Excel file and returns the direct numeric calculation back to the screen instantly.

A High‑Level Implementation Guide

Building this system on your portable drive requires organizing your project code structurally into separate tool definitions and agent initialization routines.

File 1: The Analytical Tools (ExcelAnalyzer.py)

This file houses the native Python code that will run locally on the host machine. We register these functions to the framework using Strands’ native tool decorator.

# ExcelAnalyzer.py  

import pandas as pd
from strands import tool

@tool
def get_excel_metadata(file_path: str) -> str:
    """
    Use this tool to extract layout structural layout details about an Excel file.
    Returns available column headers, sheet shapes, and total row count.
    """
    # your logic  

@tool
def calculate_column_math(file_path: str, column_name: str, metric: str) -> str:
    """
    Use this tool to calculate analytical metrics on a single target numerical column.
    Supported metrics: 'mean' (average), 'sum' (total), 'max' (highest), 'min' (lowest).
    """
    # your logic

File 2: The Main Agent Execution Engine (agent.py)

This script loads the tools from your custom analyzer module, configures the local Llama framework bypass, and executes inquiries.

# agent.py  

import os
from strands import Agent
from strands.models import BedrockModel

# Bind the standalone functions from your local file
from ExcelAnalyzer import get_excel_metadata, calculate_column_math

# Redirect the AWS SDK interface down to your local port 8080 Llama server
# Dummy keys are passed simply to pass AWS SDK internal initialization checks
local_qwen_model = BedrockModel(
    modelId="qwen",
    endpoint_url="http://localhost:8080/v1",
    region_name="us-east-1",
    aws_access_key_id="mock_key",
    aws_secret_access_key="mock_secret"
)

# Instantiate the Agent with direct object reference mapping
agent = Agent(
    model=local_qwen_model,
    tools=[get_excel_metadata, calculate_column_math],
    system_prompt="""You are a sovereign Local Data Analyst Agent.
    You have direct access to automated python tools to analyze spreadsheet files.
    Auto-select the most specific tool available to satisfy user requests.
    If the question is standard conversational knowledge, reply without tools."""
)

if __name__ == "__main__":
    target_sheet = "sales_data.xlsx"
    
    # your logic

Key Takeaways

Data Sovereignty is Non-Negotiable: Moving your AI logic locally eliminates vulnerability to downstream data supply chain leaks and isolates operational data inside private boundaries.
AWS Strands is Not Locked to the Cloud: The framework provides an exceptionally lightweight syntax for localized python workflows simply by mapping standard endpoint parameters to localhost servers.
USB Provisioning Delivers High Mobility: Bundling open models like Qwen alongside an execution environment on plug-and-play storage allows technical professionals to instantly adapt to varying compute resources while leveraging the host computer’s heavy GPU power safely.

What’s Next

Decoupling your enterprise artificial intelligence architecture from third-party cloud data pipes is the ultimate strategy for achieving true data security, cost predictability, and zero geopolitical restriction friction. By containerizing a lightweight local inference engine like llama.cpp and pairing it with a professional, tool-agnostic framework like AWS Strands on an external drive, you create an entire sovereign data laboratory that functions completely air-gapped on any host workstation you target.

This architectural overview outlines the theoretical foundational pillars, resource allocations, and file structures required to launch your localized asset parser. In the next article, we will dive deep into a complete, end-to-end AI agent implementation guide. We will walk through the granular production code line-by-line, implement custom multi-sheet data cross-referencing capabilities, and detail a complete code-level description to finalize your private AI workspace.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post Private, Sovereign Agents in Your Pocket: The Rise of USB-Deployed Local LLMs with AWS Strands appeared first on Behind the Build.

Security Meets Reality: The Great Firewall

Jonathan Wong — Mon, 18 May 2026 01:00:29 +0000

The Great Wall protected the country for hundreds of years, and it remains one of the few human creations visible from space with the naked eye. In the digital world, its virtual counterpart continues that same idea of protection, shaping how information flows and what can pass through.

Our client expanded their business into mainland China, where their applications need to load images and documents stored in Amazon S3. However, the default S3 endpoint quickly became a bottleneck, with unstable connectivity and unpredictable latency inside the region. Latency spikes, packet loss, or outright blocking can break the user experience. Yet the company domain is already approved through internal compliance procedures, meaning traffic routed through that domain is stable and trusted.

This creates a simple but important requirement:

Serve S3 files through the company domain without changing the app and without exposing the S3 bucket publicly.

Background

The API server must support mobile and web clients operating inside mainland China. Direct access to:

https://<bucket>.s3.ap-east-1.amazonaws.com/...

is unreliable. Even when it works, the latency is unpredictable.

However:

The company domain is already approved
Traffic to this domain is stable
The API layer can enforce authentication and security checks

So instead of exposing S3 directly, the API domain becomes the gateway.

Solution Options Considered

To solve the problem of unstable S3 access from mainland China while keeping the company domain approved and trusted, three architectural options were evaluated:

Cloudflare
CloudFront
NGINX Reverse Proxy

Each option solves part of the problem, but only one satisfies all requirements with minimal change and cost.

Option One: Cloudflare

Cloudflare already sits in front of the API domain, providing:

TLS termination
Global routing
Edge caching
DDoS protection
China friendly stability

Cloudflare can proxy requests to S3, but it cannot :

Access private S3 using IAM roles
Perform backend business logic checks
Enforce per request authorization
Keep traffic inside AWS backbone
Read private S3 objects without presigned URLs

Cloudflare Workers can add logic, but they introduce:

New code
New runtime
No IAM role support
No VPC endpoint support

Cloudflare is excellent for public static files, but insufficient for private S3 access with custom security checks.

Option Two: CloudFront

CloudFront is AWS’s CDN and can:

Map your company domain
Cache S3 content
Use Origin Access Control to secure S3
Improve global routing

However, CloudFront cannot natively perform cookie based authorization.

To check cookies, CloudFront requires:

CloudFront Functions (very limited)
Lambda@Edge (powerful but complex)

CloudFront also cannot:

Use IAM roles to read private S3
Access VPC endpoints
Run your existing backend logic
Guarantee optimal China performance

This makes CloudFront significantly complex, and doesn’t support IAM roles for least privilege.

Why CloudFront Cannot Assume an AWS IAM Role

CloudFront cannot assume an AWS IAM role because it is not a compute service. Only compute services such as EC2, Lambda, ECS, and EKS can call STS to assume roles and obtain temporary credentials. CloudFront has no execution environment, no credential provider, and no ability to sign AWS API requests using IAM role credentials.

Instead, CloudFront uses Origin Access Control (OAC), which is a fixed CloudFront service identity, not an IAM role. OAC can only sign requests to S3 and cannot access other AWS services, cannot run business logic, and cannot integrate with VPC endpoints.

Because CloudFront cannot assume IAM roles, it cannot:

Use IAM role permissions to read private S3
Access S3 through your VPC endpoint
Perform authenticated backend logic
Enforce per user authorization

This limitation is one of the key reasons CloudFront cannot replace an EC2 based NGINX proxy.

Option Three: NGINX Reverse Proxy

NGINX running on EC2 inside AWS provides:

Full control of request logic
Cookie based authentication
Business rule checks
IAM role access to private S3
VPC endpoint routing
Zero client side changes
Zero new AWS services
Minimal cost

NGINX can:

Serve public files directly
Serve private files only after validating cookies
Access S3 privately through AWS backbone
Enforce least privilege IAM policies
Keep all traffic internal to AWS

This satisfies all requirements:

minimal change
minimal cost
least complexity

NGINX becomes the most cost effective and least disruptive solution.

How the NGINX Proxy Works

1. Path Locations for Public and Private Buckets

NGINX exposes two categories of paths:

/app/upload/public/...  
/app/upload/private/...

Public files proxy directly.

Private files require cookie checks or business logic before proxying.

2. Proxy Mapping to S3

NGINX rewrites the incoming path and forwards it to the correct S3 bucket endpoint.

location /app/upload/public/ {
    proxy_pass https://your-public-bucket.s3.ap-east-1.amazonaws.com;
    proxy_set_header Host your-public-bucket.s3.ap-east-1.amazonaws.com;
}  

location /app/upload/private/ {  

    if (your-checking) { return 403; }

    # Remove /app from the path
    rewrite ^/app/(.*)$ /$1 break;

    # S3 bucket
    proxy_pass https://your-private-bucket.s3.ap-east-1.amazonaws.com;

    # Required for S3
    proxy_set_header Host your-private-bucket.s3.ap-east-1.amazonaws.com;
}

3. IAM Role for the NGINX Host

The EC2 instance running NGINX is granted an IAM role with only the required S3 read permissions.

{
    "Sid": "AllowObjectReadWritePublic",
    "Effect": "Allow",
    "Action": [
    "s3:GetObject",
    "s3:PutObject"
    ],
    "Resource": "arn:aws:s3:::your-private-bucket/*",
    "Condition": {
    "StringEquals": {
        "aws:RequestedRegion": "ap-east-1"
    }
    }
}

4. VPC Endpoint for S3

A Gateway VPC Endpoint ensures all S3 traffic stays inside AWS backbone, improving stability and security:

Ensure you are in the correct AWS Region
Open VPC Console : Navigate to the VPC Dashboard in your AWS Management Console.
Create Endpoint : Click Endpoints in the left sidebar, then click Create endpoint.
Service Category : Select AWS services.
Service Name : Search for s3 and select the Gateway type (e.g., com.amazonaws.ap-east-1.s3).
VPC Selection : Choose the specific VPC where your private resources live.
Route Tables : Select the Route Tables associated with your private subnets to automatically inject the S3 route.
Policy : Leave it as Full Access for standard setups, or attach a custom IAM policy to restrict bucket access.
Finish : Click Create endpoint

The vpc policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "nginx2S3ReadOnly",
            "Effect": "Allow",
            "Principal": "*",  
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::your-private-bucket",
                "arn:aws:s3:::your-private-bucket/*"
            ],
            "Condition": {
                "ArnEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::your-aws-id:role/ec2-production"
                }
            }
        }
    ]
}

Results

1. All S3 Files Accessible Through the Company Domain

The app continues using the same URL pattern with no changes.

2. Private Bucket Security Without Presigned URLs

NGINX performs the authentication and authorization checks.

3. All File Transfers Stay Inside AWS Backbone

The VPC endpoint ensures no public internet routing.

Comparison Table

Option	Strengths	Limitations	Best For
Cloudflare	Stable global routing, China friendly, SSL handled, caching, DDoS protection	Cannot access private S3 via IAM, cannot run backend logic, cannot keep traffic inside AWS backbone	Public static files, global CDN
CloudFront	AWS native CDN, OAC for S3, caching, custom domain	Cannot assume IAM roles, cookie checks require Lambda@Edge, no VPC endpoint routing, more cost and complexity	Public S3 distribution with CDN caching
NGINX Reverse Proxy	IAM role access, VPC endpoint routing, custom security checks, simple logic, no client changes	No global CDN, relies on Cloudflare for edge routing	Mixed public and private S3 access with business logic

Key Takeaways

NGINX is the only option that supports IAM role access , which is essential for secure private S3 reads without presigned URLs.
CloudFront cannot assume IAM roles , making it unsuitable for private S3 access with backend logic.
Cloudflare provides global routing and SSL , but cannot enforce your business logic or access S3 privately.
VPC endpoints keep all S3 traffic inside AWS , improving stability for mainland China and eliminating public internet exposure.
This architecture requires minimal changes to the application , making it ideal for production systems that cannot afford disruption.
NGINX plus Cloudflare gives you the best of both worlds: global routing at the edge and secure, controlled access inside AWS.

The post Security Meets Reality: The Great Firewall appeared first on Behind the Build.

Not Every Magic Wand Works for Every Company: Cloudflare, AI Restructuring, and the Elder Wand Problem

Jonathan Wong — Sat, 16 May 2026 04:27:35 +0000

When Cloudflare announced strong quarterly results, few expected what came next:

a 25 percent stock drop in a single day.

Revenue was up.

Margins were up.

Customer count was up.

And yet the market reacted as if something had gone terribly wrong.

The reason wasn’t the numbers.

It was the story.

Cloudflare positioned its restructuring as an AI‑first transformation :

1,100 roles removed
internal AI usage up 600 percent
AI agents deployed across engineering, finance, HR, and GTM
a new “agentic operating model”

The intention was clear:

AI would make Cloudflare faster, leaner, and more scalable.

But the market didn’t buy it.

The Elder Wand Problem

In Harry Potter, the Elder Wand is described as the most powerful wand ever created. It is a gift from Death.

But the wizard who believes it is a universal solution is usually the one who dies first.

Why?

Because the wand is powerful, but context‑dependent.

It obeys rules the wizard doesn’t fully understand.

It backfires when used blindly.

And it punishes those who mistake power for inevitability.

Cloudflare’s AI restructuring followed the same pattern.

AI is powerful.

AI is transformative.

AI can reshape workflows.

But AI is not a universal wand , and treating it like one can be dangerous, especially for a mid‑cap tech company with:

slowing enterprise sales
high valuation
execution risk
no AI‑product revenue engine

Cloudflare tried to wield AI like the Elder Wand.

The market reacted like the wand had backfired.

What the ISACA Vancouver Speakers Revealed and Why It Matters

At the ISACA Vancouver event, speakers from both multinational corporations and local SMEs said the same thing:

*“We are adopting AI in our work, but we are not restructuring our companies because of it. That is too risky restructuring teams too quickly around AI can create instability and unclear ownership” *

They were clear:

AI is a tool, not a new org chart
AI improves workflows, not reporting lines
AI accelerates teams, but doesn’t replace them
AI adoption should be incremental, not structural
AI should reduce friction, not create uncertainty

This is exactly the opposite of Cloudflare’s approach.

Cloudflare didn’t just adopt AI.

It reorganized the company around AI.

For MNCs and SMEs, this is the line they refuse to cross.

Because they know:

AI is still evolving
AI reliability varies by domain
AI governance is immature
AI introduces new risks
AI requires human oversight
AI is not a stable foundation for org design

In other words:

AI is powerful, but not stable enough to restructure your company around it.

The ISACA speakers understood this.

Investors understood this.

Cloudflare underestimated this.

Why the Market Punished Cloudflare

Cloudflare’s stock didn’t fall because of AI.

It fell because of misalignment :

AI efficiency ≠ AI revenue
AI restructuring ≠ AI growth
AI agents ≠ enterprise sales
AI adoption ≠ investor confidence

And here is the part you wanted added — the core investor logic:

Investors want AI to generate new revenue, not justify cost‑cutting.

Wall Street rewards companies that use AI to:

create new products
open new markets
expand customer value
increase consumption
grow top‑line revenue

Microsoft, Google, Meta, and even AWS get rewarded because their AI stories are revenue stories.

Cloudflare’s AI story was an efficiency story.

Investors don’t pay a premium for efficiency.

They pay a premium for growth.

Cloudflare tried to tell a story of acceleration.

Investors heard a story of instability.

Cloudflare tried to show strength.

Investors saw execution risk.

Cloudflare tried to use AI as a magic wand.

Investors saw the Elder Wand.

What Actually Matters for Your Business

The lesson is simple:

AI is not a universal solution.
AI is not an org chart.
AI is a tool. Powerful, but context‑dependent.

What matters is:

Revenue clarity
Customer value
Operational stability
Team alignment
Sustainable execution
Incremental adoption
Clear governance
AI that grows revenue, not just cuts cost

AI should enhance your business, not redefine it overnight.

The companies at ISACA Vancouver event understood this.

The market understood this.

Cloudflare learned it the hard way.

Because in business, as in the Deathly Hallows, the most powerful wand can be the most dangerous when misunderstood.

The post Not Every Magic Wand Works for Every Company: Cloudflare, AI Restructuring, and the Elder Wand Problem appeared first on Behind the Build.

When Invisible Tasks Break Projects: A story of chaos, security, and the power of a shared language

Jonathan Wong — Thu, 14 May 2026 00:52:45 +0000

It was the project where I turned an original six‑month engineering estimate into a ten‑week delivery.

The project did not collapse in one dramatic moment. It unravelled quietly, through a thousand tiny misunderstandings.

Every day the workflow felt more chaotic. Product features were told verbally to individual engineers. Requirements lived in scattered chats, calls, and assumptions. No one had the full picture. Everyone was busy, yet progress felt strangely unpredictable.

More meetings were added to fix the communication problem.

But more meetings only made things worse.

The real issue was not the number of meetings.

The real issue was that the teams did not share a common language.

The Invisible Task That Triggered Everything

Security was the perfect example of this invisible problem.

The product team knew security mattered, but they were not sure whether the timeline was worth it.

The engineering team followed best practices, but they could not explain the business reasons behind the work.

Security tasks were invisible.

You could not see progress.

You could not demo them.

You could not screenshot them.

And because they were invisible, they created more inquiries, more conflicts, and less teamwork.

Information broke apart. Communication channels fractured.

Everyone was working, but no one was aligned.

The workflow became a textbook communication breakdown: ineffective communication channels, uncontrolled scope change, and requirements shifting informally from one conversation to the next.

The result was predictable:

Fragmented workflow
No shared understanding
Unexpected output
Not the product the business expected

When communication is fragmented and requirements are unclear, teams fall into a repeating cycle of rework. A well‑known failure pattern in project delivery.

The team fell into a classic rework loop.

A classic communication failure

The Turning Point

Introducing a common language

The breakthrough came when I stopped trying to fix communication with more meetings and instead aligned on a shared language. Security became the anchor.

I introduced the classic CIA triad as the foundation for understanding why security tasks exist.

Confidentiality
Integrity
Availability

Suddenly, security was no longer a mysterious engineering ritual.

It became a business concept with clear meaning and impact.

But the real clarity came when I explained where security tasks actually come from.

The Four Layers Behind Every Security Task

Why these tasks exist long before a developer writes a single line of code

Security work does not appear randomly.

It flows through a predictable chain:

Law → Standard → Company Policy → Procedure

Once the business team understood this chain, the invisible became visible.

Law

The highest level of obligation

Laws define what must be protected. In the United States, examples include:

HIPAA for healthcare
GLBA for financial institutions
SOX for public companies
State privacy laws like CCPA

Laws do not tell engineers how to build systems.

They simply say: “You must protect this data.”

Standard

Industry expectations that translate law into practice

Examples:

ISO 27001
SOC 2
PCI DSS

Standards define what “good security” looks like.

They turn legal obligations into auditable expectations.

Company Policy :

Leadership’s commitment to the rules

Policies translate standards into internal rules:

All production systems must use multi factor authentication
All customer data must be encrypted
All access must follow least privilege

Policies define what the company promises to do.

Procedure

Where engineers turn policy into tasks

Procedures are the step‑by‑step instructions:

How to configure MFA
How to implement micro segmentation
How to set up audit logging

This is where invisible tasks live.

These were non‑functional requirements, essential, but invisible to stakeholders, and therefore constantly underestimated.

A developer sees “Implement MFA” or “Break price query into server → proxy → database,” but behind each task is the full chain:

Procedure ← Policy ← Standard ← Law

Once the business team saw this, the task was no longer invisible.

It became logical, necessary, and aligned with business value.

Case 1: More rights and more impact require more audit

I explained it through real life.

One factor authentication: password for your personal email
Two factor authentication: staff password and one-time device token for company restricted documents
Three factor authentication: passport, token, and face photo at the airport

The business team initially felt this was bad user experience and extra development time.

But once they understood the principle: more rights and more impact require more audit. The conversation changed.

Security was no longer a blocker.

It became a business safeguard.

Case 2: Micro segmentation and least privilege

I explained why a simple price query required three components: server, proxy, and database.

The business team asked why we could not just query directly to save time and improve speed.

Because micro segmentation protects the system.

Because least privilege prevents lateral movement.

Because shortcuts today become vulnerabilities tomorrow.

Once the business team understood this, they saw the business value behind the architecture.

The Result

Alignment, clarity, and teamwork

With a shared language, everything changed.

Fewer inquiries
Fewer conflicts
More teamwork
Less fragmentation
More predictable delivery

Security tasks were no longer invisible.

They were understood, valued, and properly planned.

We documented everything in a Confluence space. This became our knowledge management system, the structured way to reduce fragmentation and prevent repeated misunderstandings.

Teams added comments, shared insights, and reduced knowledge conflicts.

Security tasks were linked to business concepts, not just technical checklists.

Only after this alignment did meetings become productive.

Because now everyone spoke the same language.

Key Takeaways

Invisible tasks do not break projects. Misunderstood tasks do.
When teams lack a shared mental model, even simple work becomes chaotic.
When teams align on concepts, even complex work becomes manageable.

Security was just the example.

The real solution was alignment.

And once we aligned, the project finally moved forward with clarity and confidence.

What’s Next

This article showed how invisible tasks, especially security work, can quietly break a project when communication is fragmented and teams do not share a common language. Once we aligned on a shared mental model, the chaos settled, the rework loop stopped, and the workflow finally became predictable again.

In the next part of this series, I will continue the story by walking through this real project from my past experience. I will explain how standup meetings, a well designed Confluence space, and a disciplined Jira workflow worked together to solve the same communication problems described here. It will be a practical continuation of this journey, showing how alignment, documentation, and predictable processes turned a fragmented project into a high performing delivery engine.

The post When Invisible Tasks Break Projects: A story of chaos, security, and the power of a shared language appeared first on Behind the Build.

DEV Community: Jonathan Wong

Autonomous Tool Orchestration & Multi-Capability Agent Systems with Amazon Bedrock AgentCore & Strands SDK

Architectural Blueprint & Component Synergies

Deep Dive: Implementation Highlights

Setup Guide: Configuring the AWS Components

AgentCore Gateway & Model Context Protocol (MCP)

How Real-Time Dynamic Tool Discovery Works

Step-by-Step Setup

Putting Configs Together

Lifecycle Deployment Flow: Config -> Build -> Deploy -> Test

1. Configure Runtime

Parameter Breakdown

Anatomy & Impact of the Generated .bedrock_agentcore.yaml File

2. Deployment

Deployment Mechanics & Runtime Initialization

3. Configure IAM Permissions

4. Integration Testing & Real-World Validation

Business Value & Engineering Takeaways

Advanced Architecture Extension: Production Integration & Runtime Trade-Offs

Production Integration: Invoking AgentCore from a FastAPI Backend

Architectural Decision: Why Bedrock AgentCore Runtime over AWS Lambda?

What’s Next

Prompt-Driven Routing & Managed Agent Architecture with Amazon Bedrock AgentCore

1. Architectural Overview & System Flow

Core Architectural Components

High-Level End-to-End Workflow

2. Infrastructure Sanity Check: Testing Lambda & DynamoDB

Lambda Test Event Payload

Verification via DynamoDB Console

3. Core Mission: Prompt-Driven System Routing (system_prompt.txt)

Key Design Highlights of the System Prompt:

4. Constructing the Test Harness (harness-tests.json)

5. Automated Evaluation via Amazon Bedrock Evaluations

AWS CLI Evaluation Job Command Breakdown

Analyzing Results in the Console

Key Takeaways for Tech Leaders

Foundations & Rapid Prototyping: Inside the AWS AI Practitioner Challenge

Step 1: The Challenge Phase & AWS AI Practitioner Learning Plan

Step 2: From Theory to Application with AWS PartyRock

Crossing the Threshold: Into the Nanodegree

What’s Next in the Series?

Engineering Next-Gen AI Agents: Reflections on the Future AWS Agent Engineer Nanodegree

Level Up Your AI Skills with Microsoft AI Skills Fest 2026: Ends June 12!

Pre-AI Lessons in the AI Era: Why Hard Work Breaks Projects Without Transparency

The Human Dysfunction: Hard Work Without Transparency

Blindness, Communication Debt, and Lone-Wolf Isolation

The Turning Point

The Results

The AI Era: Scaling the Hardest-Working Teammate

What It Means for Your Business

Key Takeaways

Conclusion

What’s Next

The AI Revenue Illusion: Fixing Maturity Errors to Prepare for the B2AI Future

The Real-World Business Maturity Model

AI Usefulness & Capabilities

Automation vs. AI in the Real World

Modern AI Tools Supporting Daily Workflows

Tool Alignment Across the Business Maturity Spectrum

AI Must Add Revenue Value, Not Just Cut Costs

The Strategic Shift: From AI Ready to Agent Ready

Key Takeaways

The New Customer Is Not Human: Business-to-AI (B2AI)

Why Business-to-AI (B2AI) is Your Company’s Next Essential Commercial Channel

The Third Commercial Channel

The Business to AI Stack

Why B2AI is a Top-Line Priority

What Matters to a Business in the Business to AI Era

The Two-Sided B2AI Operating Model

Conclusion: The Next Platform Shift

Private, Sovereign Agents in Your Pocket: The Rise of USB-Deployed Local LLMs with AWS Strands

The Strong Case for Local LLMs

Why Portable USB Deployment?

How a USB‑Based LLM Uses the Host GPU

How AWS’s AI Strands Framework Can Run Natively Locally

Key Takeaways

What’s Next

Security Meets Reality: The Great Firewall

Background

Solution Options Considered

Anatomy & Impact of the Generated `.bedrock_agentcore.yaml` File

3. Core Mission: Prompt-Driven System Routing (`system_prompt.txt`)

4. Constructing the Test Harness (`harness-tests.json`)