DEV Community: Jonathan Wong

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.

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 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.

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 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.

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 When Invisible Tasks Break Projects: A story of chaos, security, and the power of a shared language appeared first on Behind the Build.

From Machine Learning to Production: A Practical Walkthrough Using My Vancouver Traffic Accident Risk Predictor

Jonathan Wong — Mon, 11 May 2026 22:21:41 +0000

Artificial intelligence has many branches, but in real projects the most important question is simple: what tool solves the problem with the least complexity and the highest reliability.

This article walks through that question using my GitHub project, Vancouver Traffic Accident Risk Predictor, as a real example. Along the way, it explains when to use machine learning (ML) instead of large language models, how an ML pipeline works, what MLOps means, and how a model becomes a production ready service.

The Modern Habit of Using LLMs for Everything

There is a new pattern in the industry. Whenever a team faces a data problem, someone eventually says, “Why not just use an LLM for this?”

It sounds modern. It sounds powerful. It feels like a universal solution.

But this instinct hides a deeper issue.

LLMs are not designed for structured data prediction.

They can reason across messy text, generate explanations, and handle unstructured inputs. They are excellent at language. But when the task is numerical, statistical, or based on clean tabular data, an LLM behaves like a very smart person guessing instead of a model trained precisely for the job.

This is where the Vancouver project becomes a perfect example.

The goal is to predict accident risk based on weather and traffic conditions.

This is not a language problem.

This is a structured prediction problem.

This is exactly where classical ML shines.

Why Business Users Often Think LLMs Can Solve Everything

This misconception is extremely common, and it is not the fault of business users.

It comes from the experience of interacting with LLMs, not from their underlying capabilities.

LLMs feel magical

A business user types a question.

Claude answers instantly.

It sounds smart.

It sounds confident.

It sounds like it understands the business context.

From their perspective, this feels like general intelligence.

So the natural conclusion becomes:

“If it can talk about anything, it can probably do anything.”

Industry messaging reinforces the illusion

Marketing language often says things like:

“Analyze your data with AI”
“AI that understands your business”
“AI that learns from your documents”

Business users interpret this literally.

They imagine the LLM training on their data.

In reality, the LLM is only summarizing or sampling it.

LLMs hide complexity

A classical ML pipeline exposes its steps:

Data cleaning
Feature engineering
Model training
Evaluation
Deployment

LLMs hide all of this behind a single prompt.

So business users assume the complexity is gone.

But the complexity is still there — just invisible.

The professional explanation

The most effective way to explain this to business stakeholders is simple:

“Claude is excellent at understanding and generating language.

But price prediction, risk scoring, and forecasting are mathematical problems, not language problems.”

This keeps the conversation respectful, clear, and aligned with business outcomes.

The Reality Check: Is “LLM Everything” Acceptable in Terms of Results and Costs

The short answer is no.

But the reasons matter.

The results problem

LLMs can approximate patterns in structured data, but they cannot match the precision of a model trained directly on the dataset.

Classical ML consistently delivers:

Higher accuracy
Better calibration
More stable predictions
Clearer evaluation metrics

LLMs, by contrast, introduce variability and guesswork.

The cost problem

Even small LLMs are expensive compared to classical ML.

They require more compute, more memory, and often GPU acceleration.

A simple logistic regression or random forest runs on a tiny CPU with millisecond latency and almost zero cost.

An LLM introduces unnecessary overhead.

The engineering problem

LLMs are harder to test, harder to monitor, and harder to guarantee deterministic behavior.

For structured prediction, this is unnecessary complexity.

So is “LLM everything” acceptable?

Only if you do not care about accuracy, cost, latency, interpretability, or operational simplicity.

Real projects always care about these things.

Comparison of ML vs LLM for Structured Prediction

Dimension	Classical Machine Learning	Large Language Models
Accuracy on structured data	High accuracy with stable, well calibrated predictions	Lower accuracy, pattern guessing rather than statistical learning
Latency	Milliseconds on CPU	Tens to hundreds of milliseconds, often requires GPU
Cost per prediction	Extremely low	Significantly higher, especially at scale
Scalability	Scales cheaply on commodity hardware	Scaling requires more compute and higher operational cost
Interpretability	Clear metrics, feature importance, reproducible behavior	Hard to interpret, non deterministic, difficult to validate
Operational complexity	Simple to test, monitor, and deploy	Harder to test, monitor, and guarantee consistent outputs
Best suited for	Risk scoring, forecasting, classification, anomaly detection	Text reasoning, summarization, multi modal understanding
Overall fit for structured prediction	Excellent	Acceptable only with compromises in cost and accuracy

Real World Comparison

Scikit Learn ML vs Claude 4.7 LLM for a 10 GB Price Prediction Dataset

In real enterprise environments, teams often ask whether an LLM can replace a classical ML model for large scale prediction tasks.

So let us take a concrete scenario:

A 10 GB Excel dataset for price prediction.

Which tool performs better?

A well defined scikit learn pipeline wins every time.

Claude 4.7 is slower, less accurate, and dramatically more expensive.

Why ML Wins

When the task is structured prediction on a large dataset, classical ML does not just win — it wins decisively. And the reasons become even clearer when you look at the actual tools used in real projects.

ML can train on the full dataset

A scikit learn pipeline can load and process the entire 10 GB dataset using the Python data stack that enterprises rely on every day:

pandas for ingestion and cleaning
- pandas.read_csv to load large files in chunks
- DataFrame.merge to join datasets
- DataFrame.fillna to handle missing values
numpy for vectorized numerical operations
scikit learn for modeling
- RandomForestRegressor
- GradientBoostingRegressor
- train_test_split
- Pipeline
- StandardScaler

These libraries are built for structured data at scale.

They learn real statistical relationships instead of guessing patterns.

ML produces stable, reproducible predictions

With scikit learn, you can:

Set random_state for deterministic behavior
Evaluate models with cross_val_score
Inspect feature importance
Tune hyperparameters with GridSearchCV or RandomizedSearchCV

This gives you a model that behaves the same way every time.

ML runs cheaply and efficiently

A trained scikit learn model:

Runs on CPU
Responds in milliseconds
Costs almost nothing per prediction
Scales horizontally with minimal infrastructure

This is why ML is used in production systems where cost and latency matter.

ML integrates cleanly into production

With Python’s ecosystem, you can deploy the model using:

FastAPI for serving predictions
Docker for packaging the environment

This gives you a clean, maintainable architecture that fits naturally into modern DevOps and MLOps workflows.

Why Claude 4.7 Loses

Claude 4.7 is powerful, but it is not built for this category of problem.

It cannot train on 10 GB of structured data

Claude can only sample or summarize chunks of the dataset.

It cannot compute gradients, optimize a loss function, or learn the full distribution.

It guesses patterns instead of learning them

LLMs are language models, not regression engines.

They infer trends from text, not from numerical relationships.

It is slower and more expensive

Higher latency
Higher compute cost
Requires chunking and repeated calls
Cannot be cached effectively

It introduces non deterministic behavior

Even with the same prompt, outputs can vary.

This is unacceptable for financial, operational, or regulatory workloads.

When Claude 4.7 Is Still Useful

LLMs are excellent assistants for:

Exploratory analysis
Explaining trends
Suggesting features
Cleaning messy text columns
Generating documentation

But not for the core predictive model.

For large structured datasets and numerical prediction tasks:

Use ML for the model.

Use LLMs for support.

This is the architecture that delivers accuracy, cost efficiency, and operational stability.

Machine Learning as Part of AI

Machine learning is one of the foundational pillars of AI. It learns patterns from structured data and uses those patterns to make predictions.

When ML is the right tool

Use ML when the problem involves:

Numerical prediction
Classification on structured data
Statistical relationships
Low latency inference
Clear evaluation metrics
Reproducible behavior

When LLMs are the right tool

Use LLMs when the problem involves:

Understanding or generating text
Summarizing documents
Reasoning across unstructured information
Conversational interfaces
Multi modal inputs

A simple rule of thumb:

If the question is “Given these numbers, what is the probability of X?” , use ML.
If the question is “Given this text, what does it mean?” , use an LLM.

What an ML Pipeline Really Is

An ML pipeline is the journey from raw data to a working model.

It is not a single script. It is a repeatable, structured process.

A complete ML pipeline includes:

Data ingestion
Data cleaning and preparation
Exploratory data analysis
Feature engineering
Model training and evaluation
Model packaging
Deployment and monitoring

This pipeline ensures that the work is reproducible, traceable, and ready for automation.

What MLOps Means

MLOps is the operational discipline that keeps machine learning systems healthy in production.

It brings together DevOps, data engineering, and model lifecycle management.

MLOps focuses on:

Versioning of data, code, and models
Automated training and retraining
Continuous integration and delivery
Monitoring model drift and performance
Scalable deployment patterns

If ML is the engine, MLOps is the system that keeps the engine running safely at scale.

Example: The Vancouver Traffic Accident Risk Predictor

This project analyzes weather and traffic accident data in Vancouver and builds a predictive model to estimate accident risk under different conditions.

It follows a complete ML pipeline from exploration to deployment.

Introduction to Weather and Traffic Accident Analysis in Vancouver

The project begins with a simple question:

How does weather influence accident risk in the city?

Data Sources and Analytical Tools

The project uses:

Traffic accident records: Traffic accident data is sourced from the City of Vancouver’s Strategic Plan Dashboard for reliability and accuracy. The dashboard provides detailed and regularly updated records essential for comprehensive traffic analysis.
Historical weather data: Weatherstats.ca aggregates data from Environment and Climate Change Canada for accurate meteorological information. The data encompasses a wide range of weather variables ensuring thorough climate analysis.

Tools include Python, Pandas, Matplotlib, Boken, Scikit Learn, FastAPI, and Docker.

Data Cleaning and Preparation

This stage merges datasets, handles missing values, and prepares the final analytical table.

Exploratory Data Analysis

EDA reveals patterns such as:

Higher accident frequency during snow
Seasonal variations
Time of day risk levels

Visualizing Key Trends

Charts help identify correlations and guide feature selection.

Predictive Modeling

The dataset is split into training and testing sets.

Models such as random forest are trained to predict accident risk.

Evaluation metrics confirm generalization.

Accuracy Metric: Accuracy measures the overall correctness of the predictive model by comparing true results to total predictions.

Precision Metric: Precision indicates how many of the positive predictions made by the model are actually correct.

Recall Metric: Recall assesses the model’s ability to identify all relevant positive cases in the dataset.

To increase the accuracy of Our ML module, we can tune the hyperparameters:

Insights and Conclusions

