Most engineers use AI the way they'd use a smarter autocomplete. One chat window. One task at a time. You type, you wait, you watch it type back, you copy the result. That's a fine place to start, and it's also where most people stop. Heavy users work differently — not because they type faster, but because they stop babysitting a single conversation and start orchestrating many.

Here's the mental shift: a chat is something you attend; a fleet is something you dispatch. The rest of this post is a ladder from one to the other, in four levels, using Claude Code as the running example. Each level is worth adopting on its own.

Level 1 — Loops: stop re-typing the same prompt

The first habit that separates heavy users is that they almost never do the same thing twice by hand. If a task is worth doing on an interval — poll a deploy, keep tests green, watch a PR for review comments — it should run on a loop, not on your attention.

In Claude Code, that's /loop:

/loop 5m /run-tests

That runs your /run-tests command every five minutes. Drop the interval and the model self-paces — it decides when to check back based on what it's waiting for:

/loop keep checking the PR for new review comments and address them

The point isn't the syntax. The point is a change in posture: work that repeats should not consume you. A loop babysitting a CI run frees you to think about the next thing instead of alt-tabbing to a dashboard every few minutes. The first time you set a loop running and walk away, the "one chat window" model starts to feel very small.

A good rule: any sentence you find yourself starting with "every few minutes, check…" is a loop.

Level 2 — Workflows: when a script beats a conversation

A loop repeats one task. A workflow orchestrates many, deterministically. The distinction matters: a conversation is model-driven — the model decides what to do next — while a workflow is code-driven. You write the control flow (the fan-out, the loop, the verify step) and the model fills in the intelligent parts.

The classic shape is find → verify → synthesize. Say you want to review a branch across several dimensions — correctness, security, performance — and you don't want a single pass that half-covers each. A workflow fans out one agent per dimension, then spawns a skeptic to adversarially verify each finding before it reaches you:

review each changed file for [correctness, security, perf]
  → for every finding, spawn a verifier that tries to REFUTE it
  → keep only findings that survive

Why bother instead of just asking? Three reasons:

1. Determinism — the same structure runs the same way every time. No "it forgot to check the security angle."
2. Parallelism — the dimensions run concurrently, so wall-clock time is the slowest single chain, not the sum.
3. Adversarial rigor — a separate agent whose only job is to disprove a finding kills the plausible-but-wrong results that a single optimistic pass waves through.

You reach for a workflow when the task has structure you can name — a set of files to sweep, a pipeline of stages, a thing that must be checked N independent ways. When the task is exploratory and you don't know the shape yet, stay in a conversation. Heavy users move fluidly between the two: scout in a chat to discover the work-list, then hand the list to a workflow to grind through it.

Level 3 — Subagents: parallel work, isolated context

Inside a single session, you don't have to do everything in your own context window. You can dispatch subagents — independent Claude instances that go off, do a focused job, and return only the conclusion.

This is the antidote to context bloat. When you need to answer "where is X handled across these forty files?", you don't want forty files dumped into your working memory. You want an agent to sweep them and hand back the two-line answer:

Explore agent: find every place we validate auth tokens; return file:line + a one-line note each

The key techniques:

• Fan out for independent work. If you have three unrelated tasks — update the docs, fix a flaky test, add a config flag — dispatch three agents in a single message so they run concurrently instead of one after another.
• Use the right agent for the job. A read-only Explore agent for searching, a Plan agent for designing an approach, a general agent for multi-step execution. Specialized agents keep each job's context clean.
• Keep the conclusion, not the file dump. The whole win is that the subagent reads broadly and you keep only what matters. Your context stays lean; theirs absorbs the noise.

The mental model: you are less the person writing every line and more the tech lead handing out well-scoped tickets and integrating what comes back.

Level 4 — Multiple sessions and tmux: run the fleet in parallel

The final level is spatial. One session, however well-orchestrated, is still one throat to choke. Heavy users run several Claude Code sessions at once, each on its own slice of the work, laid out where they can watch them all.

That's what tmux is for. Split your terminal into panes and put a session in each:

# a 2x2 grid of independent Claude sessions
tmux new-session -d -s fleet
tmux split-window -h
tmux split-window -v
tmux select-pane -t 0
tmux split-window -v
tmux attach -t fleet