The analysis shows how weather patterns influence accident probability and demonstrates the value of structured ML for public safety insights.

5. Productionalization and Deployment

A model becomes valuable only when it can be used by real applications.

FastAPI Model Server

The trained model is wrapped in a FastAPI application that exposes a prediction endpoint.

An in memory prediction cache provides low latency responses.

Dockerized Environment

The entire environment is packaged in Docker, ensuring:

Consistent runtime
Easy local testing
Seamless deployment to any container platform

This closes the loop from exploration to production.

Why This Matters to Your Business

Every organization today is under pressure to adopt AI, but the real advantage comes from choosing the right tool for the right problem.

This article highlights a simple but often overlooked truth:

Not every AI problem needs an LLM. Many business problems are solved faster, cheaper, and more reliably with classical ML.

For business leaders, this means:

Lower operational cost
Faster time to value
More predictable performance
Easier compliance and governance
Clearer ROI

The Vancouver project is not just a technical exercise. It is a demonstration of how disciplined ML engineering can deliver practical, measurable outcomes without unnecessary complexity.

Conclusion

Machine learning is not a relic from the pre LLM era.

It is a precise, efficient, and reliable discipline that solves structured prediction problems better than anything else.

The Vancouver Traffic Accident Risk Predictor demonstrates how ML pipelines, MLOps practices, and lightweight deployment patterns come together in a real project.

If your team is exploring AI adoption, modernizing analytics, or evaluating where ML and LLMs fit into your roadmap, I am always open to meaningful conversations.

Whether you are building your first predictive model or scaling AI across the organization, the right architecture and the right tool choice make all the difference. Feel free to connect.

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 From Machine Learning to Production: A Practical Walkthrough Using My Vancouver Traffic Accident Risk Predictor appeared first on Behind the Build.

When AI Agents Transact: How Interaction Surface Mobility Redefines the Future of Payments

Jonathan Wong — Sat, 09 May 2026 03:46:22 +0000

The story of digital payments has always been a story about movement.
Not just the movement of money, but the movement of the place where intention begins, where authentication happens, and where the transaction is finally executed.

Amazon’s introduction of Amazon Bedrock AgentCore Payments marks the beginning of a new chapter in that story. It is a chapter where AI agents no longer wait for users to initiate payments. Instead, they transact autonomously, safely, and with full governance. And to understand why this matters, we need to look at how the interaction surface has been moving for more than two decades.

A New Foundation for Agent Payments

AgentCore Payments is a fully managed payment layer that allows AI agents to pay for APIs, data, MCP servers, and even other agents. It integrates Coinbase and Stripe to support microtransactions, stablecoin payments, identity bound wallets, spending guardrails, and full observability.

In the past, building this kind of payment capability required months of engineering work. Wallet management. Compliance. Guardrails. Billing logic. Error handling. AgentCore Payments removes all of that complexity. Payments become part of the agent execution loop, not a separate system bolted on the side.

This shift becomes clear when we look at how an agent handles a simple request such as analyzing Amazon stock.

How It Works

Once the agent realizes it needs paid data, the rest of the process is handled entirely by AgentCore Payments. The system provides a complete payment foundation inside the agent execution loop. It connects wallets, executes microtransactions, enforces spending rules, and records every event for governance and audit.

AgentCore Payments includes five core capabilities that work together as a single runtime layer.

Payment orchestration
The platform manages wallet connections, establishes secure sessions with providers such as Coinbase and Stripe, and executes payments on behalf of the agent.

Payment guardrails
Every transaction is checked against authorization rules and spending limits. This prevents runaway costs and ensures the agent stays within the boundaries defined by the user or the organization.

Unified identity for agents
Each agent operates under a consistent identity that ties together permissions, wallet access, and spending policies.

Observability across all payment events
Every payment attempt, success, failure, and retry is logged. This gives teams full visibility into how agents are spending and why.

Native integration with agent execution loops
Payments are not an external system. They are part of the agent’s reasoning and tool calling cycle. This allows agents to autonomously discover, evaluate, and pay for resources as part of completing a task.

Source: Agents that transact: Introducing Amazon Bedrock AgentCore payments, built with Coinbase and Stripe | Artificial Intelligence

Example: Analyze Amazon Stock Enquiry

A user asks the agent to analyze Amazon stock.
The agent determines that real time financial data is required, and that the data source is paid.
It reaches out to the provider.
At that moment, AgentCore Payments takes over.

It authenticates the wallet.
It executes the microtransaction.
It checks spending guardrails.
It logs the entire event for observability.

Once the payment clears, the agent receives the data.
It completes the analysis and returns the result to the user.

This example demonstrates the core value of AgentCore Payments.
Agents can autonomously transact inside a single execution loop without any custom payment logic.

Interaction Surface Mobility

A Short Explanation

To understand why this shift is so significant, we need a new lens.
Historically, people talked about device mobility. Desktop to laptop to mobile to wearables. But the real story is not about devices. It is about the interaction surface. The place where intention originates, where authentication happens, and where payments are triggered.

Interaction Surface Mobility describes how this surface keeps moving closer to the user’s life.
From the desk.
To the pocket.
To the environment.
And now into the cloud, where AI agents act on our behalf.

This mobility shapes how payments work, how businesses design services, and how value flows across digital ecosystems.

The Four Eras of Interaction Surface Mobility

Before we explore the eras, it helps to understand the underlying structure.
Payment flows follow a consistent pattern:

Interaction surface → service starting point → intention → authentication → channel

This formula becomes the backbone for understanding how payments evolve as the interaction surface becomes more mobile and more embedded in daily life.

But what is actually changing in this new era?
The primary shift is the movement of the interaction surface itself.
As the interaction surface moves, everything downstream changes with it.
The service starting point moves.
The intention model changes.
The authentication model changes.
The payment channel changes.
The interaction surface is the driver.
The rest of the flow is the consequence.

With this causal structure in mind, the four eras become clear.

Table: The Evolution of Interaction Surface Mobility

Era	Interaction surface	Service starting point	Intention	Auth	Channel
Desktop Web	Desktop	Website	User initiated	Manual login	Web payment page
Mobile App	Mobile phone	App	User initiated	Biometric	Mobile wallet
Cloud AI Services	Cloud agents	Cloud workflows	AI interpreted	Pre authorized agent identity	Agent to agent payment service
Ambient AI	Ambient compute	Autonomous AI workflows	AI reasoning	Identity bound spending guardrails	Autonomous payment protocols

Era 1: The Desktop Web

In the beginning, the interaction surface was fixed.
People sat at a desk, opened a browser, and intentionally navigated to a payment page. Every action was explicit. Every step was manual. Payments were a destination, not a flow.

This era shaped the first generation of online commerce. But it was limited by the immobility of the interaction surface. The user had to go to the computer. The computer never followed the user.

Era 2: The Mobile App

Then the interaction surface moved into the pocket.
The phone became the center of digital life.
Apps replaced websites.
Biometrics replaced passwords.
Wallets replaced card forms.

Payments became faster, more personal, and more contextual.
This era created ride hailing, food delivery, and mobile commerce.
It also marked the beginning of lifestyle mobility.
People no longer went to the payment interface.
The payment interface went with them.

Era 3: Cloud Based AI Services

The next shift was subtle but profound.
The interaction surface moved off the device entirely and into the cloud.
AI agents began performing tasks on behalf of users.
They interpreted intention.
They initiated workflows.
They accessed paid resources.

But payments were still a problem.
Agents could not pay for anything without custom engineering.
Wallets were not agent native.
Guardrails were not standardized.
Governance was fragmented.

AgentCore Payments solves this.
It gives agents a native way to transact, with identity, guardrails, and observability built in.
This is the first real payment system designed for autonomous agents.

Era 4: Ambient AI

This is the era we are entering now.
The interaction surface becomes the environment itself.
Homes, cars, offices, glasses, wearables, sensors, and cloud agents all become part of a continuous ambient layer.

Intention is no longer expressed.
It is reasoned.
Sometimes even anticipated through context.

Authentication becomes a set of identity bound spending rules.
Channels become autonomous payment protocols.
Transactions become micro events inside larger workflows.

In this world, payments are not actions.
They are side effects of intelligent systems doing their work.

Why This Matters for Business

Interaction Surface Mobility is not just a technical evolution.
It is a business transformation.

Payments become invisible.
Intention becomes fluid.
Authentication becomes ambient.
Channels become agent native.
Business models shift from subscriptions to usage based to agent based.

Agents will buy data.
Agents will buy compute.
Agents will buy services.
Agents will buy from other agents.

The companies that understand this shift will design products for a world where the user is no longer the primary actor in the payment flow.
The agent is.

Closing Thought

The movement of the interaction surface has always reshaped the payment landscape.
From the desk.
To the pocket.
To the environment.
And now into the cloud, where agents transact on our behalf.

AgentCore Payments is not just a new feature.
It is the infrastructure for the next era of commerce.
An era defined by Interaction Surface Mobility, where payments become autonomous, contextual, and woven into the fabric of intelligent systems.

The post When AI Agents Transact: How Interaction Surface Mobility Redefines the Future of Payments appeared first on Behind the Build.

A Pre‑AI Lesson for the AI Era: Scrum in a Cross‑Regional Cloud Migration Delivered in Ten Weeks

Jonathan Wong — Wed, 06 May 2026 23:23:33 +0000

A few years ago, I stepped into one of the most challenging and transformative projects of my career as a Cloud Architect. I was responsible for leading a cross‑regional team of more than twenty developers across Hong Kong and China. With Scrum, Atlassian JIRA, and Confluence as our backbone, we rebuilt an AWS‑based JEE Spring microservices platform using Kafka and PostgreSQL and migrated it fully to Azure. The original engineering estimate was six months. We delivered it in ten weeks.

This is the story of how alignment, structure, and communication reshaped the entire organisation.

Background

Situation
The project began with a strong team but a fragmented operating model. Everyone worked hard, but the lack of shared structure created delays and misunderstandings.

Points
• Cross‑regional team of more than twenty developers across Hong Kong and China
• Many engineers were domain experts with strong CI and CD foundations
• Multiple teams involved including product, engineering, sales, and customer success
• Hardworking culture but no unified workflow
• Required to migrate a cloud product to Azure due to client request
• Engineering estimated six months, which the business could not accept

Result
The team had the talent and capability, but without alignment, the project was heading toward an unacceptable timeline.

My Role in the Transformation

As the Cloud Architect leading this initiative, I became the bridge between product, engineering, sales, and customer success. My role was not only technical but also organisational. I facilitated communication, explained Scrum practices in simple and practical ways, and guided the teams to adopt a structured, transparent workflow. By aligning expectations, enforcing clarity, and coaching the teams through Agile execution, I helped transform the project from fragmented chaos into a predictable, collaborative delivery model.