Now you have four panes. One session is refactoring a module, another is writing tests for it, a third is drafting a migration, a fourth is on a /loop watching CI. You glance across the grid the way an ops engineer watches a wall of monitors — dipping into whichever pane needs a decision, letting the rest run.

There's one trap to avoid: parallel sessions editing the same files will collide. The fix is isolation. Give each parallel line of work its own git worktree — a separate checkout of the same repo sharing one history:

git worktree add ../blog-feature-a feature-a
git worktree add ../blog-feature-b feature-b

Point one session at each worktree and they can hammer away simultaneously without stepping on each other. Merge when each is done. Some agent tools will even spin up a throwaway worktree per agent for you when parallel edits would otherwise conflict — but knowing the primitive underneath it is what lets you scale past a handful of sessions.

A day in the fleet

Put the four levels together and an ordinary morning looks like this:

• Pane 1 is running a review workflow on last night's branch — fan out, verify, and by the time I've had coffee it's handed me three confirmed bugs and discarded eleven false alarms.
• Pane 2 is a session in a worktree, implementing the fix for the first bug while I read the writeup for the second.
• Pane 3 is a /loop babysitting the deploy pipeline; it pings me only if something turns red.
• Pane 4 is where I'm actually thinking — sketching the next feature with a Plan agent, dispatching Explore agents to answer "how do we do X today?" without polluting my context.

I'm not typing faster than anyone else. I'm just not the bottleneck for four things at once.

Where to start

You don't get here by flipping a switch. You get here by climbing one rung at a time:

1. This week: replace one repetitive check with a /loop. Feel what it's like to walk away from it.
2. Next: the first time you catch yourself doing the same review by hand twice, write it as a workflow.
3. Then: stop reading forty files yourself — dispatch an Explore agent and keep the answer.
4. Finally: open a second session in a worktree and let two things happen at once.

The autocomplete model asks "what can this AI do for my current line of code?" The fleet model asks "what are the six things that could be running right now, and which one actually needs me?" That second question is the whole job. Learn to ask it and the tools stop being assistants — they become the team you lead.

On AWS, the clean managed path for this is Bedrock AgentCore paired with the Model Context Protocol (MCP). In this post I'll build an agent that connects to my company's internal tools over MCP, grounds its answers in internal documents through a Bedrock Knowledge Base, and ships as a small chatbot you can run in a terminal. Let me walk you through it.

From Models to Agents

An "agent" is three things wired together:

1. A model to reason (here, Claude on Bedrock)
2. A set of tools it can call (your company's APIs, exposed as MCP tools)
3. A loop that lets the model decide: answer directly, call a tool, read a doc, then continue

The hard parts have always been hosting that loop reliably and connecting it to real company systems without hand-rolling an integration per API. That's exactly what AgentCore handles. AgentCore Runtime hosts the agent as a managed, serverless endpoint. AgentCore Gateway turns your existing APIs into MCP tools the agent can discover and call. And a Bedrock Knowledge Base gives it retrieval over your documents.

The Architecture at a Glance

Here's how the pieces fit together:

1. Bedrock Knowledge Base indexes internal docs sitting in S3 (managed RAG)
2. AgentCore Gateway exposes company APIs (order lookup, ticketing, etc.) as MCP tools
3. The agent — a model plus a tool-use loop — connects to the Gateway over MCP and to the Knowledge Base for retrieval
4. AgentCore Runtime hosts that agent behind a stable, session-aware endpoint
5. A CLI chatbot invokes the endpoint and streams responses back

Each layer has one job and can be built and tested on its own. Let's go through them.

Grounding the Agent in Internal Docs

Before the agent can answer questions about internal policies, runbooks, or specs, it needs to read them. A Bedrock Knowledge Base handles the whole RAG pipeline for you: point it at an S3 bucket of documents, pick an embeddings model, and Bedrock chunks, embeds, and indexes everything into a vector store.

Once the Knowledge Base is synced, you can query it directly with retrieve_and_generate — this both retrieves the relevant chunks and generates a grounded answer in one call:

import boto3

agent_runtime = boto3.client("bedrock-agent-runtime")

response = agent_runtime.retrieve_and_generate(
    input={"text": "What's our on-call escalation policy for Sev-1 incidents?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "KB1234567890",
            "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0",
        },
    },
)

print(response["output"]["text"])