Problems and the Real Original Situation

Situation
The delays were not caused by technical difficulty. They were caused by fragmented communication, inconsistent requirement handling, and a workflow that depended heavily on verbal instructions and individual memory. The actual “before” situation was far more chaotic than a simple misalignment.

Points
• Product team sometimes gave requirements verbally through phone calls, WhatsApp or WeChat
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels such as email, phone, and chat
• Customer success often contacted individual engineers or product members suddenly
• No one had a complete picture of the requirement
• Engineering teams lacked visibility into each other’s status and technical availability
• Developers were frequently switched between tasks, losing focus
• Management had no visibility into progress or bottlenecks
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering in a structured way

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable. The six‑month estimate reflected organisational misalignment, not technical complexity.

How I Solved It Using JIRA, Confluence, and Scrum

Inside the Engineering Teams

Situation
The engineering team needed structure, clarity, and a predictable rhythm.

Points
• All development work documented on the tracker
• Engineers only worked on items listed in the tracker
• Requirements treated as negotiable conversations
• PM updated the tracker after every discussion
• Engineers picked the first available item
• Story status updated continuously
• One engineer worked on one item at a time
• Requirements broken into technical tasks
• Development discussions moved into JIRA
• Work delivered into testing story by story
• Tasks created for POC, technical debt, and research
• Tasks broken down with dependencies and blockers
• One task assigned to one engineer

Result
Engineering gained clarity, focus, and a stable delivery rhythm that accelerated progress.

Inside the Product Team

Situation
The product team needed a consistent way to express requirements so engineering could execute without ambiguity.

Points
• Features and bugs written with proper structure
• Requirements documented from the user perspective
• Simple English, point form, short sentences
• Stories tested and verified quickly
• Backlog groomed regularly and prioritized top to bottom

Result
The product team became a source of clarity instead of confusion, reducing rework and saving time.

Knowledge and Task Management

Product, Knowledge, and Requirement Management

Situation
Information lived in too many places. Teams needed a single source of truth.

Points
• Confluence used as a centralized panel
• Structure followed Space to Pages to Contents
• Pages included product requirements, technical documents, and notes
• Product requirement pages included goals, milestones, and voting
• Technical documents included architecture, installation, and account details
• Notes captured meetings, research, and decisions
• Confluence pages linked directly to JIRA issues

Result
Knowledge became shared, searchable, and consistent across all teams.

Issue Types and Their Purpose

Situation
Teams needed a common language to describe work, track progress, and estimate timelines.

Points
• Bug for previously working functions that broke
• Note for behaviours that became new requirements
• Story for the smallest unit of user value
• Task for feasibility studies, POC, and technical debt
• Epic for large initiatives
• Subtask for breaking down work
• Enabled velocity tracking and release estimation
• Tracked internal and external dependencies
• Smart Commits connected code changes to tasks
• JIRA release notes notified sales and CS automatically

Result
The organisation gained predictable delivery, accurate planning, and better cross‑team alignment.

Team Meetings to Improve Communication

Situation
Tools alone were not enough. Teams needed real‑time alignment and shared understanding.

Points
• Daily morning standups with engineering
• Weekly Monday meeting with all team heads
• Customer success joined standups when client feedback needed clarification

Result
Communication became continuous, reducing misunderstandings and last‑minute surprises.

Example: From Product Design through Engineering to CS and Back

Situation
To show the impact of the transformation, here is a real example of how a feature moved through the organisation before and after the new workflow.

Before

Situation
The original workflow was chaotic, fragmented, and heavily dependent on verbal communication.

Points
• Product team sometimes gave requirements verbally through phone calls or WhatsApp
• Product features were told directly to individual engineers or salespeople
• Different parts of the same requirement were distributed through different channels
• Customer success often contacted individual engineers suddenly
• No one had a complete picture of the requirement
• Engineering built based on partial or outdated information
• Sales promised features based on verbal conversations
• CS handled customer issues without knowing what was released
• Feedback rarely reached product or engineering

Result
The organisation operated on tribal knowledge. Misunderstandings were common, rework was frequent, and timelines were unpredictable.

After

Product Design

• Product team created a clear Confluence page with goal, user story, acceptance criteria, and diagrams
• Page linked directly to a JIRA story and tasks
• All teams saw the same requirement at the same time

Engineering Development

• Engineers broke the story into tasks and subtasks
• Dependencies and blockers were defined
• Work delivered story by story into testing
• PM verified each story immediately

Release to CS

• JIRA release function automatically pushed release notes to Microsoft Teams
• CS team received a clear list of new features, fixes, and version numbers
• Sales also received the same release notes

CS Feedback Loop

• CS tested the new feature with real customers
• Feedback added as comments on the Confluence page
• Product team reviewed and updated requirements
• Engineering received new tasks or improvements linked to the original story

Result
The entire lifecycle became a closed loop. Every team saw the same truth, reacted quickly, and aligned their actions.

Before and After Comparison

Situation
The transformation changed the culture, speed, and clarity of the entire organisation. Presenting the contrast as a table makes the improvement immediately clear.

Phase	Before	After	Result
Product Design	Requirements delivered verbally through phone or WhatsApp	Requirements documented clearly in Confluence	Clear documentation replaced verbal memory
Product Design	Different parts of the same requirement sent through different channels	Single source of truth for all requirements	One place for all information
Product Design	Product features communicated directly to individual engineers or sales	Structured JIRA stories and tasks shared with all teams	Everyone received the same message
Knowledge Management	No documentation and no shared visibility	Centralized product and technical knowledge	Teams aligned on the same information
Engineering Execution	Frequent rework and misaligned expectations	Predictable engineering workflow with clear dependencies	Work became stable and predictable
Release Management	No release notes for CS or sales	Automated release notes through JIRA to Microsoft Teams	All teams stayed informed on every release
Customer Success	CS feedback delivered suddenly to individuals	CS feedback captured in Confluence and linked to JIRA	Feedback became structured and trackable
Delivery Timeline	Six month timeline estimate	Ten week delivery	Alignment accelerated delivery dramatically

Result
The organisation shifted from reactive chaos to proactive alignment, with every team operating from the same truth.

What This Solved and the Result

Situation
Once structure, communication, and knowledge alignment were in place, the entire organisation began to move faster.

Points
• Centralized visibility improved planning and saved time
• Clear product goals reduced misunderstanding
• Early validation reduced downstream rework
• Engineering timelines became predictable
• Product page and task linkage aligned business and engineering
• JIRA auto‑release notes empowered sales and CS
• Engineering teams understood each other’s status and availability
• Defined blockers prevented last‑minute surprises
• Centralized documentation reduced search time and improved support

Result
The six‑month estimate collapsed into ten weeks because every team finally moved in the same direction.

Conclusion

Product success is built on teamwork across all functions. Improving the product development timeline required alignment from product design to feature validation, business requirement transformation, testing, release, customer success, post delivery support, and customer feedback. When every team shares the same truth, the entire organisation accelerates.

This experience, even though it happened a few years ago, remains fully relevant in today’s AI driven business era. It is a clear example of how Scrum and Agile principles solve real operational problems. The story shows that delays rarely come from tools or technical expertise. They come from the absence of a disciplined operational methodology. When teams follow a repeatable Agile process supported by a single source of truth, technology becomes an accelerator rather than a bottleneck.

What’s Next

This article presents the high level view of how Scrum and operational alignment improved a cross regional cloud migration timeline. In the next article, I will walk through the detailed implementation across each phase, and explain the specific problems the team encountered, how those challenges were solved, and how the Scrum workflow kept the project moving with clarity from design to delivery.

The post A Pre‑AI Lesson for the AI Era: Scrum in a Cross‑Regional Cloud Migration Delivered in Ten Weeks appeared first on Behind the Build.

Cloud Summit 2026

Jonathan Wong — Mon, 04 May 2026 19:56:54 +0000

I spent the day at Cloud Summit and it turned into one of the busiest days I have had in the Vancouver tech scene. The event pulled together a wide mix of local engineers and builders, and most of the sessions leaned heavily into AI. The conversation has clearly shifted from abstract excitement to real architectural patterns and operational challenges.

One of the most interesting sessions was the deep dive into the Kubernetes AI Gateway work. The working group is shaping a consistent way to handle AI‑specific traffic at the gateway layer, including protocol awareness, egress controls, payload inspection, routing and guardrails. It is still early and mostly proposals and prototypes, but the direction is promising for teams trying to standardize how they expose and secure inference workloads.

Another standout was the talk on cloud billing complexity, The Cloud Bill Nobody Could Explain. The speaker walked through a real incident investigation where even experienced teams struggled to explain unexpected cost behaviour. The supporting tools were practical, from VPC flow log analyzers that map traffic to namespaces, to exporters that surface per‑namespace cloud cost metrics, to utilities for finding orphaned disks across providers. It was a reminder that cost transparency is still one of the hardest engineering problems in cloud.

The free snacks and pizza made the long day easier, and if you also joined the AWS Workshop on Introduction to Claude Code on AWS and stayed for the after party, you probably felt the same mix of learning, networking and exhaustion.

Vancouver’s cloud and AI community is moving fast, and days like this make it clear how much is happening across the ecosystem.

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 Cloud Summit 2026 appeared first on Behind the Build.

Autodata and the New Data Pipeline: Why Meta’s Agentic Data Scientist Matters More Than the Model

Jonathan Wong — Sun, 03 May 2026 01:52:55 +0000

The industry has spent years debating model size, architectures, and inference tricks. But Meta’s latest research makes something very clear: AI success is still determined by four elements: prompt, grounding, training, and fine tuning, and three of them are fundamentally data problems.

Which means the real bottleneck isn’t compute. It’s data quality, data structure, and data digestion.

Meta’s new Autodata framework reframes this bottleneck entirely. Instead of treating data as a static asset that humans must continuously curate, Autodata turns the model itself into an autonomous data scientist , capable of generating, analyzing, and iterating on its own training data.

Figure: Autodata pipeline. The framework employs an autonomous agent that emulates the role of a data scientist, iteratively generating data, conducting qualitative inspection and quantitative performance evaluation, synthesizing insights, and updating the data-generation recipe. The agent itself can be trained to be better at the data scientist task using the same criteria used in the inner loop. This cyclical process aims to progressively enhance data quality; the diagram depicts the general workflow underlying possible instantiations. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

This is not “synthetic data 2.0.”

This is a shift in how data pipelines operate.

1. Why Data Quality Still Determines AI Success

Prompting and grounding matter, but they sit on top of the real foundation:

the training data that shapes the model’s baseline
the fine‑tuning data that aligns it
the evaluation data that determines whether it’s improving

Three of the four levers that determine AI performance are data‑centric.

And historically, all three required human data scientists — expensive, slow, and difficult to scale.

2. The Traditional Data Scientist Bottleneck

Data scientists have always played the critical role of:

curating high‑quality examples
grounding tasks in real documents
designing evaluation rubrics
iterating based on model failures

This work is high‑cost because it requires human judgment , domain knowledge, and careful harness engineering. Even synthetic data pipelines still depended on humans to design prompts, filters, and quality checks.

3. Meta’s Autodata: A Model That Trains Itself With Data It Creates

Autodata changes the loop.

Instead of single‑pass synthetic generation, the model now:

Data Creation. The agent grounds on the provided documents and uses its existing skills and compute to create training or evaluation data. It can repeat this step after each analysis cycle to incorporate new learnings and improve the data.
Data Analysis. The agent reviews the data it created to understand correctness, quality, difficulty, and diversity. These learnings feed directly back into the next creation cycle until the data reaches the required standard.
Data Scientist Loop. The agent cycles between creation and analysis until it is satisfied with the final dataset. Guardrails can be applied to prevent reward hacking, and later generations of agents can build on earlier learnings.
Meta Optimization. The agent itself can be improved through autoresearch or meta‑harness optimization so it becomes better at performing the data scientist role over time.

Meta’s implementation uses a multi agent setup with a Challenger, a Weak Solver, a Strong Solver, and a Verifier to ensure the generated data is neither trivial nor impossible. The result is higher quality training data than classical Self Instruct or CoT Self Instruct methods.

This is the first time we’ve seen a closed‑loop, feedback‑driven data creation system that mirrors how human data scientists work.

Figure: Example agent trajectory on a CS research paper, showing the final accepted round (round 6) after 5 failed attempts. The Main Agent reflects on prior failures and prompts the Challenger Agent to generate a new question. The example is evaluated by Weak (4B) and Strong (397B) solvers, scored by a Verifier/Judge across 12 rubric criteria. Round 6 achieves a 45% gap (weak 48% vs. strong 93%) and is accepted. Learnings from rounds 1–5 feed back into the Main Agent’s refinement strategy. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

4. Reducing the Cost of Human‑Grounded Data

The cost of training data has always come from:

human annotation
human‑designed prompts
human‑designed evaluation rubrics
human‑driven iteration

Autodata reduces all four.

Meta’s meta‑optimization layer even shows that the agent can improve its own instructions , discovering better harness logic without human intervention.

Figure: Meta-optimization of the data scientist agent. An outer optimization loop evaluates the agent’s harness on training papers, analyzes failure trajectories to identify systematic weaknesses (e.g., context leakage), implements harness modifications via a code-editing agent, and re-evaluates on held-out validation papers. Changes are accepted only if they improve the weak-strong separation rate. This process improved validation pass rate from 12.8% to 42.4% over 126 accepted iterations out of 233 total. RAM @ Meta AI | A framework to study AI models in Reasoning, Alignment, and use of Memory (RAM)

This is the part that matters:

The model is not just generating data, it is improving the rules for generating data.

5. AI as the Data Scientist

Meta’s results show that an AI data scientist can:

enforce paper‑specific insights
prevent context leakage
design structured rubrics
tune difficulty levels
widen capability gaps between weak and strong solvers

All without manual harness engineering.

This is the beginning of agentic data operations , where the model becomes an active participant in its own training pipeline.

6. A Shift in the Data Operations Pipeline

Autodata changes the relationship between:

data creation
data evaluation
model training
model alignment

Instead of a linear pipeline, we now have a self‑improving loop where the model continuously refines the data that refines the model.

This transforms data operations from a human‑driven workflow into a compute‑driven optimization problem.

7. Rethinking the Four Elements of AI Success

If prompt, grounding, training, and fine‑tuning determine AI success, and three of them are data‑centric, then Autodata forces us to rethink how these elements interact.

We now have:

new external grounding (the model grounds itself on documents)
new internal grounding (the model evaluates its own reasoning)
new training loops (data improves as compute increases)
new fine‑tuning strategies (agent‑generated datasets outperform human‑designed ones)

The implication is simple:

Data pipelines are becoming agentic systems, not manual processes.

Where This Leads

Autodata is not just a research milestone.

It signals a future where:

models generate their own training curriculum
data scientists supervise strategy, not samples
data quality scales with compute, not headcount
grounding becomes dynamic, not static
fine‑tuning becomes continuous, not episodic

The next wave of AI performance will come from agentic data pipelines , not larger models.

And Meta just opened the door.

Source: Meta Autodata research https://facebookresearch.github.io/RAM/blogs/autodata/

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 Autodata and the New Data Pipeline: Why Meta’s Agentic Data Scientist Matters More Than the Model appeared first on Behind the Build.

IEC BC x ISACA Vancouver Cybersecurity Networking Event

Jonathan Wong — Thu, 30 Apr 2026 23:04:57 +0000

At the IEC BC x ISACA Vancouver Cybersecurity Networking Event this week, newcomers, experienced professionals, and employers had the chance to connect meaningfully. Thank you to Immigrant Employment Council of BC, ISACA Vancouver Chapter and Vancouver Community College (VCC) for making this possible.