That's a useful building block on its own. But we don't want a separate call path — we want the agent to reach for the docs on its own when a question calls for it. We'll wire the Knowledge Base in as a tool in a moment.

Exposing Company Tools Through the MCP Gateway

This is the heart of it. Your company already has APIs — an order service, a ticketing system, a customer database. AgentCore Gateway takes those and exposes them as MCP tools, so any MCP-speaking agent can discover and call them through one standardized endpoint. No per-API glue code in the agent itself.

First, create the gateway. It speaks MCP and authorizes inbound callers with a JWT (from Cognito or any OIDC provider):

import boto3

gateway_client = boto3.client("bedrock-agentcore-control")

auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": ["<cognito_client_id>"],
        "discoveryUrl": "<cognito_oidc_discovery_url>",
    }
}

gateway = gateway_client.create_gateway(
    name="CompanyToolsGateway",
    roleArn="arn:aws:iam::123456789012:role/AgentCoreGatewayRole",
    protocolType="MCP",
    authorizerType="CUSTOM_JWT",
    authorizerConfiguration=auth_config,
    description="Internal company tools exposed as MCP",
)

gateway_id = gateway["gatewayId"]
gateway_url = gateway["gatewayUrl"]

Then add targets — each target is a backend the gateway turns into tools. The simplest is a Lambda function, where you declare the tool schema inline. Here's an "order status" tool backed by a Lambda:

lambda_target_config = {
    "mcp": {
        "lambda": {
            "lambdaArn": "arn:aws:lambda:us-east-1:123456789012:function:get-order-status",
            "toolSchema": {
                "inlinePayload": [
                    {
                        "name": "get_order_status",
                        "description": "Look up the current status of a customer order by ID",
                        "inputSchema": {
                            "type": "object",
                            "properties": {"orderId": {"type": "string"}},
                            "required": ["orderId"],
                        },
                    }
                ]
            },
        }
    }
}

gateway_client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name="OrderStatusTool",
    description="Order status lookup",
    targetConfiguration=lambda_target_config,
    credentialProviderConfigurations=[{"credentialProviderType": "GATEWAY_IAM_ROLE"}],
)

If your service already has an OpenAPI spec, you can skip the inline schema entirely — point the target at the spec in S3 and the gateway generates a tool per operation:

openapi_target_config = {
    "mcp": {"openApiSchema": {"s3": {"uri": "s3://my-bucket/specs/ticketing.yaml"}}}
}

gateway_client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name="TicketingTools",
    description="Ticketing API from OpenAPI spec",
    targetConfiguration=openapi_target_config,
    credentialProviderConfigurations=[
        {
            "credentialProviderType": "API_KEY",
            "credentialProvider": {
                "apiKeyCredentialProvider": {
                    "credentialParameterName": "api_key",
                    "providerArn": "<api-key-credential-provider-arn>",
                    "credentialLocation": "HEADER",
                }
            },
        }
    ],
)

When you create a target, the gateway immediately calls the MCP tools/list capability behind the scenes and indexes the tools, so they're discoverable right away. On the outbound side, the gateway handles auth to your backend for you — IAM (SigV4), OAuth, or an API key — so your credentials never live in the agent.

Assembling the Agent

Now we bring the model, the tools, and the docs together. I'll use the Strands Agents SDK for the agent loop — it's what AgentCore's toolkit is built around — and wrap it in BedrockAgentCoreApp so it can be deployed to the Runtime.

The agent connects to the Gateway as an MCP client: it opens a streamable HTTP connection to the gateway URL with a bearer token, lists the available tools, and hands them to the model. For documents, Strands ships a built-in retrieve tool that queries a Bedrock Knowledge Base (it reads the KNOWLEDGE_BASE_ID environment variable), so the model can pull from internal docs the same way it calls any other tool.

import os

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent
from strands.models import BedrockModel
from strands_tools import retrieve
from strands.tools.mcp import MCPClient
from mcp.client.streamable_http import streamablehttp_client

app = BedrockAgentCoreApp()

GATEWAY_URL = os.environ["GATEWAY_URL"]
MODEL_ID = "anthropic.claude-3-5-sonnet-20241022-v2:0"

# The Strands `retrieve` tool reads this to know which Knowledge Base to query.
os.environ.setdefault("KNOWLEDGE_BASE_ID", "KB1234567890")

model = BedrockModel(model_id=MODEL_ID)