The speaker shared a clear breakdown of certification pathways in cybersecurity.

Foundational certifications include ISC2 Certified in Cybersecurity (CC).

Intermediate tracks include CISA, CCSP, and AWS Security.

Senior level designations include CISSP and CISM, which reflect broader responsibility across governance, architecture, and organizational risk.

The speaker also highlighted the challenges overseas trained professionals face in the Vancouver job market. Many arrive with strong technical backgrounds, yet still need to navigate local hiring expectations, credential recognition, and the persistent “Canadian experience” requirement. Hearing this acknowledged openly was valuable for many attendees.

Another insight from the talk focused on how companies are adopting AI inside their organizational structure. The risk is not only technical. For SMEs with fewer than 50 employees, restructuring teams too quickly around AI can create instability and unclear ownership.

One final note for anyone exploring cybersecurity.

The free ISC2 Certified in Cybersecurity (CC) enrollment ends on May 20, 2026.

If you are considering a first step into the field, this is a good opportunity before the window closes.

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 IEC BC x ISACA Vancouver Cybersecurity Networking Event appeared first on Behind the Build.

My Journey to the Google Cloud Get Certified: From Fundamentals to Generative AI

Jonathan Wong — Thu, 30 Apr 2026 22:19:03 +0000

Deciding to get Google Cloud certified is one thing; finding a structured path to get there is another. I recently hit a major milestone in my journey: completing Stage 2 of the Google Cloud Get Certified program.

By earning five specific skill badges, I’ve officially unlocked my free exam voucher. These weren’t just theoretical modules—they were intense, hands-on labs that forced me to build, secure, and automate real-world cloud environments. Here is how I structured my learning path to cross the finish line:

Build a Secure Google Cloud Network

I started with the foundation. This badge focused on the defensive side of cloud architecture. I configured VPC firewalls, set up private access, and ensured that the network followed the “least privilege” principle to protect data from the ground up.

Set Up an App Dev Environment on Google Cloud

Once the network was secure, I moved to the application layer. This badge covered the essential tools for a developer’s workflow, including setting up development clusters and managing the full lifecycle of an app within the Google Cloud ecosystem.

Implement Load Balancing on Compute Engine

With the environment ready, I had to ensure it could handle traffic. I practiced configuring various Google Cloud load balancers (HTTP(S) and TCP/UDP) to distribute traffic across Compute Engine instances, ensuring high availability and performance.

Build Infrastructure with Terraform on Google Cloud

After mastering the manual setups, I moved to Infrastructure as Code (IaC). This badge acted as the bridge, taking the networking and compute skills I’d learned and teaching me how to provision them automatically using Terraform configuration files for repeatable, version-controlled deployments.

Create Your First Gemini Enterprise Application

Finally, I explored the future of the cloud: Generative AI. This badge involved integrating Google’s Gemini large language models into enterprise-level applications, showing how AI can be layered on top of a robust infrastructure.

The Road Ahead

These labs provided the practical “muscle memory” needed for the real world. Now that the voucher is unlocked, the final step toward official certification can be taken!

Are you working on GCP networking or security right now? I’d love to compare notes or hear about your approach!

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 My Journey to the Google Cloud Voucher: From Fundamentals to Generative AI appeared first on Behind the Build.

Sakura Migration

Jonathan Wong — Sun, 26 Apr 2026 05:03:15 +0000

Not long ago I visited UBC, where the Sakura blossoms were in full bloom again.

It reminded me of the first time I saw them decades ago in Japan, when I was working inside a 200‑person IT department. That was the on‑prem era. Everything lived in racks and server rooms. Everything felt stable, predictable, and physical. I thought my career would stay that way.

But life moves. Sometimes quietly. Sometimes without a plan.

Later I met Notey, and that was the beginning of my startup journey. I moved from enterprise structure to startup speed. From on‑prem systems to the cloud. From a single role to wearing multiple hats. That was my first migration, not geographical but mental. A shift in how I saw technology, teams, and myself.

I moved to Boxful next. Built an MVP that helped secure funding. Shifted from development to product. From proprietary stacks to open source. From execution to ownership. Another migration. Another environment. Another version of myself.

After that chapter, I joined venture builders, Flatiron, helping capital create new startups. Moving from building one company to helping many. From operator to enabler. From solving problems to designing systems that solve problems. Another migration.

Eventually, the Startup Visa program brought me to Vancouver. From East Asia to North America. From familiar ground to a new ecosystem. From the world I grew up into the world I chose. A migration across continents, but also across identity.

Walking past the students on UBC’s campus takes me back to when I was an undergraduate, excited about my first Yahoo email. At the time, I believed I would be happy coding every day. But the world kept shifting. We moved from desktop to cloud, then to mobile, and now to AI, where skills can be downloaded and coding itself is being redefined. Another migration. Another environment. Another identity.

Looking back, none of these migrations were planned. They happened one step at a time. Each one pulled me into a new environment and forced me to grow in ways I never anticipated.

There were migrations in scale. Migrations in technology. Migrations in geography. Migrations in identity.

Those who pause beneath the Sakura on UBC’s Memorial Road often say the trees were brought from Japan and replanted here. They blossom every year in a way you cannot find anywhere else. They did not choose the journey, yet they grew. And they became something unique because of the journey, not in spite of it.

Are you someone shaped by migrations.

What has been your latest migration.

The post Sakura Migration appeared first on Behind the Build.