def gateway_transport():
    token = get_gateway_token()  # fetch an OAuth token for the gateway's JWT authorizer
    return streamablehttp_client(
        GATEWAY_URL, headers={"Authorization": f"Bearer {token}"}
    )


mcp_client = MCPClient(gateway_transport)

SYSTEM_PROMPT = (
    "You are a helpful internal assistant. Use the company tools to look up live "
    "data, and use the retrieve tool to ground answers in internal documentation. "
    "Cite what you looked up."
)


@app.entrypoint
def invoke(payload):
    user_message = payload.get("prompt", "")
    with mcp_client:
        tools = mcp_client.list_tools_sync() + [retrieve]
        agent = Agent(model=model, system_prompt=SYSTEM_PROMPT, tools=tools)
        result = agent(user_message)
    return {"result": result.message}


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

That's the whole agent. The @app.entrypoint decorator is what makes this deployable — BedrockAgentCoreApp wraps your function in the HTTP contract AgentCore Runtime expects, so you never touch the server plumbing. Inside, the model now has the company's MCP tools and the Knowledge Base at its disposal, and the loop decides which to reach for.

Deploying to AgentCore Runtime

With the agent written, the starter toolkit deploys it in two commands. configure inspects your entrypoint and generates the runtime config; launch builds the container, pushes it, and stands up the managed endpoint:

pip install bedrock-agentcore bedrock-agentcore-starter-toolkit strands-agents strands-agents-tools

agentcore configure -e agent.py
agentcore launch

When launch finishes, it prints the agent runtime ARN. That ARN is the stable address other services — including our chatbot — use to invoke the agent. AgentCore handles scaling, session isolation, and keeping the endpoint warm.

You can smoke-test it right from the CLI:

agentcore invoke '{"prompt": "What is the status of order 4815 and what does our returns policy say?"}'

If the tools and Knowledge Base are wired correctly, the agent will call get_order_status for the live data and retrieve for the policy, then combine both into one answer.

A Quick Chatbot

The payoff: a small terminal chatbot that talks to the deployed agent. The key detail is the session id — reuse the same runtimeSessionId across turns and AgentCore keeps the conversation context, so the agent remembers what you said earlier.

import json
import uuid

import boto3

AGENT_ARN = "arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/company-assistant-XXXX"

client = boto3.client("bedrock-agentcore")
session_id = str(uuid.uuid4())  # one id for the whole conversation

print("Company assistant ready. Ctrl-C to quit.\n")

while True:
    try:
        prompt = input("you › ").strip()
    except (EOFError, KeyboardInterrupt):
        print("\nbye")
        break

    if not prompt:
        continue

    response = client.invoke_agent_runtime(
        agentRuntimeArn=AGENT_ARN,
        runtimeSessionId=session_id,
        payload=json.dumps({"prompt": prompt}).encode(),
        qualifier="DEFAULT",
    )

    # The response streams back as byte chunks — collect and decode them.
    chunks = [chunk.decode("utf-8") for chunk in response.get("response", [])]
    answer = json.loads("".join(chunks))
    print(f"bot › {answer['result']}\n")

Run it, and you've got a working internal assistant:

you › what's the status of order 4815?
bot › Order 4815 shipped yesterday and is out for delivery, expected today.

you › and if it arrives damaged, what should the customer do?
bot › Per our returns policy, damaged items can be reported within 30 days for a
      full refund or replacement — here's the process...

The first answer came from the MCP order tool; the second came from the Knowledge Base. The agent decided which to use, and the session id tied the two turns together.

Putting It All Together

Step back and the whole thing is just a few well-bounded layers:

• A Knowledge Base grounds the agent in internal documents
• A Gateway exposes company APIs as MCP tools, handling auth on both sides
• The agent wires the model to those tools and docs with a decision loop
• AgentCore Runtime hosts it serverlessly behind a session-aware endpoint
• A CLI chatbot consumes it like any other API

The nice part is that none of this required managing a server, and each layer is swappable — add a new company API by creating one more gateway target, and every agent connected to the gateway can use it immediately. No redeploys, no glue code.

If you've already got models running on Bedrock, this is how you give them hands. Next time someone asks your assistant a question that spans a live system and your internal docs, it'll just handle it.

What Are Embeddings?

At their core, embeddings are dense vector representations of data — typically text, but they work for images, audio, and structured data too. Instead of representing a word or sentence as a sparse one-hot vector, embeddings map it into a continuous, high-dimensional space where semantic similarity becomes geometric proximity.

Think of it like this: if you embed the phrases "high credit risk" and "elevated default probability," they'll end up close together in vector space. Meanwhile, "low volatility" will be far away. This property is what makes embeddings so powerful for analysis.

# Example: Two semantically similar phrases will have similar embeddings
embedding_1 = model.encode("high credit risk")
embedding_2 = model.encode("elevated default probability")
embedding_3 = model.encode("low volatility")

# Cosine similarity between 1 and 2 will be high
# Cosine similarity between 1 and 3 will be low

Modern LLMs generate these embeddings as part of their architecture. The same model you trained in SageMaker can produce them directly.

How Embeddings Work

When you pass text through an LLM, the model processes it through multiple transformer layers. Each layer refines the representation, capturing increasingly abstract patterns. The final hidden states — or sometimes a pooled version of them — become the embedding.

Here's a simplified view of the process:

1. Tokenization: Break text into tokens (subwords or characters)
2. Token Embeddings: Map each token to a learned vector
3. Positional Encoding: Add information about token position
4. Transformer Layers: Process tokens through attention and feed-forward layers
5. Pooling: Aggregate token representations into a single vector (mean, max, or CLS token)

The result is a fixed-size vector (often 768 or 1024 dimensions for models like BERT, or up to 4096+ for larger models) that encodes the meaning of your input.

import torch
from transformers import AutoTokenizer, AutoModel

# Load a pre-trained model
tokenizer = AutoTokenizer.from_pretrained("sentence-transformers/all-MiniLM-L6-v2")
model = AutoModel.from_pretrained("sentence-transformers/all-MiniLM-L6-v2")

# Generate embedding
text = "Customer exhibits high transaction volatility"
inputs = tokenizer(text, return_tensors="pt", padding=True, truncation=True)

with torch.no_grad():
    outputs = model(**inputs)
    # Use mean pooling to get sentence embedding
    embedding = outputs.last_hidden_state.mean(dim=1)

print(embedding.shape)  # torch.Size([1, 384])

Using Embeddings for Risk Data Analysis

Now, let's connect this to something practical: analyzing risk data from your SageMaker pipeline. Suppose you've trained a model on financial transaction data, and you want to surface insights to users in a way that's intuitive and actionable.

Problem: Making Sense of Thousands of Risk Signals

You have thousands of risk events — fraud alerts, credit score changes, compliance flags. Users can't scroll through raw logs. They need a way to:

• Find similar incidents quickly
• Cluster related risks
• Ask questions in natural language
• Get summarized, ranked results

Solution: Embed Everything

Step 1: Generate embeddings for all your risk events.

import boto3
import json
from sentence_transformers import SentenceTransformer

# Initialize embedding model
embed_model = SentenceTransformer('all-MiniLM-L6-v2')

# Fetch risk data from S3 (output from your SageMaker pipeline)
s3 = boto3.client('s3')
response = s3.get_object(Bucket='my-bucket', Key='risk-events/latest.json')
risk_events = json.loads(response['Body'].read())

# Generate embeddings for each event description
embeddings = []
for event in risk_events:
    description = event['description']
    embedding = embed_model.encode(description)
    embeddings.append({
        'event_id': event['id'],
        'embedding': embedding.tolist(),
        'metadata': event
    })

# Store embeddings in a vector database or S3

Step 2: Build a semantic search layer.

When a user searches for "suspicious wire transfers," you embed their query and find the closest risk events in vector space.

import numpy as np
from sklearn.metrics.pairwise import cosine_similarity

# User query
query = "suspicious wire transfers"
query_embedding = embed_model.encode(query)

# Compute similarity to all stored embeddings
event_embeddings = np.array([e['embedding'] for e in embeddings])
similarities = cosine_similarity([query_embedding], event_embeddings)[0]

# Get top 5 most similar events
top_indices = similarities.argsort()[-5:][::-1]
results = [embeddings[i]['metadata'] for i in top_indices]

for result in results:
    print(f"Event: {result['description']} | Score: {similarities[top_indices[0]]:.3f}")

Using a Vector Database

For production, you'll want a proper vector database like Pinecone, Weaviate, or OpenSearch with k-NN. They handle indexing, approximate nearest neighbor search, and scaling.

from pinecone import Pinecone, ServerlessSpec

# Initialize Pinecone
pc = Pinecone(api_key="your-api-key")

# Create index
index = pc.Index("risk-embeddings")

# Upsert embeddings
vectors = [
    (e['event_id'], e['embedding'], e['metadata'])
    for e in embeddings
]
index.upsert(vectors=vectors)

# Query
query_embedding = embed_model.encode("high credit risk customers").tolist()
results = index.query(vector=query_embedding, top_k=10, include_metadata=True)

for match in results['matches']:
    print(f"{match['metadata']['description']} | Score: {match['score']:.3f}")

Building User-Friendly Outputs

Once you have embeddings in place, you can build interfaces that feel intelligent:

1. Semantic Search

Users type natural language queries and get relevant risk events instantly, ranked by semantic similarity.

2. Automatic Clustering

Group similar risks together without manual tagging. Run k-means or HDBSCAN on your embeddings to discover patterns.

from sklearn.cluster import KMeans

# Cluster risk events
kmeans = KMeans(n_clusters=10)
clusters = kmeans.fit_predict(event_embeddings)

# Add cluster labels to metadata
for i, event in enumerate(embeddings):
    event['metadata']['cluster'] = int(clusters[i])

3. Anomaly Detection

Identify outlier events by measuring distance to cluster centroids or using isolation forests on embeddings.

4. Conversational Queries

Let users ask complex questions like "Show me credit risks from Q4 that are similar to this flagged account." Embed the question, filter by metadata, and return results.

Integrating with Your SageMaker Pipeline

Here's how this fits into the pipeline we built before:

1. Training — Your SageMaker job produces a model that can generate embeddings
2. Batch Transform — Run batch inference to embed your entire risk dataset
3. Storage — Write embeddings to a vector database or S3
4. Endpoint — Deploy a SageMaker endpoint that embeds user queries in real time
5. Application — Your front-end calls the endpoint and searches the vector store

import sagemaker

# Deploy embedding model as SageMaker endpoint
estimator = sagemaker.estimator.Estimator(
    image_uri="123456789012.dkr.ecr.us-east-1.amazonaws.com/embedding-model:latest",
    role=role,
    instance_count=1,
    instance_type="ml.m5.large"
)

predictor = estimator.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.xlarge"
)

# Query the endpoint
import boto3
client = boto3.client("sagemaker-runtime")

response = client.invoke_endpoint(
    EndpointName=predictor.endpoint_name,
    ContentType="application/json",
    Body=json.dumps({"text": "high credit risk"})
)

embedding = json.loads(response["Body"].read())

Real-World Example: Risk Dashboard

Imagine a dashboard where analysts can:

• Type "show me fraud cases similar to case #12345"
• See a ranked list of similar incidents
• Click through to see full details
• Get an AI-generated summary of common patterns

Behind the scenes:

1. The query gets embedded via your SageMaker endpoint
2. A vector database returns the top matches
3. Metadata filters narrow down results (date range, severity, etc.)
4. Another LLM call summarizes the findings

The entire flow is powered by embeddings, and users interact with it like it's magic.

Best Practices

1. Choose the Right Model For domain-specific data (finance, healthcare), fine-tune an embedding model on your data. Generic models like all-MiniLM-L6-v2 work well out of the box, but custom training improves relevance.

2. Normalize and Store Metadata Embeddings capture semantics, but you still need filters (date, category, user ID). Store metadata alongside embeddings.

3. Monitor Drift As your data evolves, re-embed periodically. Embeddings from old models can become stale.

4. Hybrid Search Combine semantic search (embeddings) with keyword search (BM25) for best results. Tools like OpenSearch support this natively.

Conclusion

Embeddings turn messy, high-dimensional data into something you can reason about geometrically. They're not just a trick for similarity search — they're a fundamental tool for building intelligent systems that meet users where they are.

If you've already got a SageMaker pipeline running, adding embeddings is a natural next step. You go from serving predictions to serving understanding. And that's where the real value is.

Next time a user asks, "find risks like this one," you'll be ready.

The Pipeline at a Glance

The data flows like this:

1. AWS Glue extracts raw data and writes it as Parquet to S3
2. Amazon Athena queries and validates that data on demand
3. SageMaker Training Jobs consume the data and train the LLM
4. SageMaker Batch Transform runs batch inference for evaluation
5. SageMaker Endpoints serve the trained model in production
6. Downstream services call those endpoints for real-time inference

Each layer does one thing well. Let's go through them.

Extracting Data with AWS Glue

Glue is where the pipeline starts. A Glue Job pulls raw data from the source, applies transformations, and writes it out as Parquet files to an S3 bucket. Parquet is the right format here — it's columnar, compressed, and works seamlessly with everything downstream.

from awsglue.job import Job
from awsglue.context import GlueContext
from pyspark import SparkContext

sc = SparkContext()
glueContext = GlueContext(sc)
job = Job(glueContext)

raw_data = glueContext.create_dynamic_frame_from_catalog(
    database="my_database",
    table_name="raw_events"
)

glueContext.write_dynamic_frame_from_options(
    frame=raw_data,
    connection_type="s3",
    connection_options={
        "path": "s3://my-bucket/training-data/",
        "partitionKeys": ["date"]
    },
    format="parquet"
)

job.commit()

The job runs on a schedule, so the S3 bucket stays fresh without any manual intervention.

Querying with Amazon Athena

Once the Parquet files are in S3, Athena lets me query them with plain SQL — no cluster to spin up, no provisioning. I use it for two things: validating that the Glue transformation produced the right data, and as a lightweight source for feeding into training.

SELECT COUNT(*), MIN(date), MAX(date)
FROM training_data
WHERE date >= '2025-06-01';

Athena query results can be exported back to S3, which keeps the handoff to SageMaker clean and decoupled.

Training the LLM with SageMaker

This is the core of it. SageMaker Training Jobs handle the actual model training — provisioning GPU instances, running distributed training, and saving checkpoints. I use a custom container image that has the training script and dependencies baked in, and point it at the Parquet data in S3.

import sagemaker

session = sagemaker.Session()
role = sagemaker.get_execution_role()

estimator = sagemaker.estimator.Estimator(
    image_uri="123456789012.dkr.ecr.us-east-1.amazonaws.com/llm-trainer:latest",
    role=role,
    instance_count=2,
    instance_type="ml.p3.16xlarge",
    output_path="s3://my-bucket/model-output/"
)

estimator.fit({
    "train": "s3://my-bucket/training-data/",
    "validation": "s3://my-bucket/validation-data/"
})

When the job finishes, the trained model artifacts end up in output_path on S3. SageMaker takes care of the rest — scaling, monitoring, and logging.

Evaluating with Batch Transform

Before anything goes to production, I run the model against a held-out evaluation set. Batch Transform is perfect for this — it runs inference over an entire dataset in one pass, no persistent endpoint needed.

transformer = estimator.transformer(
    instance_count=1,
    instance_type="ml.m5.4xlarge",
    output_path="s3://my-bucket/batch-output/"
)

transformer.transform(
    data="s3://my-bucket/evaluation-data/",
    content_type="application/json",
    split_type="Line"
)
transformer.wait()

The predictions land in S3. I pull them into a notebook or Athena to compute metrics and decide whether the model is ready to deploy.

Deploying with SageMaker Endpoints

Once the model passes evaluation, I deploy it as a real-time endpoint. This gives other services a stable, managed URL to call for inference.

predictor = estimator.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.xlarge"
)

print(predictor.endpoint_name)
# e.g. llm-trainer-2026-02-04-12-30-00-000

SageMaker handles auto-scaling, health checks, and traffic management under the hood. The endpoint just stays up and ready.

Consuming the Endpoint

Other services in the stack call the endpoint directly over HTTPS. From their perspective, it's just an API — they don't need to know anything about the training setup or the underlying infrastructure.

import boto3

client = boto3.client("sagemaker-runtime")

response = client.invoke_endpoint(
    EndpointName="llm-trainer-2026-02-04-12-30-00-000",
    ContentType="application/json",
    Body=b'{"prompt": "Summarize the following text: ..."}'
)

result = response["Body"].read().decode("utf-8")

That's it. The consuming service gets back the model's response and can do whatever it needs with it.

Putting It All Together

The full pipeline runs with minimal babysitting:

• Glue keeps the training data fresh in S3
• Athena validates and explores it
• SageMaker trains new model versions as the data evolves
• Batch Transform gates what goes to production
• Endpoints serve the live model
• Downstream services consume it like any other API

It's a clean way to go from raw data to a production LLM on AWS. Each layer is independently testable, and the whole thing scales without you touching a single server. Definitely worth exploring if you're looking to get ML workloads running on AWS.

What is Netlify?

Netlify is a hosting platform designed specifically for static sites and Jamstack applications. It offers continuous deployment, global CDN, and many other features - all with a generous free tier.

Prerequisites

Before we begin, make sure you have:

• Your static site in a Git repository (GitHub, GitLab, or Bitbucket)
• A Netlify account (it's free!)

Deployment Steps

1. Connect Your Repository

Log into Netlify and click "Add new site" → "Import an existing project". Connect your Git provider and select your repository.

2. Configure Build Settings

Netlify will often auto-detect your build settings, but you'll want to verify:

• Build command: npm run build (or your specific build command)
• Publish directory: _site (or wherever your build outputs)

3. Deploy!

Click "Deploy site" and watch the magic happen. Netlify will:

1. Clone your repository
2. Install dependencies
3. Run your build command
4. Deploy the output to their global CDN

Continuous Deployment

The best part? Every time you push to your main branch, Netlify automatically rebuilds and deploys your site. No manual intervention needed!

Custom Domain

Once deployed, you can:

• Use the free .netlify.app subdomain
• Add your own custom domain
• Get free SSL certificates automatically

Additional Features

Netlify offers many powerful features:

• Form handling - Collect form submissions without backend code
• Functions - Add serverless functions to your static site
• Split testing - A/B test different versions
• Deploy previews - Every PR gets its own preview URL

Tips for Success

1. Make sure your .gitignore excludes node_modules and build output
2. Set up environment variables in Netlify's dashboard if needed
3. Use netlify.toml for advanced configuration

Conclusion

Netlify has made web deployment accessible to everyone. Within minutes, you can have your site live on a global CDN with HTTPS. Give it a try - you'll wonder how you ever deployed sites any other way!

Simplicity and Flexibility

Eleventy doesn't force you into a specific template language or structure. You can use Markdown, Nunjucks, Liquid, JavaScript, or even mix and match. This flexibility was a big selling point for me.

Zero Configuration to Start

You can literally get started with just a markdown file. As your needs grow, you can add configuration, but you're not forced to deal with complex setup from day one.

// .eleventy.js - simple config example
module.exports = function(eleventyConfig) {
  eleventyConfig.addPassthroughCopy("css");
  return {
    dir: {
      input: "src",
      output: "_site"
    }
  };
};

Performance

Eleventy is incredibly fast. Build times are measured in milliseconds for small to medium sites. This makes the development experience smooth and enjoyable.

JavaScript Ecosystem

Since Eleventy is built on Node.js, I can tap into the entire npm ecosystem for plugins and tools. This is a huge advantage if you're already familiar with JavaScript.

Great Documentation

The Eleventy docs are comprehensive and well-organized. There's also a helpful community and lots of starter projects to learn from.

Perfect for Blogs

With built-in support for collections, pagination, and data processing, Eleventy is particularly well-suited for blogs and content-heavy sites.

Conclusion

If you're looking for a static site generator that's powerful yet simple, I highly recommend giving Eleventy a try. It's been a pleasure to work with, and I'm excited to keep building with it.

What is a Static Site Generator?

A static site generator is a tool that generates a full static HTML website based on raw data and templates. Unlike dynamic content management systems, static sites are pre-built and served as-is to users.

Benefits of Static Sites

Speed

Static sites are incredibly fast because there's no database queries or server-side processing needed. The HTML is pre-generated and ready to serve.

Security

With no database or server-side code execution, there's a much smaller attack surface. Static sites are inherently more secure.

Scalability

Static files can be easily cached and distributed through CDNs, making them highly scalable without complex infrastructure.

Cost-Effective

Hosting static files is cheap. Services like Netlify, Vercel, and GitHub Pages even offer free hosting for static sites.

Popular Static Site Generators

Some popular options include:

• Eleventy - Flexible and JavaScript-based
• Hugo - Extremely fast, written in Go
• Gatsby - React-based with a rich plugin ecosystem
• Next.js - Can generate static sites with React

Getting Started

The best way to learn is by doing. Pick a static site generator that fits your tech stack and start building. Most have excellent documentation and starter templates to help you get up and running quickly.

Happy building!