DEV Community: AWS Community Builders

Event-driven media intelligence with AWS Step Functions and Bedrock

Collins Ushi — Sat, 18 Apr 2026 19:00:05 +0000

Every modern product that handles user-generated media; say a podcast platform, a video CMS, a learning product, a content-moderation layer - eventually runs into the same problem. A file lands in storage, and now the system needs to understand it: extract the speech, identify what's on screen, summarise it, tag it, and make it queryable. Doing that on a single server is expensive, fragile, and impossible to scale predictably.

This article walks through a serverless design for that problem on AWS. The pipeline ingests audio, video, or images, runs them through managed AI services (Rekognition, Transcribe, Bedrock), and persists the extracted intelligence into DynamoDB for downstream use - all without operating a single EC2 instance. The focus is on why each piece exists and how it fits together, not just naming the services.

Why serverless is the right shape for this problem

Media workloads are spiky and long-running in a way that punishes traditional compute.
A single 45 minute video can take several minutes to transcribe; ten of them landing at once shouldn't require keeping ten servers warm all day. The workflow also fans out naturally; transcription, visual analysis, and thumbnail generation are independent steps that want to run in parallel.

Three properties of a serverless, event-driven design map cleanly onto this:

Elastic concurrency: Lambda, Rekognition, and Transcribe scale out on demand. You pay per request and per second of processing, not for idle capacity.
Native asynchrony: Step Functions turn a multi-stage AI pipeline into a declarative state machine with retries, timeouts, and parallel branches built in - no message queues or cron jobs to wire by hand.
Composability: Every stage is a managed service with a clear IAM contract. Swapping Transcribe for a different ASR provider, or Bedrock for a self-hosted model, is a local change.

Architecture at a glance

The pipeline has five logical layers:

Ingestion: S3 receives the upload.
Event routing: EventBridge picks up the Object Created event and triggers the workflow.
Orchestration: Step Functions coordinates the processing stages.
Intelligence: Lambda functions call Rekognition, Transcribe, and Bedrock to extract structured data.
Persistence: DynamoDB stores the metadata, keyed by media ID, for downstream querying.

Walking through each component

1. S3 as the ingestion surface
The pipeline starts where most media pipelines start: a single S3 bucket configured for object uploads. A few things are worth doing at this layer that are easy to skip:

Separate buckets (or at least prefixes) for raw input and processed artefacts. Keeping incoming/ and processed/ distinct means lifecycle rules, replication, and IAM policies stay clean as the system grows.
Multipart upload configuration. Large video files need multipart uploads; the default S3 SDKs handle this, but the bucket should have a lifecycle rule to abort incomplete multipart uploads after N days, or costs quietly accumulate.
Server-side encryption and versioning. If the system ever handles sensitive content (KYC video, medical, private podcasts), this is non-negotiable.

2. EventBridge as the event router
You could wire S3 notifications directly to a Lambda, it works but could be rigid. Putting EventBridge between S3 and the rest of the pipeline gives you something much more valuable: a declarative event bus where rules pattern-match on the event payload.
The immediate benefit is filtering. A rule can fire the pipeline only for specific prefixes, file extensions, or size ranges:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": { "name": ["media-ingest-prod"] },
    "object": {
      "key": [{ "prefix": "incoming/" }],
      "size": [{ "numeric": [">", 1024] }]
    }
  }
}

The longer-term benefit is that the event bus becomes a seam. When a second consumer appears, say; an analytics team that wants to count uploads per tenant, they attach their own rule without touching the core pipeline.

3. Step Functions as the orchestrator
Interestingly, this appears to be the heart of the design. Step Functions expresses the pipeline as a JSON (or YAML) state machine, and the payoff is enormous: retries with exponential backoff, per-state timeouts, parallel branches, and error paths are all configuration rather than code.

A reasonable shape for the state machine looks like this:

ClassifyMedia; a Lambda that inspects the MIME type and branches on whether the file is image, audio, or video.

ParallelAnalysis; a Parallel state that runs, for a video:

StartTranscriptionJob (Transcribe) on the extracted audio track.
StartLabelDetection and StartContentModeration (Rekognition Video) on the visual track.

WaitForCompletion; asynchronous Rekognition and Transcribe jobs publish completion events; the state machine uses .waitForTaskToken or polling to resume once results are ready.

SummariseWithBedrock; a Lambda that sends the transcript and label set to a Bedrock model and receives a structured summary.

PersistMetadata; writes the final object into DynamoDB.

CatchAll; a catch block that routes any failure to a dead-letter state, writes the error into a failures table, and optionally notifies via SNS.

The thing to internalise is that Step Functions is not "just" a workflow visualiser, it's the reason the pipeline is resilient. A transient Bedrock throttling error retries automatically; a malformed file fails into the catch branch instead of silently leaving the system in a half-processed state.

4. Lambda as the glue
Each state in the machine is either a direct service integration (Step Functions can call Rekognition, Transcribe, and DynamoDB without a Lambda in between) or a small Lambda function for the bits that need custom logic: MIME classification, payload shaping before Bedrock, post-processing transcripts.

A rule of thumb: prefer direct service integrations wherever possible. Every Lambda you add is code to test, package, monitor, and patch. The direct integrations are zero-code and zero-cold-start.

5. The AI layer: Rekognition, Transcribe, and Bedrock

Each of these handles a different modality:

Amazon Rekognition handles visual analysis, object and scene labels, celebrity detection, content moderation flags, and text-in-image (OCR) for video and still images. For video, jobs are asynchronous: you start a job and receive an SNS notification when results are ready.
Amazon Transcribe turns audio into a structured transcript with timestamps, speaker diarisation, and optional custom vocabularies. For a podcast pipeline, custom vocabularies dramatically improve accuracy on domain-specific terms (product names, acronyms, people).
Amazon Bedrock is where the "AI-powered" part lives in the modern sense. Given the raw transcript and Rekognition labels, a Bedrock model (Claude, Nova, Llama, depending on preference) produces the artefacts downstream systems actually want: a one-paragraph summary, chapter markers with timestamps, topic tags, a short SEO description, a list of named entities.

The prompt design for the Bedrock step deserves its own attention. A pattern that works well is to ask the model for a strict JSON response against a schema you define, rather than free-form text so the persistence step can store it without fragile parsing:

You will receive a transcript and a list of visual labels from a video.

Return ONLY a JSON object with this exact shape:

{
  "summary": string (max 80 words),
  "chapters": [{ "title": string, "start_seconds": number }],
  "topics": string[],
  "entities": { "people": string[], "organisations": string[], "places": string[] }
}

6. DynamoDB as the metadata store
DynamoDB is the right fit here because the access patterns are simple and the shape is predictable. A single table keyed by media_id (partition key) with created_at as the sort key handles the primary "fetch processing result for this upload" pattern. A GSI on tenant or status lets you answer "show me all videos processed in the last 24 hours" without scanning.
Keep the Bedrock-generated summary and the raw transcript reference separate: summaries are small and hot, transcripts can be large and belong back in S3 with just a pointer in DynamoDB.

Putting it together: an end-to-end request

Concretely, here's what happens when a user uploads a 20 minute interview video:

The client performs a multipart upload to s3://media-ingest-prod/incoming/<tenant-id>/<uuid>.mp4.
S3 emits an Object Created event to the default event bus.
An EventBridge rule matches on the incoming/ prefix and starts a Step Functions execution, passing the bucket and key as input.
The state machine classifies the file as video, then fans out in parallel: Transcribe starts on the audio track, Rekognition starts label detection and content moderation on the visual track.
Both jobs complete asynchronously; the state machine resumes via task tokens.
A Lambda gathers the transcript and labels, constructs a Bedrock prompt, and receives a structured JSON summary.
A final step writes the full metadata record to DynamoDB and moves the original file from incoming/ to processed/.
Any failure along the way is caught, logged to a failures table, and surfaced via an SNS topic that pages the on-call engineer if it crosses a threshold.

The whole thing runs without a single long-lived server.

Things that bite you in production

Diagrams make this look clean. A few practical notes from taking a pipeline like this to production:

IAM is the hard part. Each Lambda and each Step Functions state needs a narrowly scoped role. Do not share a single execution role across the pipeline, one overly broad policy is how s3:GetObject * turns into a security incident.
Bedrock throttling is real. Regional model quotas can and will throttle you under load. Wrap the Bedrock call in a retry policy with jitter, and consider provisioned throughput if the pipeline is on a critical path.
Large transcripts exceed context windows. A two-hour podcast transcript can be larger than a single model context. Chunk on speaker turns or paragraph boundaries, summarise each chunk, then do a reduce pass - a classic map-reduce over text.
Cost lurks in the idle corners. The obvious costs (Transcribe per audio-minute, Rekognition per video-minute, Bedrock per token) are easy to forecast. The easily-missed ones are Step Functions state transitions on high-volume pipelines and CloudWatch Logs ingestion if you log every event verbatim. Sample your logs.
Observability needs to span the whole flow. A single correlation ID; the S3 object key or a generated media ID should travel through every Lambda, Step Functions state, and DynamoDB record, so that when something breaks you can reconstruct exactly what happened with a single query.

Where this design shines

The same skeleton supports a surprising range of products with only the Bedrock prompt and the DynamoDB schema changing:

Podcast platforms that want automatic show notes, chapter markers, and searchable transcripts.

Video intelligence tools for media libraries tagging, searching, and moderating large content archives.

Learning and compliance products that need to extract key points and generate quizzes from lecture recordings.

Content moderation systems combining Rekognition's moderation labels with LLM-based policy reasoning for edge cases.

Customer support analytics processing recorded calls to surface sentiment, topics, and escalation signals.

Where to take it next

Once the base pipeline is in place, the interesting extensions are mostly at the edges:

Realtime mode. Swap batch Transcribe for Transcribe Streaming and emit partial results over WebSockets for live captioning.
Semantic search. Pipe the Bedrock-generated summary and transcript chunks into an embedding model and store the vectors in OpenSearch or a vector store now the media library is searchable by meaning, not just tags.
Human-in-the-loop review. For content moderation or compliance, route low-confidence Bedrock decisions to an SQS queue backed by a reviewer UI, and feed the decisions back as training data.
Multi-tenant isolation. Use S3 access points and dynamic Step Functions execution roles to enforce tenant boundaries at the infrastructure layer rather than in application code.

My closing thought

The interesting thing about this architecture isn't any individual service; it's that the boundaries between them are event-driven and declarative. You can reason about the system by looking at the state machine definition and the EventBridge rules, not by reading through layers of application code. That's what makes it durable: when the product team asks for a new capability ("can we also detect languages automatically?"), you add a state, not a service.

Serverless isn't the right answer for every system, but for "something landed in storage, now go understand it," it's hard to beat. The pipeline scales with the work, costs track usage, and the blast radius of any one failure is a single execution not the whole platform.

Resurface Claude Code Usage Across Your Team with CloudWatch OTEL (No Lambda)

Gabriel Koo — Sat, 18 Apr 2026 12:59:36 +0000

I've been building AI tooling infrastructure to empower a team of 50+ software engineers to do vibe coding safely. We went from 3 engineers using AI full-time to 50+ in 6 months — including non-engineers. (I co-presented on this journey at AgentCon Hong Kong 2026.)

One thing we learned: you can't improve what you can't measure. Once you give a team AI coding tools, you want visibility into how they're being used — not to evaluate individual engineers, but to understand adoption patterns. Which tools are people reaching for? How large are the prompts? What tool calls are being made? Making these metrics visible to everyone helps the team learn from each other and helps champions pull others forward.

This post is about the plumbing: how to get that telemetry data from coding agents into CloudWatch with minimal infrastructure.

"But we already have an LLM gateway." If your team routes AI traffic through a gateway like LiteLLM or AWS Bedrock, you already have token-level usage data. But if your engineers are on coding plans — Claude Team/Max, OpenCode Go, GitHub Copilot seats, ChatGPT Codex — the LLM calls bypass your gateway entirely. You lose visibility into the interesting stuff: how many tool calls per session, prompt sizes, which tools are being invoked, who's active at what times. That's where OTEL telemetry fills the gap.

AI coding tools are shipping with built-in OpenTelemetry support. Claude Code, Claude CoWork, GitHub Copilot, Gemini CLI, and Cursor (via hooks) all export metrics, traces, and log events over OTLP/HTTP — token counts, tool durations, model latency, the works. Kiro has an open feature request for native OTEL support too.

There's one catch: CloudWatch's OTLP endpoints require SigV4 signing. These tools' OTEL SDKs can't do that. Neither can most OTEL SDKs without an AWS-specific exporter or a collector sidecar.

The usual fix is a Lambda function that receives OTLP, signs it, and forwards it. That means cold starts, packaging, and another thing to maintain.

Here's a simpler way: API Gateway REST API with AWS Service Integration. APIGW signs the request with SigV4 using an execution role. No Lambda. No collector. No code.

Timeline: CloudWatch has supported OTLP ingestion for traces and logs for some time (availability varies by region — check the OTLP endpoints doc). Native OTLP metrics support launched April 2, 2026 in public preview, completing all three pillars of observability via OTLP.

Architecture

AI Coding Tool (OTEL SDK)
  ↓ OTLP/HTTP + x-api-key
API Gateway REST API
  ├→ POST /v1/metrics  → AWS Integration → monitoring (SigV4) → CloudWatch Metrics
  ├→ POST /v1/traces   → AWS Integration → xray (SigV4)      → X-Ray / CloudWatch Logs
  └→ POST /v1/logs     → AWS Integration → logs (SigV4)       → CloudWatch Logs

The client sends standard OTLP/HTTP requests with an API key. APIGW validates the key, assumes an IAM role, signs the request with SigV4, and forwards it to the CloudWatch OTLP endpoint. That's it.

Why This Works

API Gateway REST API has an integration type called AWS Service Integration. It can call any AWS service API and sign the request with SigV4 using an execution role. The CloudWatch OTLP endpoints are standard AWS service endpoints:

Signal	Endpoint	Service
Metrics	`monitoring.{region}.amazonaws.com/v1/metrics`	`monitoring`
Traces	`xray.{region}.amazonaws.com/v1/traces`	`xray`
Logs	`logs.{region}.amazonaws.com/v1/logs`	`logs`

APIGW's integration URI format maps directly:

arn:aws:apigateway:{region}:monitoring:path/v1/metrics
arn:aws:apigateway:{region}:xray:path/v1/traces
arn:aws:apigateway:{region}:logs:path/v1/logs

Setup

The full infrastructure is defined in a CloudFormation template (link at the bottom). Here's what it creates:

IAM Execution Role

APIGW needs an IAM role to sign requests to CloudWatch. The policy is scoped to only the actions and resources needed for OTLP ingestion:

Parameters:
  OtlpLogGroupName:
    Type: String
    Default: "otlp-logs"
    Description: CloudWatch Logs log group for OTLP log ingestion

Resources:
  OtlpExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: apigateway.amazonaws.com
            Action: sts:AssumeRole
      Policies:
        - PolicyName: otlp-metrics
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - cloudwatch:PutMetricData
                Resource: "*"
        - PolicyName: otlp-traces
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - xray:PutTraceSegments
                  - xray:PutTelemetryRecords
                Resource: "*"
        - PolicyName: otlp-logs
          PolicyDocument:
            Statement:
              - Effect: Allow
                Action:
                  - logs:PutLogEvents
                  - logs:CreateLogStream
                  - logs:DescribeLogStreams
                Resource:
                  - !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:${OtlpLogGroupName}:*"

Note: cloudwatch:PutMetricData doesn't support resource-level ARNs. The cloudwatch:namespace condition key exists but does not apply to the OTLP ingestion path — metrics are accepted regardless of namespace. X-Ray PutTraceSegments also doesn't support resource-level restrictions. Logs permissions are scoped to a specific log group via the OtlpLogGroupName parameter.

API Gateway with AWS Service Integration

Each OTLP signal gets its own resource with an AWS integration:

MetricsMethod:
  Type: AWS::ApiGateway::Method
  Properties:
    HttpMethod: POST
    AuthorizationType: NONE
    ApiKeyRequired: true
    Integration:
      Type: AWS
      IntegrationHttpMethod: POST
      Uri: !Sub "arn:aws:apigateway:${AWS::Region}:monitoring:path/v1/metrics"
      Credentials: !GetAtt OtlpExecutionRole.Arn
      PassthroughBehavior: WHEN_NO_MATCH
      ContentHandling: CONVERT_TO_TEXT

Same pattern for /v1/traces (service: xray) and /v1/logs (service: logs).

API Key Authentication

Protect the endpoint with an API key so only your tools can send telemetry:

ApiKey:
  Type: AWS::ApiGateway::ApiKey
  Properties:
    Enabled: true

UsagePlan:
  Type: AWS::ApiGateway::UsagePlan
  Properties:
    ApiStages:
      - ApiId: !Ref Api
        Stage: !Ref Stage

Configure Your Tools

The proxy works with any tool that supports standard OTEL environment variables. Here's how to configure each:

Disclaimer: I personally use Claude Code routed through a custom LLM gateway (not a coding plan), since some coding plans aren't available in the region I live in. The configurations below are based on each tool's official documentation — your mileage may vary.

Claude Code

Official monitoring docs

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/json
export OTEL_EXPORTER_OTLP_ENDPOINT=https://xxx.execute-api.us-west-2.amazonaws.com/prod
export OTEL_EXPORTER_OTLP_HEADERS=x-api-key=your-api-key
export OTEL_SERVICE_NAME=claude-code

For short-lived tasks, lower the export interval so data flushes before the process exits:

export OTEL_METRIC_EXPORT_INTERVAL=1000
export OTEL_LOGS_EXPORT_INTERVAL=1000

For traces (beta):

export CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1
export OTEL_TRACES_EXPORTER=otlp
export OTEL_TRACES_EXPORT_INTERVAL=1000

Enforcing OTEL across your team: Claude Code supports managed settings via managed-settings.json, deployable through MDM (Jamf, Intune, etc.). This lets you enforce OTEL configuration org-wide — engineers don't need to set environment variables manually, and they can't opt out.

Claude CoWork (Team & Enterprise)

CoWork monitoring docs — configure via Admin Settings → Cowork → Monitoring:

OTLP endpoint: your APIGW URL
OTLP protocol: http/json
OTLP headers: x-api-key=your-api-key

CoWork streams user prompts, tool/MCP invocations, file access, human approval decisions, and API request details. It shares the same OTel event schema as Claude Code via the Claude Agent SDK — you can distinguish them by terminal.type (cowork vs cli).

GitHub Copilot CLI

Copilot CLI OTel reference — available since Copilot CLI 1.0.4:

export COPILOT_OTEL_ENDPOINT=https://xxx.execute-api.us-west-2.amazonaws.com/prod
export COPILOT_OTEL_HEADERS=x-api-key=your-api-key

Gemini CLI

Gemini CLI telemetry docs

export GEMINI_CLI_OTEL_EXPORT_ENDPOINT=https://xxx.execute-api.us-west-2.amazonaws.com/prod

Cursor (via Hooks)

Cursor doesn't have native OTEL export yet, but the community cursor-otel-hook project captures agent activity via Cursor's hook system and exports traces to any OTLP endpoint. Configure via otel_config.json:

{
  "OTEL_EXPORTER_OTLP_ENDPOINT": "https://xxx.execute-api.us-west-2.amazonaws.com/prod/v1/traces",
  "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json",
  "OTEL_EXPORTER_OTLP_HEADERS": { "x-api-key": "your-api-key" }
}

What You Get

CloudWatch receives standard OTLP data. For Claude Code specifically:

Metrics: claude_code.token.usage (by token.type: input/output/cache_read/cache_creation), claude_code.cost.usage (USD), claude_code.session.count, claude_code.lines_of_code.count
Traces (beta): Spans linking each user prompt → API requests → tool executions
Log events: claude_code.user_prompt, claude_code.tool_decision, claude_code.tool_result, claude_code.api_request — all tagged with session.id and service.name=claude-code

Here's what real Claude Code log events look like after flowing through the proxy into CloudWatch Logs. This is actual data from an E2E test — a single prompt that triggered a Bash tool call:

claude_code.user_prompt — emitted when the user sends a prompt:

{
  "resource": {
    "attributes": {
      "host.arch": "arm64",
      "os.type": "linux",
      "service.name": "claude-code",
      "service.version": "2.1.114",
      "os.version": "6.17.0-1010-aws"
    }
  },
  "scope": {
    "name": "com.anthropic.claude_code.events",
    "version": "2.1.114"
  },
  "body": "claude_code.user_prompt",
  "attributes": {
    "event.sequence": 0,
    "user.id": "1c257d04...",
    "prompt_length": "40",
    "terminal.type": "non-interactive",
    "event.name": "user_prompt",
    "event.timestamp": "2026-04-18T11:23:13.187Z",
    "prompt": "<REDACTED>",
    "session.id": "846ab649-8bba-471e-8ec5-8756116d0840",
    "prompt.id": "88475ee2-59c2-4137-9201-5540c6a6cad1"
  }
}

claude_code.tool_result — emitted after each tool execution:

{
  "body": "claude_code.tool_result",
  "attributes": {
    "tool_name": "Bash",
    "tool_result_size_bytes": "899",
    "tool_input": "{\"command\":\"ls\",\"description\":\"List files in current directory\"}",
    "duration_ms": "95",
    "success": "true",
    "session.id": "846ab649-8bba-471e-8ec5-8756116d0840",
    "prompt.id": "88475ee2-59c2-4137-9201-5540c6a6cad1"
  }
}

claude_code.api_request — emitted after each API call with token counts and cost:

{
  "body": "claude_code.api_request",
  "attributes": {
    "model": "claude-sonnet-4-5-20250929",
    "input_tokens": "142",
    "output_tokens": "61",
    "cache_read_tokens": "0",
    "cache_creation_tokens": "25848",
    "cost_usd": "0.098271",
    "duration_ms": "4950",
    "speed": "normal",
    "session.id": "846ab649-8bba-471e-8ec5-8756116d0840",
    "prompt.id": "88475ee2-59c2-4137-9201-5540c6a6cad1"
  }
}

All events share the same prompt.id, linking them into a single interaction. The event.sequence field orders events within a prompt. Every record carries service.name=claude-code in resource attributes, so isolating Claude Code telemetry in a mixed pipeline is trivial — just filter on that in CloudWatch Logs Insights:

fields @timestamp, body, attributes.model, attributes.cost_usd, attributes.duration_ms
| filter resource.attributes.`service.name` = 'claude-code'
| filter body = 'claude_code.api_request'
| sort @timestamp desc

Region Availability

CloudWatch OTLP endpoints are available in most regions but not all. The OTLP metrics preview launched in 5 regions:

Signal	Regions	Docs
Metrics (preview)	us-east-1, us-west-2, ap-southeast-1, ap-southeast-2, eu-west-1	Announcement
Traces	Most commercial regions	OTLP Endpoints
Logs	Most commercial regions	OTLP Endpoints

Tested and confirmed:

Region	Metrics	Traces	Logs
us-east-1	✅	✅	✅
us-west-2	✅	✅	✅
ap-southeast-1	✅	✅	✅
ap-east-1 (Hong Kong)	❌	❌	❌

If your primary region doesn't support it, deploy the proxy in a supported region. The APIGW endpoint is accessible from anywhere.

For the full list of CloudWatch service endpoints by region, see the AWS General Reference.

Gotchas

XRay traces require manual setup. The CloudFormation template creates the proxy endpoints, but X-Ray traces need two additional steps that aren't in the template:

Set CloudWatch Logs as the trace segment destination:

aws xray update-trace-segment-destination --destination CloudWatchLogs

Create a CloudWatch Logs resource policy allowing X-Ray to write to the aws/spans log group:

aws logs put-resource-policy \
  --policy-name XRayAccessPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"xray.amazonaws.com"},"Action":["logs:PutLogEvents","logs:CreateLogGroup","logs:CreateLogStream"],"Resource":"*"}]}'

Without these, traces will return AccessDeniedException.

CloudWatch Logs supports bearer token auth. The /v1/logs endpoint supports bearer token authentication without SigV4 — but only for logs. Metrics and traces still require SigV4, which is why the APIGW proxy is needed for a unified endpoint.

Use http/json, not http/protobuf. CloudWatch accepts both formats, but API Gateway's CONVERT_TO_TEXT content handling can corrupt binary protobuf payloads in transit. Set OTEL_EXPORTER_OTLP_PROTOCOL=http/json to avoid this. JSON is also easier to debug in APIGW execution logs. Most coding tools default to protobuf, so you'll need to override this explicitly.

API Gateway payload limit. REST API has a 10MB payload limit. OTLP batches from coding tools are well under this, but keep it in mind if you're aggregating from multiple sources. CloudWatch's own limits are 1MB for metrics and logs, 5MB for traces (full limits).

REST API, not HTTP API. Only REST API supports the AWS integration type needed for SigV4 service proxying. HTTP API does not.

Cost

This is about as cheap as it gets for a telemetry pipeline:

Component	Cost
API Gateway	~$3.50 / million requests
CloudWatch Metrics	Standard CW pricing (free during OTel metrics preview)
CloudWatch Logs	Standard CW pricing
Lambda	$0 (there is none)

No idle cost. No provisioned capacity. Pure pay-per-request.

For comparison: a Lambda-based OTLP forwarder would add ~$0.20/million invocations plus compute time, but gives you retry logic and transformation capabilities. At typical coding agent volumes (a few hundred requests/day per developer), the cost difference is negligible — the real win is operational simplicity.

When NOT to Use This

This proxy is optimized for simplicity. It's the right choice for low-to-moderate telemetry volumes from coding agents and developer tools. But it has tradeoffs:

Approach	Complexity	Cost	Retries	Multi-destination	Transformation
This proxy (APIGW)	Minimal	~$3.50/M req	❌	❌	❌
OTel Collector	Medium	Compute cost	✅	✅	✅
Lambda forwarder	Medium	~$0.20/M + compute	✅	✅	✅
ADOT SDK (in-app)	Low	Free (SigV4 native)	✅	❌	❌
SaaS (Datadog, etc.)	Low	$$$	✅	N/A	✅

Consider an OTel Collector or Lambda forwarder instead if you need:

High throughput — thousands of requests/second from many sources
Retry and buffering — this proxy is fire-and-forget; if CloudWatch returns an error, the data is lost. OTEL SDKs have built-in retry, but only for transient failures
Multi-destination routing — fan out to CloudWatch + Datadog + S3 simultaneously
Payload transformation — filter, enrich, or redact telemetry before ingestion
Compliance requirements — audit trails, guaranteed delivery, or data residency controls

For most coding agent monitoring use cases (a team of 5-50 developers), this proxy handles the volume comfortably.

Security Considerations

The proxy uses API key authentication — simple but not the strongest option. Here's how to harden it:

Attach AWS WAF to the REST API. Add rate limiting, IP allowlisting, or geo-blocking to prevent abuse. A single WAF WebACL with a rate-based rule (e.g., 1000 req/5min per IP) costs ~$6/month and stops most abuse patterns.

Rotate API keys. APIGW supports multiple API keys per usage plan. Create a new key, distribute it, then disable the old one — zero downtime rotation.

Consider IAM auth for internal use. If your tools run inside AWS (EC2, ECS, Lambda), switch AuthorizationType from NONE to AWS_IAM and drop the API key entirely. The caller signs requests with SigV4 using their IAM role — no shared secrets. This doesn't work for external tools like Claude Code on developer laptops, but it's ideal for CI/CD pipelines or server-side agents.

Egress control. If you're running coding agents in a controlled environment, restrict outbound traffic to only your APIGW endpoint. This prevents telemetry from leaking to unauthorized collectors.

Beyond Coding Agents

This proxy works with any OTEL SDK that supports OTLP/HTTP. If your tool can set OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS, it can ship telemetry to CloudWatch through this proxy.

Potential use cases:

AI coding agents (Claude Code, CoWork, Copilot, Cursor, Gemini CLI) — track token usage, costs, and tool calls across your org
Internal tools — ship metrics without embedding AWS credentials in client apps
CI/CD pipelines — export build/test telemetry to CloudWatch
On-premises services — send OTLP from outside AWS without running ADOT Collector

For apps running inside AWS with IAM roles available, consider the ADOT SDK for collector-less telemetry with native SigV4 signing — no proxy needed.

Source Code & One-Click Deploy

The CloudFormation template and full documentation are on GitHub:

👉 gabrielkoo/otlp-cloudwatch-proxy

One-click deploy to supported regions:

Region	Deploy
US East (N. Virginia)
US West (Oregon)
Asia Pacific (Singapore)
Asia Pacific (Sydney)
Europe (Ireland)

Built and validated on a Saturday morning with Claude Code + OpenClaw. Zero Lambda functions were harmed in the making of this article.

AWS Data & AI Stories #02: Amazon Bedrock Data Automation

Sedat SALMAN — Sat, 18 Apr 2026 05:01:56 +0000

In the first article, I talked about multimodal AI at a high level.

Now it is time to go one step deeper.

When we say multimodal AI, one of the first real challenges is not the model itself. The first challenge is the data. In most environments, the input is messy, unstructured, and spread across different formats such as documents, images, audio, and video. Amazon Bedrock Data Automation, or BDA, is designed for exactly this problem: extracting useful insights from unstructured multimodal content and turning it into structured output that applications can use.

For me, BDA is not the “chat” layer. It is the processing layer.

That is what makes it important.

What is Amazon Bedrock Data Automation?

Amazon Bedrock Data Automation is a managed AWS capability that automates insight generation from unstructured content such as documents, images, audio, and video. Instead of building separate extraction pipelines for each format, you can use BDA to generate structured outputs from multimodal input in a more consistent way.

This is useful because many AI projects fail at the beginning.

Not because the model is weak, but because the source data is not ready.

Think about a few common examples:

scanned PDFs
invoices
screenshots
call recordings
inspection videos
photos from the field
reports with mixed text and visuals

These are all valuable, but none of them are naturally clean inputs for downstream AI.

Why does BDA matter?

Because AI systems need structure.

Before you build search, RAG, analytics, or assistants, you usually need to answer a simpler question:

How do I turn raw content into usable information?

That is where BDA fits.

AWS describes BDA as a service that can produce both standard output and custom output depending on the use case. Standard output gives predefined insights for a data type, while custom output lets you define tailored extraction logic. This makes BDA useful not only for generic processing, but also for business-specific workflows.

So in practical terms, BDA can help when you want to:

extract content from complex documents
summarize audio or video
generate structured metadata
prepare content for retrieval
feed another AI workflow

How I would position BDA in an AWS architecture

I would place BDA near the beginning of the workflow.

A simple view looks like this:

Input data → BDA processing → structured output → storage/indexing → retrieval/generation

This is also how AWS examples position it. In AWS guidance and solution examples, BDA is commonly used after content lands in S3, and before services such as Knowledge Bases, vector stores, or agentic applications use the extracted results.

So if Part 1 was about multimodal AI, Part 2 is about making multimodal content usable.

Main concepts to understand

There are two core ideas in BDA that matter most: projects and blueprints.

1. Projects

A project is the main configuration container in BDA. AWS documentation describes it as the grouping that holds standard and optional custom output settings for processing. When you call the async API with a project ARN, BDA uses that project’s configuration to process the file and produce the defined outputs.

In simple terms, a project is where you define how BDA should behave for your use case.

2. Blueprints

Blueprints are what make custom extraction possible. AWS documentation explains that blueprints define the extraction logic and output format for custom outputs, allowing you to tailor BDA to your own business fields and data structures.

This is one of the most valuable parts of BDA.

Because in real projects, we usually do not want only generic output. We want specific fields, specific structure, and specific business meaning.

For example:

invoice number
customer name
incident category
equipment ID
inspection result
priority level

That is where blueprints become important.

Standard output vs custom output

This is one of the most important design choices.

Standard output

Standard output is faster to start with. AWS says it provides predefined insights based on the data type being processed, such as document semantics, audio transcripts, or video summaries and chapter summaries.

This is a good option when:

you want speed
you are validating a use case
you do not need very specific extraction fields yet

Custom output

Custom output is for more targeted use cases. With blueprints, you define the extraction logic and expected structure so the output matches your business need more closely. AWS has also added features such as blueprint instruction optimization to improve custom extraction accuracy using example assets and ground-truth labels.

This is a better option when:

you need specific fields
you need consistency
you are building a production workflow
your documents or media are domain-specific

For me, the normal journey is:
start with standard output, then move to custom output when the use case becomes clearer.

What types of content can BDA process?

BDA is built for multimodal content. AWS documentation and product pages describe support for:

documents
images
audio
video

That matters because many organizations have all four.

And the value is not only in “understanding” each file type independently. The real value is creating a single processing layer for all of them.

Where BDA fits best

I think BDA is strongest in these scenarios:

1. Intelligent document processing

AWS has positioned BDA strongly for document-heavy workflows, and AWS blog content around intelligent document processing shows it being used to accelerate extraction and automation for business documents.

Preparing content for RAG

AWS examples show BDA being used before Knowledge Bases and vector indexing so that multimodal content can be turned into cleaner, more useful retrieval input.

3. Audio and video understanding

BDA can generate outputs such as transcripts and summaries from audio and video, and AWS recently expanded it with custom vocabulary support through Data Automation Library to improve speech recognition accuracy for domain-specific terms.

4. Compliance and content review

AWS has also shown BDA in workflows such as extracting attachment content for later PII detection and redaction with Guardrails, which makes it relevant beyond simple summarization.

A practical workflow example

Let’s take a simple example.

Imagine you are building a support or operations workflow.

The input may include:

a maintenance PDF
a photo from the field
a voice note from an engineer
a short inspection video

Without a processing layer, each file stays isolated.

With BDA, the system can extract usable outputs from these files, and the rest of the architecture can work with those results more easily. Those extracted outputs can then be stored, indexed, sent to a knowledge base, or used by an agentic workflow. This is consistent with AWS’s documented BDA flow and solution examples that combine S3, BDA, Knowledge Bases, OpenSearch, and AgentCore.

That is why I see BDA as the bridge between raw content and usable AI workflows.

Newer capabilities worth watching

Two additions make BDA more interesting for real projects.

First, AWS added blueprint instruction optimization, which helps improve custom field extraction accuracy using example documents and labels. This is useful because custom extraction often needs tuning before it becomes reliable.

Second, AWS added custom vocabulary through Data Automation Library for audio and video processing. This helps when your environment uses domain-specific terms, product names, or technical language that general transcription may miss.

These are good signs that BDA is moving from “interesting feature” toward “serious processing layer.”

Things to keep in mind

BDA is powerful, but I would still keep a few points in mind.

1. Start simple

AWS recommends starting with standard output if you are new to the service. That makes sense because it helps validate the value quickly before you invest in custom extraction logic.

2. Design for the business output

Do not begin with “what model do I want?”
Begin with:

what fields do I need?
what decision will use this output?
what system will consume it?

3. Watch input requirements

AWS documents prerequisites and file requirements for BDA, including file-specific constraints that differ by content type and processing mode.

4. Treat prompts and blueprints carefully

AWS explicitly notes that blueprint prompt input should come from trusted sources, which is an important reminder for secure enterprise design.

Final thoughts

For me, Amazon Bedrock Data Automation is one of the most practical pieces in the current AWS multimodal stack.

It does not replace retrieval, RAG, or agents.

It enables them.

If multimodal AI is the bigger vision, BDA is one of the first services that helps turn that vision into a usable workflow. It helps convert raw documents, images, audio, and video into outputs that the rest of your architecture can actually work with.

That is why I would not treat BDA as a side feature.

I would treat it as a foundational building block.

In the next article, I will move one step further and focus on multimodal knowledge bases and how retrieval fits after the processing layer.

Supercharge AWS Diagrams in VSCode with Mermaid and Custom Icons

Moya Richards — Sat, 18 Apr 2026 04:45:00 +0000

Want to turn your architecture docs into visual gold? With the new Mermaid.js architecture diagram syntax and custom icon packs, you can create AWS diagrams—all from within VSCode using Markdown.

This guide walks you through how to:

✅ Use Mermaid’s new architecture syntax
✅ Set up custom AWS and icon libraries
✅ Preview it all in VSCode using the Markdown Preview Enhanced extension

Let’s dive in. 👇

🔧 Icon Packs You'll Use

Here are the icon libraries we’ll pull in:

These icons can be referenced in your Mermaid diagrams by name (e.g. logos:aws-lambda, aws:aurora, fa: ,).

✅ Step 1: Install Markdown Preview Enhanced

First, install the Markdown Preview Enhanced extension in VSCode.

It enables rich previews for .md files—supporting Mermaid, LaTeX, charts, diagrams, and more.

⚙️ Step 2: Inject Icon Packs into Mermaid

We’ll now customize the Markdown preview to load external icon packs into Mermaid.

How to set it up:

In VSCode, press Ctrl + P, then type:

   > Markdown Preview Enhanced: Customize Preview Html Head (WORKSPACE)

Select the command. It will create a file:

   .crossnote/head.html

Paste the following code into that file:

<!-- Load custom icon packs for Mermaid architecture diagrams -->
<script type="text/javascript">
  const configureMermaidIconPacks = () => {
    window["mermaid"].registerIconPacks([
      {
        name: "logos",
        loader: () =>
          fetch("https://unpkg.com/@iconify-json/logos/icons.json").then(res =>
            res.json()
          ),
      },
      {
        name: "lucide",
        loader: () =>
          fetch("https://unpkg.com/@iconify-json/lucide/icons.json").then(res =>
            res.json()
          ),
      },
      {
        name: "fa",
        loader: () =>
          fetch("https://unpkg.com/@iconify-json/fa/icons.json").then(res =>
            res.json()
          ),
      },
      {
        name: "aws",
        loader: () =>
          fetch(
            "https://raw.githubusercontent.com/awslabs/aws-icons-for-plantuml/aa30729ab2e125f13526020fa98ed5eb0ed86cc1/dist/aws-icons-mermaid.json"
          ).then(res => res.json()),
      },
    ]);
  };

  if (document.readyState !== "loading") {
    configureMermaidIconPacks();
  } else {
    document.addEventListener("DOMContentLoaded", () => {
      configureMermaidIconPacks();
    });
  }
</script>

This ensures Mermaid can load and render your custom icons directly in preview.

🖼️ Step 3: Create a Diagram with AWS Icons

Now create a .md file (e.g. README.md) and embed a Mermaid diagram using the new architecture syntax and icons.

Here’s a full example using AWS services:

Click to expand the Mermaid diagram example

---
config:
  theme: base
  themeVariables:
    darkMode: false
    archEdgeColor: "#232F3E"
    archEdgeArrowColor: "#232F3E"
    archGroupBorderColor: "#ff862a"
---
architecture-beta


service user_service(lucide:user)[Users via Web Browser]

group cdk_infra(cloud)[AWS CDK Infrastructure]

service waf(logos:aws-waf)[AWS WAF] in cdk_infra
service cloudfront(logos:aws-cloudfront)[Amazon CloudFront] in cdk_infra
service cognito(logos:aws-cognito)[Amazon Cognito] in cdk_infra
service s3_front(logos:aws-s3)[Amazon S3 Frontend Hosting] in cdk_infra
service apigw(logos:aws-api-gateway)[Amazon API Gateway] in cdk_infra
service appsync(logos:aws-appsync)[AWS AppSync] in cdk_infra
service cdk_deploy(aws:cloudformation)[AWS CDK Deployment] in cdk_infra

group vpc_private_subnet(cloud)[VPC Private Subnet] in cdk_infra

service lambda(logos:aws-lambda)[AWS Lambda] in vpc_private_subnet
service dynamodb(logos:aws-dynamodb)[Amazon DynamoDB] in vpc_private_subnet
service aurora(logos:aws-aurora)[Amazon Aurora PostgreSQL] in vpc_private_subnet
service sagemaker(aws:sagemaker)[Amazon SageMaker] in vpc_private_subnet
service bedrock(aws:bedrock)[Amazon Bedrock] in vpc_private_subnet
service step_functions(logos:aws-step-functions)[AWS Step Functions] in vpc_private_subnet
service s3_ingest(logos:aws-s3)[Amazon S3 Ingestion] in vpc_private_subnet
service lambda_ingest(logos:aws-lambda)[AWS Lambda Ingestion] in vpc_private_subnet


user_service:R --&gt; L:waf
waf:R --&gt; L:cloudfront
cloudfront:R --&gt; L:cognito
cognito:R --&gt; L:s3_front
s3_front:R --&gt; L:apigw
s3_front:B --&gt; L:appsync
apigw:R --&gt; L:lambda
appsync:R --&gt; L:lambda
lambda:R --&gt; L:dynamodb
lambda:B --&gt; T:aurora
lambda:T --&gt; B:bedrock
sagemaker:R --&gt; B:s3_ingest
step_functions:R --&gt; L:s3_ingest
s3_ingest:R --&gt; L:lambda_ingest
lambda_ingest:R --&gt; L:dynamodb
lambda_ingest:R --&gt; L:aurora
cdk_deploy:R --&gt; L:step_functions

view in the Mermaid Live Editor

🎉 That’s It!

You now have a fully working setup to design AWS diagrams using Mermaid in VSCode—with custom icons and rich architecture syntax. It’s perfect for:

Internal docs and wikis
Cloud architecture planning
README files that actually explain things

🛠 Bonus Tips

If icons don’t appear, double-check you’re in the Markdown Preview Enhanced window (not the default preview).

Building a Multimodal Agent with the ADK, AWS Fargate, and Gemini Flash Live 3.1

xbill — Fri, 17 Apr 2026 19:20:10 +0000

Leveraging the Google Agent Development Kit (ADK) and the underlying Gemini LLM to build Agentic apps using the Gemini Live API with the Python programming language deployed to Amazon Fargate.

Aren’t There a Billion Python ADK Demos?

Yes there are.

Python has traditionally been the main coding language for ML and AI tools. The goal of this article is to provide a minimal viable basic working ADK streaming multi-modal agent using the latest Gemini Live Models.

In the Spirit of Mr. McConaughey’s “alright, alright, alright”

So what is different about this lab compared to all the others out there?

This is one of the first implementations of the latest Gemini 3.1 Flash Live Model with the Agent Development Kit (ADK). The starting point for the demo was an existing Code lab- which was updated and re-engineered with Gemini CLI.

The original Codelab- is here:

Way Back Home - Building an ADK Bi-Directional Streaming Agent | Google Codelabs

What Is Python?

Python is an interpreted language that allows for rapid development and testing and has deep libraries for working with ML and AI:

Welcome to Python.org

Python Version Management

One of the downsides of the wide deployment of Python has been managing the language versions across platforms and maintaining a supported version.

The pyenv tool enables deploying consistent versions of Python:

GitHub - pyenv/pyenv: Simple Python version management

As of writing — the mainstream python version is 3.13. To validate your current Python:

python --version
Python 3.13.13

Amazon Fargate

AWS Fargate is a serverless, pay-as-you-go compute engine for containers that works with Amazon Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS). It eliminates the need to manage, patch, or scale underlying EC2 virtual machines. Fargate automatically allocates, scales, and manages compute infrastructure, allowing developers to focus solely on designing and operating applications.

Details are here:

Serverless Compute - AWS Fargate - AWS

More information on Fargate is available here:

Architect for AWS Fargate for Amazon ECS

Gemini Live Models

Gemini Live is a conversational AI feature from Google that enables free-flowing, real-time voice, video, and screen-sharing interactions, allowing you to brainstorm, learn, or problem-solve through natural dialogue. Powered by the Gemini 3.1 Flash Live model , it provides low-latency, human-like, and emotionally aware speech in over 200 countries.

More details are available here:

Gemini 3.1 Flash Live Preview | Gemini API | Google AI for Developers

The Gemini Live Models bring unique real-time capabilities than can be used directly from an Agent. A summary of the model is also available here:

https://deepmind.google/models/model-cards/gemini-3-1-flash-live/

Gemini CLI

If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:

npm install -g @google/gemini-cli

Testing the Gemini CLI Environment

Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:

▝▜▄ Gemini CLI v0.33.1
    ▝▜▄
   ▗▟▀ Logged in with Google /auth
  ▝▀ Gemini Code Assist Standard /upgrade no sandbox (see /docs) /model Auto (Gemini 3) | 239.8 MB

Node Version Management

Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:

GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Agent Development Kit

The Google Agent Development Kit (ADK) is an open-source, Python-based framework designed to streamline the creation, deployment, and orchestration of sophisticated, multi-agent AI systems. It treats agent development like software engineering, offering modularity, state management, and built-in tools (like Google Search) to build autonomous agents.

The ADK can be installed from here:

Agent Development Kit (ADK)

Where do I start?

The strategy for starting multimodal real time agent development is a incremental step by step approach.

First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.

Then, a minimal ADK Agent is built and tested locally. Next — the entire solution is deployed to Amazon ECS Fargate.

Setup the Basic Environment

At this point you should have a working Python environment and a working Gemini CLI installation. All of the relevant code examples and documentation is available in GitHub. This repo has a wide variety of samples- but this lab will focus on the ‘gemini31-fargate’ setup.

The next step is to clone the GitHub repository to your local environment:

cd ~
git clone https://github.com/xbill9/gemini-cli-aws
cd gemini31-fargate

Then run init.sh from the cloned directory.

The script will attempt to determine your shell environment and set the correct variables:


xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ source init.sh
Environment setup complete.
GOOGLE_GENAI_USE_VERTEXAI=false
GOOGLE_CLOUD_PROJECT=aisprint-491218
GOOGLE_CLOUD_LOCATION=us-central1

If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:

source set_env.sh

Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.

Build the User Interface

The front end files provide the user interface:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make frontend
cd frontend && npm install && npm run build

up to date, audited 219 packages in 800ms

49 packages are looking for funding
  run `npm fund` for details

1 high severity vulnerability

To address all issues, run:
  npm audit fix

Run `npm audit` for details.

> frontend@0.0.0 build
> vite build

vite v7.3.1 building client environment for production...
✓ 33 modules transformed.
dist/index.html 0.46 kB │ gzip: 0.29 kB
dist/assets/index-xOQlTZZB.css 21.60 kB │ gzip: 4.54 kB
dist/assets/index-DZmIx3HW.js 214.58 kB │ gzip: 67.45 kB
✓ built in 1.18s

Test The User Interface

The mock server test script allows the interface and Browser settings to be set to allow multimedia — without using any external Model calls or tokens:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make mock
python mock/mock_server.py
Serving static files from: /home/xbill/gemini-cli-aws/gemini31-fargate/frontend/dist
INFO: Started server process [8689]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

The Deployed mock front-end will look similar to:

Verify The ADK Installation

To verify the setup, run the ADK CLI locally with the biometric_agent:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ source testadk.sh
connect to local ADK CLI 

/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
Log setup complete: /tmp/agents_log/agent.20260415_200105.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/cli/cli.py:204: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
Running agent biometric_agent, type exit to exit.

[biometric_agent]: Scanner Online.

[user]:

Test The ADK Web Interface

This tests the Audio / Video ADK agent interactions:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ source runadk.sh 
connect on http://127.0.0.1:8000/

/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
2026-04-15 20:01:46,272 - INFO - service_factory.py:266 - Using in-memory memory service
2026-04-15 20:01:46,272 - INFO - local_storage.py:84 - Using per-agent session storage rooted at /home/xbill/gemini-cli-aws/gemini31-fargate/backend/app
2026-04-15 20:01:46,272 - INFO - local_storage.py:110 - Using file artifact service at /home/xbill/gemini-cli-aws/gemini31-fargate/backend/app/.adk/artifacts
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/cli/fast_api.py:198: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
INFO: Started server process [10520]
INFO: Waiting for application startup.

+-----------------------------------------------------------------------------+
| ADK Web Server started |
| |
| For local testing, access at http://0.0.0.0:8000. |
+-----------------------------------------------------------------------------+

INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
INFO: 127.0.0.1:41986 - "GET / HTTP/1.1" 307 Temporary Redirect
INFO: 127.0.0.1:41986 - "GET /dev-ui/ HTTP/1.1" 200 OK
INFO: 127.0.0.1:41986 - "GET /dev-ui/styles-YY6V3TJU.css HTTP/1.1" 200 OK
INFO: 127.0.0.1:41990 - "GET /dev-ui/chunk-RGCH6K7F.js HTTP/1.1" 200 OK
INFO: 127.0.0.1:42002 - "GET /dev-ui/chunk-W7GRJBO5.js HTTP/1.1" 200 OK
INFO: 127.0.0.1:42026 - "GET /dev-ui/main-7SJG752M.js HTTP/1.1" 200 OK
INFO: 127.0.0.1:42016 - "GET /dev-ui/polyfills-5CFQRCPP.js HTTP/1.1" 200 OK
INFO: 127.0.0.1:42026 - "GET /dev-ui/assets/config/runtime-config.json HTTP/1.1" 200 OK
INFO: 127.0.0.1:42026 - "GET /list-apps?relative_path=./ HTTP/1.1" 200 OK
INFO: 127.0.0.1:41986 - "GET /dev-ui/assets/ADK-512-color.svg HTTP/1.1" 200 OK
INFO: 127.0.0.1:42026 - "GET /dev-ui/adk_favicon.svg HTTP/1.1" 200 OK
2026-04-15 20:01:49,369 - INFO - local_storage.py:60 - Creating local session service at /home/xbill/gemini-cli-aws/gemini31-fargate/backend/app/biometric_agent/.adk/session.db
INFO: 127.0.0.1:42016 - "GET /builder/app/biometric_agent?ts=1776297709357 HTTP/1.1" 200 OK
2026-04-15 20:01:49,393 - INFO - adk_web_server.py:867 - New session created: b1b2e791-b792-414a-9d46-90a3ddac1e53

Then use the web interface — either on the local interface 127.0.0.1 or the catch-all web interface 0.0.0.0 -depending on your environment:

Special note for Google Cloud Shell Deployments- add a CORS allow_origins configuration exemption to allow the ADK agent to run:

adk web --host 0.0.0.0 --allow_origins 'regex:.*'

Lint and Test the Main Python Code

The final step is to build, lint, and test the main Python code.

To Lint:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make lint
Linting Python code with Ruff...
ruff check backend
All checks passed!
Linting Frontend code with ESLint...
cd frontend && npm run lint

> frontend@0.0.0 lint
> eslint .

To Test:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make test
Running backend and connectivity tests...
python3 -m pytest test_live_connection.py test_ws_backend.py test_ws_backend_v2.py backend/app/biometric_agent/test_agent.py
================================================================ test session starts ================================================================
platform linux -- Python 3.13.13, pytest-9.0.3, pluggy-1.6.0
rootdir: /home/xbill/gemini-cli-aws/gemini31-fargate
plugins: anyio-4.13.0, asyncio-1.3.0
asyncio: mode=Mode.STRICT, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
collected 8 items                                                                                                                                   

test_live_connection.py . [12%]
test_ws_backend.py . [25%]
test_ws_backend_v2.py . [37%]
backend/app/biometric_agent/test_agent.py ..... [100%]

================================================================= warnings summary ==================================================================
../../.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72
  /home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
    check_feature_enabled()

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=========================================================== 8 passed, 1 warning in 2.67s ============================================================
xbill@penguin:~/gemini-cli-aws/gemini31-fargate$

Running Locally

The main Python Code can then be run locally:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ source biosync.sh
Local URL
http://127.0.0.1:8080/
/home/xbill/.pyenv/versions/3.13.13/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
2026-04-15 20:06:48,642 - INFO - System Config: 2.0 FPS, 10.0s Heartbeat
Serving static files from: /home/xbill/gemini-cli-aws/gemini31-fargate/frontend/dist
INFO: Started server process [11513]
INFO: Waiting for application startup.
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

Then connect to the local front end:

Deploying to ECS

A utility script runs the deployment to AWS ECS Fargate. Use the deploy version from the local system:

aws login --remote

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ source save-aws-creds.sh 
Exporting AWS credentials...
Successfully saved credentials to .aws_creds
The Makefile will now automatically use these for deployments.
xbill@penguin:~/gemini-cli-aws/gemini31-fargate$

The system can now be deployed:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make deploy
./save-aws-creds.sh
Exporting AWS credentials...
Successfully saved credentials to .aws_creds
The Makefile will now automatically use these for deployments.
./deploy-fargate.sh

And status checked:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make status
--- Fargate Cluster Status ---
-------------------------------------------------------------
| DescribeClusters |
+--------------------------+----------+----------+----------+
| Name | Pending | Running | Status |
+--------------------------+----------+----------+----------+
| biometric-scout-cluster | 0 | 1 | ACTIVE |
+--------------------------+----------+----------+----------+
--- Fargate Service Status ---
-------------------------------------------------------------
| DescribeServices |
+---------+----------+---------------------------+----------+
| Desired | Running | Service | Status |
+---------+----------+---------------------------+----------+
| 1 | 1 | biometric-scout-service | ACTIVE |
+---------+----------+---------------------------+----------+
xbill@penguin:~/gemini-cli-aws/gemini31-fargate$

Once the container is deployed- you can then get the endpoint:

xbill@penguin:~/gemini-cli-aws/gemini31-fargate$ make endpoint
--- Fargate HTTPS Endpoint ---
Application URL: https://biometric-scout-alb-1410555012.us-east-1.elb.amazonaws.com

The service will be visible in the AWS console:

Running the Web Interface

Start a connection to the deployed app:

https://biometric-scout-alb-1410555012.us-east-1.elb.amazonaws.com

Then connect to the app :

Then use the Live model to process audio and video:

Finally — complete the sequence:

Gemini CLI Code Review

As a final step — Gemini CLI was used for a full code review of the project:

✦ Based on my comprehensive review of the "Alpha Rescue Drone - Biometric Security System," the codebase is exceptionally well-structured,
  follows modern engineering standards, and strictly adheres to the specialized requirements for Gemini 3.1 Flash Live and the Google Agent
  Development Kit (ADK).

Core Architecture & Integration
  The system excels at orchestrating a high-frequency, multimodal data stream. The use of a binary protocol (0x01 for audio, 0x02 for video)
  in useGeminiSocket.js minimizes overhead, while the monkey-patching utility in patch_adk.py demonstrates a sophisticated understanding of
  the evolving Gemini 3.1 Live API. This proactive approach ensures compatibility with features like send_realtime_input that are not yet
  natively handled by the standard ADK.

Backend Analysis
   - Agent Intelligence: The instructions in agent.py are precise and prioritize safety (offensive gesture detection) and hidden overrides
     ("Devil's Horns") effectively.
   - Resilience: The backend implements a heartbeat stimulus (CONTINUE_SURVEILLANCE) and a neural handshake, which are critical for
     maintaining model engagement during visual-only periods.
   - Model Fallback: The get_model_id() logic is clever, automatically switching to gemini-2.5-flash for CLI runs to prevent 404 errors,
     while defaulting to the high-performance gemini-3.1-flash-live-preview for production.

Frontend & UI/UX
   - Aesthetic: The "Neon Cyan" HUD in BiometricLock.jsx provides a high-fidelity, futuristic feel that aligns with the "Mission Alpha"
     theme.
   - Feedback Loop: The synchronization between the random sequence generation, visual matching, and the special "Heavy Metal" audio event
     creates a compelling user experience.
   - Efficiency: Utilizing toBlob with JPEG compression (0.6) for the 2 FPS video stream is an optimal choice for balancing visual clarity
     with network latency.

Testing & Maintainability
   - Validation: The project maintains a clean slate with 100% test and linting compliance. The inclusion of mock.sh is a significant
     developer productivity boost.
   - Standards: The use of Ruff for Python and ESLint for the frontend ensures long-term code quality.

Recommendations
   1. Connection Resilience: While the SYSTEM_ERROR closes the socket correctly, the frontend could benefit from a more graceful
      "Reconnecting..." state if the network fluctuates during a mission.
   2. Patch Management: As the Gemini Live API stabilizes, keep an eye on official ADK updates to deprecate the manual unrolling of
      media_chunks in patch_adk.py.
   3. Security: Verify that the .env variables are correctly injected into the Cloud Run environment via the Makefile or cloudbuild.yaml
      without being exposed in the build logs.

Overall, the system is a robust and creative implementation of real-time multimodal AI. Authentication Protocol: Stable. 🤘
                                                                                                                             ? for shortcuts

Summary

The Agent Development Kit was used to enable a multi-modal agent using the Gemini Live Model. This Agent was tested locally with the CLI and then deployed to Amazon Fargate. Several key take-aways and lessons learned were summarized from working with the transition to a new Live Gemini LLM model. Finally, Gemini CLI was used for a complete project code review.

I Replaced 47 DevOps Scripts With One AI Agent — Here’s What Happened

POTHURAJU JAYAKRISHNA YADAV — Fri, 17 Apr 2026 10:15:34 +0000

The Hook: I Was Wrong About Automation

I thought I automated DevOps.

I had 47 deployment scripts.

Then I started replacing them with an AI agent —
and most scripts became unnecessary.

Not by following instructions.
By making decisions.

And the 2 AM debugging stopped.

Note: The code shown here is simplified for clarity.
The GitHub repo contains a more modular implementation.

That's when I realized:

I wasn't automating.
I was hardcoding decisions.

I gave Claude a list of AWS tools and one instruction: "Deploy this app."

No hardcoded logic.
No decision trees.

Just: describe the goal, Claude figures out how.

Deployment time: 3 hours → in minutes for most cases.

(Built this while deploying real workloads on AWS: Docker, ECS, EC2, IAM.)

🎯 Is This For You?

This post is for:

DevOps engineers with 10+ deployment scripts
Platform engineers building internal developer platforms
Anyone exploring AI agents beyond chatbots
Teams on AWS (Docker, EC2, ECS, IAM)

If manual deployment takes > 30 minutes, read this.

✨ What's Possible

Old way (manual):

aws ecs create-cluster --cluster-name prod
aws ecs register-task-definition --family myapp ...
# [50+ commands, 3 hours, manual debugging]

New way (agent):

agent.run("Deploy FastAPI with PostgreSQL, auto-scale to 20, "
          "minimal IAM perms, CloudWatch monitoring")

# ✅ Done in minutes for most cases, with significantly reduced debugging

No scripts.

Just Claude thinking out loud about your infrastructure.

🚀 How It Actually Works

You describe the goal (natural language):

"Deploy my app on 5 ECS tasks, auto-scale to 20 on high CPU"

Claude gets these tools:

dispatcher = {
    "ecs__create_cluster": ecs.create_cluster,
    "ecs__register_task": ecs.register_task_definition,
    "ecs__create_service": ecs.create_service,
    "iam__create_role": iam.create_role,  # For permissions
}

Claude reasons autonomously:

"User wants ECS deployment.
 I need to:
 1. Check if cluster exists
 2. Register task definition
 3. Create service with 5 tasks
 4. Setup auto-scaling
 5. Verify it's running"

It executes:

Call ecs__create_cluster() → Get cluster ARN
Call ecs__register_task() → Get task definition
Call ecs__create_service() → Get running tasks
Call ecs__setup_autoscaling() → Confirmed
Return: "All 5 tasks running, auto-scaling 5-20"

** Minimal manual intervention in most cases. Just reasoning + execution + feedback loops.**

⚠️ The Problem I Started With

I had:

deploy_docker.py — 150 lines of Docker logic
deploy_ec2.py — 200 lines of EC2 logic
deploy_ecs.py — 300 lines of ECS logic
3 routers trying to chain them together
0 way to handle "deploy to both EC2 AND ECS"

Every new service = new script. Every new workflow = rewrite everything.

Solution: Reduce rigid scripts — let the agent handle orchestration logic dynamically.

Instead of routing to specific tools, give Claude all available tools and let it decide which ones to use, in which order, adapting as it goes.

# All tools in one place
tools = {
    "docker__run": run_container,
    "ec2__create": create_instance,
    "ecs__deploy": create_service,
    "iam__create_role": create_role,
    # ... more tools
}

# Let Claude orchestrate
agent.run("Deploy with Docker locally, then scale to ECS production")
# Claude figures out: Docker first, then ECS, then IAM for permissions

🏗️ The Architecture (3 Layers)

┌──────────────────────────────┐
│ User Goal (natural language) │  
│ "Deploy scalable production  │
│  stack with auto-scaling"    │
└──────────┬───────────────────┘
           │
           ▼
    ┌─────────────────────────────────────────────┐
    │  Claude (Bedrock)                           │
    │  ← Reads goal + available tools             │
    │  ← Decides sequence of actions              │
    │  ← Adapts when things fail                  │
    └──────────────┬────────────────────────────┘
                   │
    ┌──────────────┴──────────────┐
    │                             │
    ▼                             ▼
┌─────────────┐  ┌──────────────────┐
│ AWS APIs    │  │ Conversation     │
│ (via boto3) │  │ Memory (DynamoDB)│
│ ← Executes  │  │ ← Recalls setup  │
│   decisions │  │   from last week │
└─────────────┘  └──────────────────┘
    │                    │
    └────────┬───────────┘
             │
    ┌────────▼─────────┐
    │ Actual Resources │
    │ EC2, ECS, Docker │
    │      IAM, etc    │
    └──────────────────┘

3 moving parts:

Claude — Reasons about the task
Tools — Execute AWS API calls
Memory — Remember past deployments for coherence

🔧 The Setup (Code Foundation)

Here's the entire base system in ~100 lines. Full code on GitHub.

import boto3
from agents.memory import load_history, save_message

MODEL = "apac.amazon.nova-lite-v1:0"  # Fast, cheap 

class BaseAgent:
    """Foundation for all agents (Docker, EC2, ECS, IAM)"""
    AGENT_KEY = None  # "docker", "ec2", etc.
    SYSTEM_PROMPT = ""  # Agent's personality
    CAPABILITIES = []  # What this agent can do

    def __init__(self, name: str, region: str = "us-east-1"):
        self.name = name
        self.session = boto3.Session(region_name=region)
        self._bedrock = None

    @property
    def bedrock(self):
        """Lazy load Bedrock connection (only when needed)"""
        if not self._bedrock:
            self._bedrock = self.session.client("bedrock-runtime")
        return self._bedrock

    def run(self, task: str, session_id: str = None) -> dict:
        """The agentic loop: think → decide → act → repeat"""
        tools = self.get_tools()
        dispatcher = self.get_dispatcher()
        messages = load_history(session_id) + [{"role": "user", "content": [{"text": task}]}]

        for _ in range(10):  # Max 10 iterations to prevent infinite loops
            # Ask Claude what to do
            response = self.bedrock.converse(
                modelId=MODEL,
                system=self.SYSTEM_PROMPT,
                messages=messages,
                tools=tools,
                toolUseDepth=2,
            )

            # Is Claude done?
            if response["stopReason"] == "endTurn":
                return {"status": "SUCCESS", "message": response["content"]}

            # Execute tools Claude wants to call
            tool_results = []
            for tool_use in response["content"]:
                tool_name = tool_use["toolUse"]["name"]
                try:
                    result = dispatcher<a href="tool_use["toolUse"]["input"]">tool_name</a>
                except Exception as e:
                    result = {"error": str(e), "status": "failed"}

                tool_results.append({"toolUseId": tool_use["toolUse"]["toolUseId"],
                                    "content": [{"json": result}]})

            # Add Claude's decision + results to conversation
            messages.append({"role": "assistant", "content": response["content"]})
            messages.append({"role": "user", "content": [{"toolResult": tr} for tr in tool_results]})

            # Save for future reference
            if session_id:
                save_message(session_id, messages[-1])

        return {"status": "FAILED", "reason": "Max iterations reached"}

What's happening:

Lazy loading (@property bedrock): Don't connect to Claude until needed
Tool loop: Call tools, capture results, show Claude the output
Error handling: Don't crash—tell Claude what failed, let it adapt
Memory: Save each turn so Claude remembers next week

🚀 Agents in Action: 3 Real Examples

DockerAgent: Deploy Locally

class DockerAgent(BaseAgent):
    AGENT_KEY = "docker"
    SYSTEM_PROMPT = """You manage Docker containers.
Rules: Pull image first, check if container exists, use sensible defaults."""

    CAPABILITIES = [
        {"name": "list_containers", "description": "List running containers"},
        {"name": "run_container", "description": "Pull and run image"},
        {"name": "stop_container", "description": "Stop a container"},
    ]

Usage:

docker_agent = DockerAgent()
docker_agent.run("Deploy FastAPI on port 8000 with health check")
# Claude calls: list_containers → run_container → confirms it's running

EC2Agent: Scale to Cloud

class EC2Agent(BaseAgent):
    AGENT_KEY = "ec2"
    SYSTEM_PROMPT = """You manage EC2 instances.
Rules: Tag for organization, verify security groups, create new→test→retire old."""

    CAPABILITIES = [
        {"name": "describe_instances", "description": "List instances"},
        {"name": "create_instance", "description": "Launch new instance"},
        {"name": "stop_instance", "description": "Stop instance"},
    ]

Usage:

ec2_agent = EC2Agent()
ec2_agent.run("Create 2 t2.micro instances, tag as app-server")
# Claude: checks if instances exist → creates 2 → returns IPs → confirms running

ECSAgent: Production Auto-Scaling

class ECSAgent(BaseAgent):
    AGENT_KEY = "ecs"
    SYSTEM_PROMPT = """You manage ECS services at production scale.
Rules: Task definition first, use Fargate, always configure auto-scaling."""

    CAPABILITIES = [
        {"name": "create_cluster", "description": "Create ECS cluster"},
        {"name": "register_task_definition", "description": "Register blueprint"},
        {"name": "create_service", "description": "Deploy service"},
        {"name": "setup_autoscaling", "description": "Configure scaling rules"},
    ]

Usage:

ecs_agent = ECSAgent()
ecs_agent.run("Deploy with 5 tasks, auto-scale to 20 on high CPU, health monitoring")
# Claude orchestrates: cluster → task definition → service → autoscaling → verification

Real Usage: From Local to Production

Scenario: Deploy FastAPI from laptop to production in minutes for most cases, with significantly reduced debugging.

Stage 1: Test locally

docker_agent.run("Run myapp:latest on port 8000", session_id="prod_001")
# ✅ Docker container running

Stage 2: Scale to cloud

ec2_agent.run("Create 2 instances for load balancing", session_id="prod_001")
# ✅ 2 EC2 instances up (same session = Claude remembers port 8000)

Stage 3: Auto-scaling production

ecs_agent.run("Deploy with 5-20 auto-scaling, CloudWatch monitoring", session_id="prod_001")
# ✅ 5 ECS tasks running, auto-scaling 5-20 based on CPU

All with the same session_id: Claude remembers the image name, port, and configuration from Stage 1. Everything connects seamlessly.

📚 Memory: Agents Remember

# Day 1
agent.run("Deploy on Docker with port 8000", session_id="user_123")

# Week later
agent.run("Move this to ECS for production", session_id="user_123")
# Claude reads history from DynamoDB:
# "I remember this app used port 8000. I'll keep that for ECS too."

DynamoDB stores every conversation turn. Claude recalls past decisions and uses them for coherence.

🛡️ Production-Ready Code Patterns

This is what the user feedback emphasized. Real code needs safety.

Pattern 1: Error Handling (Don't Crash, Recover)

# ❌ Wrong: crashes on error
result = dispatcher[tool_name](tool_input)

# ✅ Right: tell Claude about the error
try:
    result = dispatcher[tool_name](tool_input)
except Exception as e:
    result = {
        "error": str(e),
        "status": "failed",
        "request_id": request_id,  # For debugging
    }
# Claude sees the error and tries a different approach

Why this matters: If Docker pull fails, don't give up. Tell Claude: "Pull failed, but let me check if the image is locally cached." Claude adapts.

Pattern 2: Timeouts (Prevent Hanging)

from functools import wraps
import signal

def with_timeout(seconds=30):
    """Prevent tools from running forever"""
    def decorator(func):
        def wrapper(*args, **kwargs):
            def handler(signum, frame):
                raise TimeoutError(f"Tool execution exceeded {seconds}s")

            signal.signal(signal.SIGALRM, handler)
            signal.alarm(seconds)
            try:
                result = func(*args, **kwargs)
                signal.alarm(0)  # Cancel timeout
                return result
            except TimeoutError as e:
                return {"error": str(e), "status": "timeout"}
        return wrapper
    return decorator

@with_timeout(seconds=60)
def create_instance(params):
    """If EC2 creation hangs, timeout after 60 seconds"""
    ec2 = boto3.client("ec2")
    return ec2.create_instances(**params)

Pattern 3: Input Validation (Prevent Bad Requests)

def create_instance(params):
    """Validate before executing"""
    # Check required fields
    required = ["ImageId", "InstanceType"]
    for field in required:
        if field not in params:
            return {"error": f"Missing required field: {field}", "status": "failed"}

    # Validate instance type
    valid_types = ["t2.micro", "t2.small", "t3.medium"]
    if params["InstanceType"] not in valid_types:
        return {
            "error": f"InstanceType must be one of {valid_types}",
            "status": "failed"
        }

    # Now safe to execute
    ec2 = boto3.client("ec2")
    return ec2.create_instances(**params)

Pattern 4: Audit Logging (Proof for Compliance)

import json
from datetime import datetime

def log_action(request_id: str, user: str, action: str, params: dict, result: dict):
    """Log everything for audits"""
    log_entry = {
        "request_id": request_id,
        "timestamp": datetime.utcnow().isoformat(),
        "user": user,
        "action": action,
        "params": json.dumps(params),  # What was requested
        "result_status": result.get("status"),
        "result_code": result.get("error"),
    }

    # Save to CloudWatch Logs or DynamoDB
    dynamodb.put_item(TableName="agent_audit", Item=log_entry)

# In the tool dispatcher:
result = dispatcher[tool_name](tool_input)
log_action(request_id, user_id, tool_name, tool_input, result)

Pattern 5: Cost Guards (Don't Deploy Expensive Mistakes)

MONTHLY_BUDGET = 1000  # $1000/month limit

def estimate_cost(action: str, params: dict) -> float:
    """Estimate AWS cost before executing"""
    if action == "create_instance":
        instance_type = params.get("InstanceType", "t2.micro")
        hourly_rates = {
            "t2.micro": 0.012,
            "t2.small": 0.023,
            "t3.medium": 0.042,
        }
        months_running = 1
        return hourly_rates.get(instance_type, 0) * 730 * months_running

    elif action == "create_rds":
        # RDS: ~$400/month for 20GB
        return 400

    return 0

# In the runnable:
estimated = estimate_cost(tool_name, tool_input)
if estimated > MONTHLY_BUDGET:
    return {
        "error": f"Cost ${estimated:.2f} exceeds budget ${MONTHLY_BUDGET}",
        "status": "rejected",
    }
# Only execute if under budget
result = dispatcher[tool_name](tool_input)

Pattern 6: Role-Based Access (Security Boundaries)

# Define who can do what
USER_PERMISSIONS = {
    "admin": ["create_instance", "delete_instance", "create_role", "delete_role"],
    "developer": ["create_instance", "stop_instance", "deploy_to_ecs"],
    "readonly": ["describe_instances", "list_containers", "get_logs"],
}

def check_permission(user_role: str, action: str) -> bool:
    """Prevent unauthorized actions"""
    allowed = USER_PERMISSIONS.get(user_role, [])
    if action not in allowed:
        return False
    return True

# Before executing:
if not check_permission(user_role, tool_name):
    return {
        "error": f"User role '{user_role}' cannot perform '{tool_name}'",
        "status": "permission_denied",
    }
result = dispatcher[tool_name](tool_input)

✅ Why Agents > Scripts

	Scripts	Agents
New workflow	Rewrite code	Claude adapts
Error recovery	Crashes	Tries alternatives
Reasoning	None (hardcoded)	Full decision log
Maintenance	Grows linearly	One framework
Learning	Manual proof	Automatic audit trail

🎯 Getting Started

Just 3 commands:

git clone https://github.com/jayakrishnayadav24/ai-agents
cd ai-agents
pip install -r requirements.txt

Then try:

from agents.docker_agent import DockerAgent

agent = DockerAgent()
response = agent.run(
    "Deploy FastAPI app on port 8000 with health check"
)
print(response)

That's it. Claude handles the rest.

📚 What's Next (Part 2)

This was the concept. Github:

✅ Full working code (all agents)
✅ DynamoDB setup for memory
✅ Deploying agents to Lambda
✅ Real production patterns (request tracing, cost estimation)
✅ Demo with actual deployments

⚠️ Where This Breaks

Complex compliance environments (manual approvals still needed)
Cost estimation is approximate
Requires well-defined tools (garbage in → garbage out)

The Bottom Line

Before: 47 scripts, 3 hours/deployment, constant debugging

After: 1 agent framework, in minutes for most cases, with significantly reduced debugging/deployment.

Why? Because Claude doesn't follow scripts. Claude plans and executes the steps based on the goal.

It adapts. It learns. It remembers.

That's not automation anymore. That's the future of infrastructure.

How many deployment scripts are you still maintaining?

10+? 20+? 50+?

I want to see how bad this problem is. Drop a comment 👇

Your feedback shapes Part 2.

Processing long running events on AWS API Gateway

Evertson Croes — Fri, 17 Apr 2026 08:19:51 +0000

Processing long running events on AWS API Gateway

AWS API Gateway is a managed HTTP/REST service provided by AWS. It provides a relatively simple way to host an API and offers rich functionality when it comes to customizability, security and integration. AWS API Gateway enforces a maximum integration timeout of 29 seconds. For most APIs this is perfectly reasonable.

However, problems arise when an API must trigger operations that take minutes to complete, such as generating large exports or running complex background jobs. In our case, we needed to generate large database exports that could take several minutes. A synchronous API request was therefore not an option. One example is the generation of large exports from a database. This became a challenge with the default setup we had with API Gateway.

AWS provides some guidance on this in their documentation. However, in this blog article I want to share how we solved this problem in our project in more detail and also provide a working CDK project as an example.

The problem

As mentioned in the intro, we have a time limit of 29 seconds on requests on API Gateway. But the problem is also that we want to run functionality that could potentially run for many minutes. In this case, we do not want to run a synchronous call, but an asynchronous call. Meaning that even if API Gateway would allow us to keep a request open for 30 minutes, it would not be beneficial for a frontend application to keep one blocking request open for that long since it takes up resources.

So we also need a mechanism to handle asynchronous requests while still using API Gateway.

The TaskManager

We ended up calling the solution to this problem the “TaskManager”. It can be seen as one Microservice with the sole responsibility of keeping track of tasks. It does not actually process the tasks. The following diagram provides a high-level overview:

In this overview, there are Task Suppliers, Task Processors and the TaskManager itself. It is important to note that in our use cases, we have not yet found a scenario where there are multiple suppliers of the same task and multiple processors for the same type of task. However, the pattern introduced in this blog could be expanded to include this if necessary.

If we zoom in to the TaskManager, we have the following components:

(Click here to see diagram better)

This diagram depicts the deployment and the flow at the same time. On the left side, we can see a Task Supplier. For this example, it does not matter what this is. It could be any component that can do a HTTP request. In our example, it was a Backend-for-Frontend API Gateway.

This Task Supplier calls one of the two endpoints available in the TaskManager API, which itself is an API Gateway, that allows the creation of a Task via a HTTP POST request. This triggers a Lambda function that will create the task in the TaskStatus DynamoDB Table.

When an entry is created in this Table, a DynamoDB Stream will trigger the TaskStatusPublisher Lambda. This Lambda will check if this is a new entry (indicated by the INSERT) and in this case will publish a “TaskCreatedEvent”. It is important to note that this event also contains the Task Type. This is important as the type determines which processor needs to process it.

This is essentially where the first flow of the TaskManager ends. It is the responsibility of the Task Processor to create an EventBridge rule to consume this event and process the event.

The TaskManager expects to be regularly updated by the TaskProcessor via the TaskUpdatedEvent. The status of the event can be updated to RUNNING, SUCCESSFUL and FAILED. In the case of SUCCESSFUL, a payload can also be added. This could be the result of the task or in our case for the large exports, a signed S3 bucket URL to download it.

The Task Supplier can poll for the task regularly and get the status. Based on this status it can decide how to react.

Notice that the TaskStatusPublisher also publishes TaskRunningEvent, TaskSuccessfulEvent and TaskFailedEvent. This could be used in combination with a WebSocket mechanism to receive live updates instead of polling. However, this is out-of-scope for this blog.

This setup benefits from being completely serverless, meaning we can scale up on higher loads but also scale down to zero if there are no tasks. For this reason, in our case, we have only created one instance of this TaskManager that is shared by all tasks in our system. However, you could create multiple TaskManagers for different bounded contexts or even for each type of task.

CDK Project

The example CDK project of this setup can be found in this GitHub repository. There is a README file which explains how to build and deploy the project to your own AWS environment.

Final Thoughts

This pattern is a simple but powerful way to:

Work around API Gateway limitations
Build scalable async workflows
Keep your frontend responsive

If you're dealing with long-running operations in AWS, this approach is definitely worth considering.

Multi-Agent A2A with the Agent Development Kit(ADK), Amazon ECS Express, and Gemini CLI

xbill — Thu, 16 Apr 2026 22:47:15 +0000

Leveraging the Google Agent Development Kit (ADK) and the underlying Gemini LLM to build Multi-Agent Applications with A2A protocol support using the Python programming language deployed to AWS ECS Express.

Aren’t There a Billion Python ADK Demos?

Yes there are.

Python has traditionally been the main coding language for ML and AI tools. The goal of this article is to provide a multi-agent test bed for building, debugging, and deploying multi-agent applications.

Rock and roll ain’t noise pollution

So what is different about this lab compared to all the others out there?

This is one of the first deep dives into a Multi-Agent application leveraging the advanced tooling of Gemini CLI. The starting point for the demo was an existing Codelab- which was updated and re-engineered with Gemini CLI.

The original Codelab- is here:

Building a Multi-Agent System | Google Codelabs

Python Version Management

One of the downsides of the wide deployment of Python has been managing the language versions across platforms and maintaining a supported version.

The pyenv tool enables deploying consistent versions of Python:

GitHub - pyenv/pyenv: Simple Python version management

As of writing — the mainstream python version is 3.13. To validate your current Python:

python --version
Python 3.13.13

Amazon ECS Express

Amazon ECS Express Mode (announced Nov 2025) is a simplified deployment feature for Amazon Elastic Container Service (ECS) designed to rapidly launch containerized applications, APIs, and web services on AWS Fargate. It automates infrastructure setup — including load balancing, networking, scaling, and HTTPS endpoints — allowing developers to deploy from container image to production in a single step.

More details are available here:

Amazon ECS Express Mode

The ECS status is visible from the AWS Console:

Gemini CLI

If not pre-installed you can download the Gemini CLI to interact with the source files and provide real-time assistance:

npm install -g @google/gemini-cli

Testing the Gemini CLI Environment

Once you have all the tools and the correct Node.js version in place- you can test the startup of Gemini CLI. You will need to authenticate with a Key or your Google Account:

▝▜▄ Gemini CLI v0.33.1
    ▝▜▄
   ▗▟▀ Logged in with Google /auth
  ▝▀ Gemini Code Assist Standard /upgrade no sandbox (see /docs) /model Auto (Gemini 3) | 239.8 MB

Node Version Management

Gemini CLI needs a consistent, up to date version of Node. The nvm command can be used to get a standard Node environment:

GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

Agent Development Kit

The ADK can be installed from here:

Agent Development Kit (ADK)

Agent Skills

Gemini CLI can be customized to work with ADK agents. Both an Agent Development MCP server, and specific Agent skills are available.

More details are here:

Agent Development Kit (ADK)

To get the Agent Skills in Gemini CLI:

> /skills list
Available Agent Skills:

and the ADK documentation:

> /mcp list
Configured MCP servers:
🟢 adk-docs-mcp (from adk-docs-ext) - Ready (2 tools)
  Tools:
  - mcp_adk-docs-mcp_fetch_docs
  - mcp_adk-docs-mcp_list_doc_sources

Where do I start?

The strategy for starting multi agent development is a incremental step by step approach.

First, the basic development environment is setup with the required system variables, and a working Gemini CLI configuration.

Then, ADK Multi-Agent is built, debugged, and tested locally. Finally — the entire solution is deployed to Google Cloud Run.

Setup the Basic Environment

At this point you should have a working Python environment and a working Gemini CLI installation. All of the relevant code examples and documentation is available in GitHub.

The next step is to clone the GitHub repository to your local environment:

cd ~
git clone https://github.com/xbill9/gemini-cli-aws
cd multi-ecsexpress

Then run init2.sh from the cloned directory.

The script will attempt to determine your shell environment and set the correct variables:

source init2.sh

If your session times out or you need to re-authenticate- you can run the set_env.sh script to reset your environment variables:

source set_env.sh

Variables like PROJECT_ID need to be setup for use in the various build scripts- so the set_env script can be used to reset the environment if you time-out.

aws login --remote

Finally install the packages and dependencies:

make install

Verify The ADK Installation

To verify the setup, run the ADK CLI locally with the researcher agent:

xbill@penguin:~/gemini-cli-aws/multi-eks/agents$ adk run researcher
/home/xbill/.local/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
Log setup complete: /tmp/agents_log/agent.20260412_164250.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
{"asctime": "2026-04-12 16:42:50,986", "name": "root", "levelname": "INFO", "message": "Logging initialized for researcher", "filename": "logging_config.py", "lineno": 54, "service": "researcher", "log_level": "INFO"}
{"asctime": "2026-04-12 16:42:50,987", "name": "researcher.agent", "levelname": "INFO", "message": "Initialized researcher agent with model: gemini-2.5-flash", "filename": "agent.py", "lineno": 85}
{"asctime": "2026-04-12 16:42:50,988", "name": "google_adk.google.adk.cli.utils.envs", "levelname": "INFO", "message": "Loaded .env file for researcher at /home/xbill/gemini-cli-aws/multi-eks/.env", "filename": "envs.py", "lineno": 83}
{"asctime": "2026-04-12 16:42:50,988", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Using per-agent session storage rooted at /home/xbill/gemini-cli-aws/multi-eks/agents", "filename": "local_storage.py", "lineno": 84}
{"asctime": "2026-04-12 16:42:50,988", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Using file artifact service at /home/xbill/gemini-cli-aws/multi-eks/agents/researcher/.adk/artifacts", "filename": "local_storage.py", "lineno": 110}
{"asctime": "2026-04-12 16:42:50,988", "name": "google_adk.google.adk.cli.utils.service_factory", "levelname": "INFO", "message": "Using in-memory memory service", "filename": "service_factory.py", "lineno": 266}
{"asctime": "2026-04-12 16:42:50,993", "name": "google_adk.google.adk.cli.utils.local_storage", "levelname": "INFO", "message": "Creating local session service at /home/xbill/gemini-cli-aws/multi-eks/agents/researcher/.adk/session.db", "filename": "local_storage.py", "lineno": 60}
Running agent researcher, type exit to exit.



  
  
  Test The ADK Web Interface


This tests the ADK agent interactions with a browser:



xbill@penguin:~/gemini-cli-aws/multi-eks/agents$ adk web --host 0.0.0.0
/home/xbill/.local/lib/python3.13/site-packages/google/adk/features/_feature_decorator.py:72: UserWarning: [EXPERIMENTAL] feature FeatureName.PLUGGABLE_AUTH is enabled.
  check_feature_enabled()
2026-04-12 16:43:14,152 - INFO - service_factory.py:266 - Using in-memory memory service
2026-04-12 16:43:14,153 - INFO - local_storage.py:84 - Using per-agent session storage rooted at /home/xbill/gemini-cli-aws/multi-eks/agents
2026-04-12 16:43:14,153 - INFO - local_storage.py:110 - Using file artifact service at /home/xbill/gemini-cli-aws/multi-eks/agents/.adk/artifacts
/home/xbill/.local/lib/python3.13/site-packages/google/adk/cli/fast_api.py:198: UserWarning: [EXPERIMENTAL] InMemoryCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  credential_service = InMemoryCredentialService()
/home/xbill/.local/lib/python3.13/site-packages/google/adk/auth/credential_service/in_memory_credential_service.py:33: UserWarning: [EXPERIMENTAL] BaseCredentialService: This feature is experimental and may change or be removed in future versions without notice. It may introduce breaking changes at any time.
  super(). __init__ ()
INFO: Started server process [32675]
INFO: Waiting for application startup.






Then use the web interface — either on the local interface 127.0.0.1 or the catch-all web interface 0.0.0.0 -depending on your environment:



Special note for Google Cloud Shell Deployments- add a CORS allow_origins configuration exemption to allow the ADK agent to run:




adk web --host 0.0.0.0 --allow_origins 'regex:.*'







  
  
  Multi Agent Design


The multi-agent deployment consists of 5 agents:


Researcher
Judge
Orchestrator
Content Builder
Course Builder


For a detailed analysis of the multi-agent architecture- this article provides the background information:

Multi-Agent A2A with the Agent Development Kit(ADK), Cloud Run, and Gemini CLI


  
  
  Running/Testing/Debugging Locally


The main Makefile has been extended with extensive targets for managing the agents on the local development environment.

The key targets include:




xbill@penguin:~/multi-agent$ make help
Available commands:
  install - Install all dependencies for root, agents, and app
  start - Start all services locally (alias for start-local)
  stop - Stop all local services (alias for stop-local)
  run - Start all services locally (alias for start-local)
  local - Show local service URLs
  start-local - Start all local services in background
  stop-local - Stop all local processes
  test - Run all tests (pytest)
  test-researcher - Test the Researcher agent directly
  test-judge - Test the Judge agent directly
  test-orchestrator - Test the Orchestrator logic
  lint - Run linting checks (ruff)
  deploy - Deploy all services to Cloud Run
  destroy - Delete all Cloud Run services
  clean - Remove caches and logs






First check for local running agents:




xbill@penguin:~/gemini-cli-aws$ make status
Checking status of locally running agents and servers...
--- Network Status ---
No services listening on expected ports (8000-8004, 5173).
--- Process Status ---
No matching processes found.






Then all the agents can be started together:




✦ The frontend has been built and all local services (Researcher, Judge, Content Builder, Orchestrator, App Backend, and Frontend dev server) have
  been started in the background.

   - Frontend: http://localhost:5173 (http://localhost:5173)
   - Backend: http://localhost:8000 (http://localhost:8000)

  Logs for each service are available in the project root: researcher.log, judge.log, content_builder.log, orchestrator.log, backend.log, and
  frontend.log.






Then connect to the front end locally:



And the entire agent system will run in the local environment:




  
  
  Local Logging / Debugging


Gemini CLI has full access to the local agent logs for debugging and troubleshooting:




> review the local logs for the multi-agent run
✦ I will check run_local.sh and the project structure to determine where logs are stored or how they are generated.






This will verify the local operation of the code:




✦ The local logs confirm a successful multi-agent run for the topic "the history of the internet." Here is a summary of the execution flow:

* Orchestrator (orchestrator.log): Successfully managed the pipeline. It captured the topic, coordinated the Research-Judge loop, and escalated to
     content generation after the first iteration.
   * Researcher (researcher.log): Gathered approximately 9.2KB of research data using the google_search tool. It completed its task with a 200 OK
     response.
   * Judge (judge.log): Evaluated the findings and gave a "pass" status. The judge noted that the research was "comprehensive, accurate, and
     well-structured," making it an "excellent foundation for educational content."
   * Content Builder (content_builder.log): Successfully transformed the validated research into a structured Markdown course module and finished
     execution.
   * Backend & Frontend (backend.log, frontend.log): The FastAPI backend (port 8000) and Vite frontend (port 5173) are running and communicating with
     the orchestrator as expected.

Notable Observation:
   * A minor warning appeared in researcher.log: Researcher callback: 'response' not found or has no parts. However, this did not impact the
     successful completion of the research or the overall pipeline.

All services are currently active and logged at the DEBUG level as specified in run_local.sh.







  
  
  Deploying to Amazon Elastic Container Service (ECS)


The project level Makefile has targets for managing the Agent deployment to serverless endpoints. You can submit the build for ECS Express deployment:




make deploy
✦ The deployment was successful, and all 5 services are active on AWS ECS Express. You can access the Web App at the following URL:

  Web App (Course Creator): https://ad-65d6861112ff49099782001efe5e2721.ecs.us-east-1.on.aws

  The other microservices are also deployed and integrated:
   - Researcher: https://ad-8779b3dc720e4d9e9ca9b1091499084a.ecs.us-east-1.on.aws
   - Judge: https://ad-ab123be1fad04a9390e1d918f9b8ec04.ecs.us-east-1.on.aws
   - Content Builder: https://ad-622b8527fd1f41668624714f62deee0f.ecs.us-east-1.on.aws
   - Orchestrator: https://ad-c0f70b2d021744ec9761c2e54ca60287.ecs.us-east-1.on.aws






Once the containers are deployed- you can then get the endpoint:




✦ The Web App (Course Creator) endpoint is:

  https://ad-65d6861112ff49099782001efe5e2721.ecs.us-east-1.on.aws






The service will be visible in the AWS console:



And the entire system can be tested:




> make e2e-test-ecsexpress

✦ The end-to-end test of the AI Course Creator on AWS ECS Express was successful. The system, comprising 5 microservices, correctly researched
  "The History of the Internet," evaluated the findings, and generated a structured 4-module course. The public URL for the Web App is:

  https://ad-65d6861112ff49099782001efe5e2721.ecs.us-east-1.on.aws








  
  
  Running the Web Interface


Start a connection to the Cloud Run deployed app:




http://a27c61bc6fb3c425ca13d862e0fe4aed-865627292.us-east-1.elb.amazonaws.com






Then connect to the app :



Then use online course generator:




  
  
  Final Gemini CLI Code Review


As a final step — Gemini CLI was used for a full code review of the project:




✦ This multi-agent project is a well-engineered application of ADK 2.5 and the A2A protocol. The separation of specialized agents (Researcher,
  Judge, Content Builder) coordinated by a central Orchestrator demonstrates a mature microservice-oriented design.

Key Strengths
   * Coordinated Orchestration: The use of SequentialAgent and LoopAgent creates a robust, iterative research-judge cycle.
   * Resilient State Flow: The strategy of passing data through event content and "recovering" it via before_agent_callback heuristics is a clever
     way to handle state across distributed, independent session stores.
   * Polished Streaming: The web app's SSE implementation, specifically the greedy overlap deduplication (merge_strings) and system message
     cleanup, ensures a high-quality user experience despite the inherent noise in multi-agent LLM streams.
   * Cloud-Native Readiness: Using Identity Tokens for authenticated service-to-service communication and middleware for dynamic A2A URL rewriting
     makes the system ready for production deployment on Cloud Run.







  
  
  Summary


The Agent Development Kit (ADK) was used to build a multi-agent system with A2A support using the Gemini Flash LLM Model. This application was tested locally with Gemini CLI and then deployed to AWS ECS Express. Finally, Gemini CLI was used for a complete project code review.

AWS Data & AI Stories #01: Multimodal AI

Sedat SALMAN — Thu, 16 Apr 2026 18:49:58 +0000

In traditional AI systems, text was usually the main input.

But to solve real life problem, text is not enough by alone.

Today, many workloads include documents, images, audio, and video at the same time. A user may upload a PDF report, attach a photo, send a voice note, or provide a short video clip. If our solution only understands text, we miss a big part of the context.

This is where multimodal AI becomes important.

On AWS, multimodal AI is now becoming more practical. Amazon Bedrock Knowledge Bases supports multimodal content such as images, audio, and video, and AWS now provides different processing approaches depending on whether the goal is retrieval or structured extraction.

What is Multimodal AI?

Multimodal AI means an AI system can work with more than one type of data.

For example:

text
images
scanned documents
audio
video

Instead of focusing on only one format, the system can process and combine multiple data types to produce better results.

This is useful because enterprise data is rarely pure text. A lot of business value sits inside screenshots, scanned forms, call recordings, diagrams, inspection videos, and media-rich documents. AWS’s current multimodal stack is built around exactly that problem.

Why does it matter?

Because real systems are multimodal by nature.

Think about a few examples:

A support team receives images and voice notes from the field
A finance team works with reports, charts, and scanned documents
A healthcare team uses forms, reports, and medical images
An industrial operation stores inspection photos, maintenance PDFs, and recorded operator observations

In all of these cases, text-only AI is limited.

A multimodal approach helps us move from isolated files to connected understanding.

Multimodal AI on AWS

When I look at AWS from a practical point of view, I see multimodal AI as a workflow, not just a model.

A simple logical flow looks like this:

Collect multimodal data
Process and extract useful information
Store or index the result
Retrieve relevant context
Generate answers, summaries, or actions

AWS already has building blocks for this. Amazon Bedrock Data Automation is designed to extract structured insights from documents, images, audio, and video. Amazon Bedrock Knowledge Bases supports multimodal retrieval. AWS also supports Nova Multimodal Embeddings for visual and cross-modal retrieval scenarios.

Main AWS services to know

1. Amazon Bedrock Data Automation

This is useful when the main challenge is understanding raw input.

For example:

extracting information from documents
analyzing images
processing audio
turning video into structured output

So if the input is messy and unstructured, this is a strong starting point. AWS positions Bedrock Data Automation specifically for automating insight generation from unstructured multimodal content.

2. Amazon Bedrock Knowledge Bases

This is useful when the goal is retrieval.

If you want your AI application to search your content and answer questions based on it, Knowledge Bases becomes important. AWS documentation now states that Bedrock Knowledge Bases supports images, audio, and video in addition to traditional text-based content.

3. Amazon Nova Multimodal Embeddings

This is useful when the goal is similarity and cross-modal search.

For example:

finding images similar to another image
searching media with text
creating a shared semantic space across different content types

Amazon Nova Multimodal Embeddings supports text, documents, images, video, and audio in a single embedding space, which makes cross-modal retrieval possible.

A simple architecture view

At a high level, a multimodal AI architecture on AWS can look like this:

Data comes from users, applications, devices, or storage
Files are stored in Amazon S3
Bedrock Data Automation extracts useful content and structure
Bedrock Knowledge Bases indexes or connects relevant knowledge
Nova Multimodal Embeddings can support semantic and visual retrieval
A Bedrock-based application or assistant generates the final output

This approach is also reflected in AWS guidance and recent AWS machine learning posts around multimodal retrieval and multimodal assistants.

Retrieval or extraction?

This is one of the first design questions I would ask.

Do I want to extract information from the content?

Or do I want to retrieve relevant content across multiple modalities?

These are not exactly the same problem.

If the main need is converting raw media into structured output, Bedrock Data Automation is usually the right starting point.

If the main need is visual similarity or cross-modal search, Nova Multimodal Embeddings is often the better fit.

AWS explicitly separates these two approaches in its multimodal guidance, which is useful because many teams try to solve all multimodal problems in the same way.

Where can this be used?

There are many practical scenarios.

A few examples:

intelligent document processing
visual search
media search
support case analysis
industrial inspection workflows
knowledge assistants
report summarization from mixed content

For me, the important point is this: multimodal AI is not only about chat. It is also about turning different content types into usable business knowledge.

Common mistake

A common mistake is to think multimodal AI means only “upload file and ask question.”

That is too simple.

A real solution usually needs:

ingestion
extraction
indexing
retrieval
generation
governance

The model is only one part of the story.

Final thoughts

Multimodal AI is becoming a practical architecture topic on AWS.

Instead of treating text, images, audio, and video as separate worlds, we can now build workflows that connect them. AWS already provides managed building blocks for processing, retrieval, and generation across these content types, which makes multimodal design much more realistic than before.

For me, the first step is not choosing the model.

The first step is asking:

What type of data do I have?
What insight do I need?
Do I need extraction, retrieval, or both?
Do I want an assistant, a search engine, or a workflow?

If these answers are clear, the architecture becomes much easier.

In the next article, I will focus on Amazon Bedrock Data Automation and how it fits into a real multimodal workflow on AWS.

Monitorando AWS com Datadog: o que aprendi partindo do zero

Diogo Maske — Thu, 16 Apr 2026 14:07:47 +0000

🇧🇷O artigo está em PT-BR, fique à vontade para traduzir.
🇺🇲The article is in PT-BR, feel free to translate it.

☁️☁️☁️

Acabei de concluir o laboratório Introduction to Monitoring AWS with Datadog e quero compartilhar o que aprendi, porque foi bem mais interessante do que eu esperava. E também porque tive algumas dúvidas que acho que muita gente iniciante também teria.

Antes de começar, vou ser honesto: eu sei o que a AWS soluciona e entrega e tinha uma noção vaga do que era o Datadog ("aquela ferramenta de monitoramento cara"). Mas não entendia como os dois se conectavam na prática, nem por que isso seria importante no dia a dia de um time de DevOps.

O curso usa um app fictício chamado TechStories, uma plataforma de notícias e mídia social hospedada inteiramente na AWS, como base para os exercícios. Isso ajudou muito, porque deu um contexto real pra tudo.

O problema que o curso resolve

Imagine que seu time mantém uma aplicação rodando em EC2, com containers no ECS Fargate, banco de dados no RDS, funções Lambda e tabelas no DynamoDB. Como você sabe se está tudo funcionando bem? Você fica alternando entre console da AWS, CloudWatch, logs espalhados, é muito caótico.

O Datadog entra como uma camada única de observabilidade: você coleta métricas, logs e traces de tudo isso em um só lugar. O lab simulou exatamente esse cenário.

Como a integração AWS funciona por baixo dos panos

A primeira coisa que o curso explica é que existem basicamente dois jeitos de coletar dados da AWS no Datadog:

Via polling do CloudWatch — o Datadog consulta a API da AWS de tempos em tempos pra pegar as métricas. É a forma mais simples de configurar, mas tem um delay de alguns minutos.
Via Metric Streams — você configura a AWS pra empurrar as métricas pro Datadog em tempo quase real. Latência bem menor, ideal pra alertas críticos.

Na prática, pra começar você instala a integração AWS no Datadog, cria uma role IAM na sua conta com as permissões corretas, e aponta o Datadog pra essa role. Depois disso ele já começa a descobrir os recursos automaticamente.

O Datadog Forwarder e o negócio dos logs

Uma das partes que mais me fez parar e reler foi o fluxo de logs. Na AWS, os logs dos serviços gerenciados (Lambda, RDS, etc.) vão pro CloudWatch Logs. Mas o Datadog não lê o CloudWatch Logs diretamente, você precisa de um intermediário.

Esse intermediário é o Datadog Forwarder: uma função Lambda que você instala via CloudFormation e que fica "ouvindo" os CloudWatch Log Groups. Quando chega um log novo, ela encaminha pro Datadog. É bonito quando está pronto, mas exige configurar subscriptions pra cada log group que você quer monitorar.

No lab, depois de configurar isso, consegui ver os logs da Lambda keyword-insights-processor direto no Log Explorer do Datadog, com todos os campos estruturados, tags automáticas de ambiente, serviço, ARN da função, etc. Bem diferente de ficar vasculhando no CloudWatch.

Datadog Agent: quando os serviços gerenciados não são suficientes

Pra EC2 e containers, o Datadog tem o próprio agente, um processo que roda dentro da máquina/container e coleta métricas muito mais granulares do que o CloudWatch oferece: memória por processo, latência de disco, métricas customizadas, traces...

No caso do ECS Fargate, você sobe o Agent como um sidecar container na mesma task definition do seu serviço. Quando vi isso me pareceu muito trabalhoso, mas no lab eles mostram que dá pra fazer via CloudFormation, e as tags ficam todas consistentes por causa de um padrão de key:value definido nos recursos:

App:TechStories / Env:monitoring-aws-lab / Service:<nome-do-serviço>

Isso é fundamental. Sem tags consistentes, você não consegue filtrar nada no Datadog depois.

O que dá pra ver depois que tudo está integrado

O Resource Catalog mostrou tudo que foi descoberto na conta: 343 databases, 70 containers, 22 serverless functions, 1 host EC2... tudo categorizado, com região, ambiente e serviço associado. Dá pra clicar em qualquer recurso e ver as métricas diretamente.

Na seção de Metrics, busquei por aws.dynamodb e apareceram 22 métricas diferentes — capacidade de leitura/escrita, número de itens, tamanho das tabelas. Coisas que antes eu teria que montar dashboards manualmente no CloudWatch.

O AWS Overview Dashboard, que vem pronto como OOTB (out-of-the-box) no Datadog, já trouxe um panorama geral: 1 instância EC2 rodando, 4 monitores de status todos OK, 491 invocações Lambda na última hora, taxa de erro 0%, duração média de 988ms. Também dá pra ver traces das requisições HTTP diretamente no host EC2: cada request com host, serviço, recurso e latência.

O que ficou de lição 🧠

Mais do que as ferramentas em si, o lab reforçou uma coisa: observabilidade não é sobre acumular dados. É sobre ter os dados certos, com contexto suficiente (tags!) pra você conseguir responder perguntas quando algo dá errado.

A integração AWS + Datadog, quando bem configurada, te dá isso: um lugar só pra métricas, logs e traces, com correlação entre eles. Você vê que o tempo de resposta subiu, clica no trace, chega no log do Lambda, entende o que aconteceu.

Ainda tenho muito a aprender (APM, alertas, SLOs...), mas foi uma ótima base. Recomendo o Learning Center do Datadog pra quem quiser começar, os labs são práticos e o ambiente já vem configurado, então você foca no aprendizado em vez de ficar lutando com IAM.

Se quiser trocar ideia sobre isso ou acompanhar minha jornada, me encontra aqui no LinkedIn ✌️

The Setup Is the Strategy: How I Orchestrated a Product Migration with Claude Code

Karthik Subramanian — Thu, 16 Apr 2026 13:49:55 +0000

Most engineers using Claude Code are getting a fraction of its value. Not because the tool isn't capable — but because they're using it out of the box, unconfigured, the way you'd use a new IDE without installing extensions or setting up your build system. The default experience is decent. The configured experience is transformative.

I'm a Senior Software Engineering Manager leading a team focused on leveraging AI to find acceleration opportunities across the software development lifecycle. I've been playing around with AI tooling for a while and could see its potential, so I proposed a proof of concept: take a real product migration — the kind of project that would normally require a team of engineers across multiple sprints — and attempt it solo, using Claude Code as my primary development platform. Not "AI-assisted development" An AI-first model where every phase of the SDLC runs through Claude Code's feature set.

The migration itself was substantial:

4 legacy repositories consolidated into 2,
a database migration from MySQL to PostgreSQL,
framework upgrades across the full stack (Spring Boot 2 to 3, Java 17 to 21, React 17 to 18),
an authentication model replacement,
and complete test suites for everything.

What made this work wasn't Claude Code itself. It was how I set it up.

The skills that made me effective at leading engineering teams — providing clear context, delegating with specificity, reviewing rigorously, building repeatable processes — turned out to be exactly the skills that make Claude Code most effective. Engineers whose day-to-day revolves around writing code by hand sometimes struggle with this shift because the instinct is to do the work yourself, not to set up the system and direct it. I'd spent years not writing the code myself. I was already an orchestrator. The medium changed, the model didn't.

This post walks through how I configured Claude Code for a real migration, organized as building blocks. Each layer depends on the one below it. Skip the foundation and the rest falls apart.

Building Block 1: Planning — Laying the Foundation

Before any code was written, I built the context and planning infrastructure. This is the layer most people skip, and it's the layer that matters most.

CLAUDE.md — The Master Context

Claude Code reads CLAUDE.md files on every session start. They're your project memory — the equivalent of onboarding documentation for a new team member. I built a multi-level hierarchy:

Workspace-level (181 lines): overview of all 25+ repositories, tech stack summary, cross-service architecture, shared build commands
Domain-level: 18-service catalog, glossary of domain terms, JWT authentication architecture, service communication patterns
Per-repo: service-specific conventions, module structure, testing standards, local dev setup

Each level inherits from its parent. When Claude Code opens a session in any repo, it automatically has the full context stack — from the broadest architectural view down to the specific service conventions.

This is the single highest-leverage thing you can configure. A well-written CLAUDE.md prevents Claude from re-exploring your codebase every session, asking questions you've already answered, or making assumptions that contradict your architecture. It's free, it's immediate, and it compounds over time.

The Memory System

Claude Code has a persistent memory system — files that survive across sessions. I built 17 memory files organized by type:

User: who I am, my role, what I'm working on
Feedback: corrections that become permanent rules
Project: active work context, ticket maps, architectural decisions
Reference: pointers to external systems (Confluence pages, Jira boards, SonarQube dashboards)

The feedback memories are the most powerful. Every time I corrected Claude — "don't amend commits, it breaks CI and MR reviews" or "always fix all test failures before committing, even seemingly pre-existing ones" or "copy application-local.yml to worktrees because it's gitignored" — that correction became a permanent rule. One-time mistakes became permanent automation. After a few weeks, the memory system had captured dozens of workflow-specific rules that would take a new team member months to internalize.

The Context Funnel

For the planning phase itself, I fed Claude Code everything it would need to design the migration:

The four legacy repositories (full source access)
Dev database connections (read-only) to both MySQL and PostgreSQL
A reference implementation — a similar product that had already been migrated to the platform
Live Swagger documentation from upstream services (router, rostering, authentication APIs)

With this context loaded, I used the brainstorming skill (from the superpowers plugin) to generate the migration design across all eight repositories simultaneously. The skill enforces a structured process: explore context, ask clarifying questions, propose approaches with trade-offs, present the design for approval, then write a spec document.

I also used agent teams — an experimental Claude Code feature that runs parallel reviewers with independent context windows — to stress-test the design. Three independent agents reviewed the same architecture and caught issues a single pass missed:

Missing resume logic for interrupted user flows (a legacy endpoint had been removed without accounting for in-progress sessions)
Frontend state invalidation gaps in the data fetching layer
Unnecessary network hops that could be eliminated now that previously separate services lived in the same JVM

Giving AI direct database access allowed exact column-by-column mapping between the legacy and target schemas. It caught DDL mismatches — timestamp type differences, nullable column discrepancies, default value conflicts — that ORM annotations hide. Without this, the migration would have hit runtime errors that are painful to debug after the fact.

Atlassian MCP + Custom Jira Skill — From Design to Tickets

This is where the Atlassian MCP enters the story. It connects Claude Code directly to Jira and Confluence — no browser, no context switching.

First, the design became documentation: 20+ Confluence pages generated directly from Claude Code via MCP. Design documents, use case specifications, system architecture diagrams — all created and published without leaving the terminal. That said, this is where I hit my first major failure. The Atlassian MCP's updateConfluencePage tool silently truncates content beyond ~5KB. I asked Claude to update two design documents — 37KB and 46KB — and both were overwritten with partial content. I had to manually restore them from Confluence's page history. The data loss was real. I immediately encoded a memory rule: never update large Confluence pages via MCP, only add comments. Lesson learned the hard way.

Then came the decomposition. This was one of the most powerful things I did: I tasked Claude with breaking the architecture into Jira tickets scoped for three constraints:

Reviewable code reviews: no 2,000-line merge requests that reviewers rubber-stamp. Each ticket's scope had to produce a merge request a human could meaningfully assess.
QA throughput: QA can't test a monolithic "migrate everything" ticket. Each ticket needed to be independently testable with clear acceptance criteria.
Parallel development: tickets needed clean boundaries so multiple could be in-flight simultaneously without merge conflicts.

The result: 19 Jira tickets created in a single session from the design docs. Each with acceptance criteria in Atlassian Document Format, story points, sprint assignment, and a parent epic link. But it couldn't link them — the MCP tool for creating issue links between tickets throws a "not found" error. I had to go into Jira manually and add the "is blocked by" relationships myself. Not everything is automatable yet.

The Jira API has other quirks that would bite you every session without the right setup. So I built the my-jira skill — a custom skill file that encodes all the workarounds:

createJiraIssue renders newlines as literal \n text. The skill enforces a follow-up editJiraIssue call to fix formatting.
Story points live in customfield_10058, not the obvious-looking field. The wrong field silently saves to the wrong place — you'd never know until someone checks the sprint board.
QA testing note templates, project constants, sprint IDs, assignee account IDs — all encoded in one place.

One skill file eliminated an entire class of silent failures.

Building Block 2: Execution — The Development Loop

With the plan in place and tickets created, execution begins. Each ticket follows the same cycle: design doc, plan doc, execute, review, iterate, merge, move to QA. The tools enter the story as the workflow demands them.

Per-Ticket Planning

Every ticket — no matter how small — gets two documents before any code is written:

Design doc (what + why): the problem being solved, the approach, the constraints
Plan doc (how + steps): every file to change, every migration rule, every commit interval

I review the plan before execution starts. This is the gate. The AI generates, I validate. I know the domain, the constraints, the edge cases that don't show up in code. This is where the orchestrator model is most visible: I'm not writing plans by hand, but I'm reading every one and catching the things that only domain knowledge reveals.

Worktrees — Parallel Execution

Each ticket executes in a dedicated git worktree. Claude Code's /execute-plan skill runs the plan step-by-step in an isolated working directory.

At peak, I had 8 active worktrees across 2 repositories — 4 tickets developed concurrently. The tickets depended on each other, but the worktree model let me develop them in parallel and rebase with --onto as dependencies merged upstream. All four hit QA in the same sprint.

The practical limit: about 4 active Claude Code sessions at a time, depending on how many contexts you can keep in your head. You're reviewing output from multiple streams, making judgment calls, and keeping the overall architecture coherent. It's project management, not coding.

GitLab CLI + The `manage-mr` Skill

Merge requests aren't just git push. There's the strategy description, the pipeline to monitor, quality gates to check, and the fix-push-recheck cycle when something fails.

The manage-mr skill wraps the full lifecycle:

Create the MR with a description derived from the plan doc
Monitor the CI pipeline with /loop on a recurring interval
Check SonarQube quality gates
If anything fails: read the failure, trace to source, fix, re-push

The /loop skill deserves its own mention. It runs a command on a configurable interval — I used it to poll CI pipelines. Pipeline fails? Claude reads the build log, traces the error to the source file, applies a fix, pushes, and the loop continues. No browser, no manual checking.

One recurring failure pattern worth mentioning: AI would sometimes aggressively remove "unused" state variables without checking the callbacks that referenced them, breaking CI. It also missed secondary integration tests that asserted on the removed behavior. The fix was straightforward each time, but the pattern recurred enough that I added a memory rule: "verify all references before removing anything." The pipeline loop caught these quickly, but they shouldn't have happened in the first place.

SonarQube MCP

Connected via MCP server, Claude can query pull request issues, check quality gates, and fix vulnerabilities directly from the terminal. The migration shipped with 95%+ API coverage, 91% frontend coverage, zero bugs, zero vulnerabilities, and zero security hotspots at the time of QA handoff.

Chrome DevTools MCP

For frontend work, Claude needs to see the actual rendered application — not just the code. The Chrome DevTools MCP connects Claude to a live browser session. I log in, navigate to the page, and Claude inspects the live DOM, console errors, and network requests.

This is a game-changer for UI work. It finds CSS/layout bugs, missing state updates, and rendering issues that code-level analysis and screenshots could never surface. Claude can see what the user sees.

Figma MCP

During frontend porting, Claude references Figma designs directly via MCP. No screenshotting, no describing layouts in words. It reads the design context — component structure, spacing, colors, typography — and translates to code. This kept the ported UI faithful to the design without the constant back-and-forth of "does this match the mockup?"

Postman MCP

The API collection stays in sync with endpoint changes. Test scripts auto-chain with dynamic JWT extraction. This matters because QA depends on Postman to validate the API — if the collection is stale, they're blocked. The MCP integration ensures the collection reflects the latest API state at all times.

The `move-to-qa` Skill

When a ticket is ready for QA, there's a ritual: add structured testing notes (environment, credentials, test steps, caveats), transition the ticket to the QA column, notify the QA channel. Getting any step wrong means the QA engineer wastes time asking clarifying questions.

The move-to-qa skill encodes the entire handoff as a single invocation. One command handles the comment (in the exact template QA expects), the Jira transition, and the notification. Consistent handoff, every time, no steps skipped.

Keeping Everything in Sync

Here's where the orchestration model really pays off. When implementation changes a design decision or uncovers a requirement gap, Claude updates Confluence and Jira in the same session — with the caveat that large page edits go through comments, not full page updates (see the Confluence truncation lesson above). The old friction — finish code, open browser, update Jira, update Confluence — is the kind of manual chore that developers frequently skip. Now it's one prompt: "Update the design doc to reflect that we're using a materialized view instead of a join, and comment the change on the Jira ticket."

Documentation stays in sync because it's part of the workflow, not an afterthought.

Building Block 3: Review & Iteration

Code Review Plugins

The code-review and pr-review-toolkit plugins run multi-agent PR reviews with confidence-based scoring. They're effective as a first-pass filter:

Caught syntax and formatting bugs
Off-by-one errors in date filters
Missing transactional annotations
Raw data leakage in error responses

AI caught roughly 30-40% of issues — the low-to-mid-level stuff that humans miss under time pressure.

But the high-level stuff still needed a human reviewer: permission architecture that needed refactoring, structural design decisions for domain enums, Java stream filtering optimizations, missing API documentation annotations. These aren't bugs — they're design-level improvements that require understanding the system's intent, not just its syntax. AI review is a floor-raiser, not a ceiling-raiser. It catches what slips through, but it doesn't replace architectural judgment.

Responding to Review Comments

When human reviewers leave comments on merge requests, Claude reads and responds via the GitLab integration. Implement the requested changes, push, and the review loop continues — all from the terminal. The reviewer doesn't know or care that the fixes were AI-assisted. They just see responsive, well-reasoned changes.

The Cost

Honest accounting matters. Over the course of the migration — roughly 15 work days from planning through QA handoff — I spent close to $5,000 in API token costs running Claude Code through AWS Bedrock.

For a migration of this scope — four repos, database migration, full-stack framework upgrades, auth model replacement, ~50 tickets, ~580 tests — that's a fraction of what the engineering time alone would cost with a traditional team across multiple sprints.

Lessons learned on cost management:

Clear your context frequently. This is the single biggest cost lever. Claude Code caches your conversation context and re-reads it on every turn. Long marathon sessions accumulate enormous cache read and cache write charges that dwarf the actual input/output token costs. Use /compact aggressively, and prefer multiple shorter focused sessions over all-day marathons.
Use the right model for the job. Opus for planning, architecture, and complex reasoning. Sonnet for routine execution, test generation, and boilerplate. Haiku for quick lookups. The cost difference between models is significant and most execution work doesn't need the most powerful model.
The cost is front-loaded. The initial setup — CLAUDE.md files, skills, MCPs, memory rules, the design phase — was the most token-intensive period. Once configured, subsequent tickets were dramatically cheaper because the context was already built and the workflows were encoded.

Closing

By the end of the POC, the migration had produced roughly 50 tickets, 580 passing tests, 95%+ API coverage, and zero bugs, vulnerabilities, or security hotspots at QA handoff. One engineer, half a month, one tool — configured deliberately for every phase of the work.

The throughput increase didn't come from AI writing better code. It came from iterating faster, verifying more thoroughly, and managing parallel execution streams.

The building blocks made this possible:

Planning: CLAUDE.md gave the AI context. Memory gave it institutional knowledge. The brainstorming skill gave it structure. The Atlassian MCP and custom Jira skill turned designs into documentation and actionable, well-scoped tickets.
Execution: worktrees enabled parallel development. Skills encoded repeatable workflows. MCPs connected Claude Code to every system in the SDLC — version control, CI/CD, code quality, design tools, project management, documentation.
Review: plugins raised the floor on code review quality. Human reviewers caught the architectural and design-level issues that AI can't.

Each layer depends on the one below it. Skip the foundation — the CLAUDE.md files, the memory, the skills — and the execution layer produces mediocre results. That's what most people experience. They skip straight to "write me some code" without investing in the setup, get underwhelming output, and conclude the tool isn't useful.

The setup is the strategy.

If you're starting from zero, here's my recommendation: write your CLAUDE.md first. Just the basics — tech stack, project structure, build commands, conventions. Then add one MCP integration for the system you context-switch to most often (probably your issue tracker). Then build one custom skill for your most repeated workflow. Build up from there. Each layer makes the next one more effective.

Control Your Tesla from the Terminal with a Kiro CLI Skill

Jérôme GUYON — Thu, 16 Apr 2026 08:49:16 +0000

🔗 https://github.com/guyon-it-consulting/myteslamate-skills-and-power

Last Tuesday, I was deep into a CDK refactor — the kind where I have 14 files open and I'm scared to blink. Then a thought hit me: did I turn on Sentry mode? My car was parked at the train station. I could grab my phone, open the Tesla app, wait for it to wake the car, scroll to Security, check the toggle… or I could just not break my flow.

What if I could ask my coding assistant instead?

Turns out, I can. I built a Kiro CLI skill that lets me control my Tesla straight from the terminal. It was also the perfect excuse to learn how to create a Kiro CLI Skill 😊 — and what better way to test a new feature than with something fun? Check the battery, lock the doors, toggle Sentry mode, pull up charging stats — all without leaving my editor. The secret ingredient? An MCP server that wraps APIs that any AI assistant can call.

What is MyTeslaMate?

Before we get to the skill itself, let me introduce the engine behind it.

MyTeslaMate is the hosted version of TeslaMate, the most popular open-source data logger for Tesla vehicles. If you own a Tesla and you haven't heard of TeslaMate, stop reading and go look at it. It continuously records every drive, charge session, sleep cycle, and software update into a PostgreSQL database, and exposes rich Grafana dashboards — battery degradation, charging curves, trip history, lifetime stats, vampire drain, efficiency trends, and more.

MyTeslaMate takes all of that and hosts it for you. No Docker, no self-hosting, no database maintenance. It adds premium features like supercharger cost import, automations, fleet management, and — this is the part we care about — an MCP server.

The MCP server at https://mcp.myteslamate.com/mcp wraps two APIs into a single endpoint:

API	Tools	What it does
Tesla Fleet API	98	Vehicle commands, energy control, charging, navigation, security
TeslaMate API	9	Drive stats, charging analytics, efficiency data, trip history

That's 100+ tools accessible from any MCP-compatible AI assistant. Authentication is handled via OAuth SSO with Tesla's authorization server.

What is a Kiro CLI Skill?

A skill is how you teach Kiro CLI about a specific domain. It's a markdown file with YAML frontmatter that describes what the skill does and when to activate it. Think of it as a cheat sheet that Kiro loads on demand — it doesn't bloat your context until you actually need it.

A skill has two parts:

The frontmatter — metadata that tells Kiro when to load the skill:

---
name: tesla-commands
description: Control your Tesla vehicle and energy products via MyTeslaMate MCP server.
  Use when the user asks about their car, vehicle status, lock/unlock, climate control, charging, Powerwall, solar production, energy optimization, Sentry mode, trip planning, drive statistics, or any Tesla-related query. Triggers on "tesla", "my car", "vehicle",
  "charge", "battery", "climate", "powerwall", "solar", "sentry", "lock", "unlock",
  "supercharger", "road trip", "energy", "charging history", "drive stats".
---

The body — capabilities, workflow instructions, and safety rules that guide the agent:

# Tesla Commands

The `tesla-mcp` server exposes **100+ tools**.

## Capabilities
### Vehicle Control (64 commands)
- Doors & Access: lock, unlock, open/close trunk, open frunk
- Climate: start/stop HVAC, set temps, seat heaters, steering wheel heater
- Charging: start/stop charge, set charge limit, schedule charging
...

## Workflow
1. Use @tesla-mcp tools directly for all Tesla operations.
2. Check current state before making changes.
3. Wake the vehicle before sending action commands if the car is asleep.

## Safety
- Confirm with the user before executing security-sensitive commands.
- Always show current state before making changes.

The skill lives in ~/.kiro/skills/tesla-commands/SKILL.md. But a skill alone isn't enough — you also need an agent that knows how to use it.

The Tesla agent configuration

I created a dedicated agent: a JSON file that ties everything together: the skill, the MCP server and the tools.

{
  "name": "tesla",
  "description": "Tesla vehicle and energy control agent via MyTeslaMate MCP server",
  "prompt": "You help the user monitor and control their Tesla vehicle and energy products. Use the tesla-mcp tools for all operations. Present data in a human-readable format. Confirm before executing security-sensitive commands.",
  "tools": ["read", "shell", "grep", "glob", "@tesla-mcp"],
  "allowedTools": ["read", "@tesla-mcp"],
  "resources": [
    "skill://.kiro/skills/tesla-commands/SKILL.md"
  ],
  "mcpServers": {
    "tesla-mcp": {
      "url": "https://mcp.myteslamate.com/mcp"
    }
  },
  "welcomeMessage": "Tesla control ready. What would you like to do with your car?"
}

A few things worth noting here:

resources uses the skill:// URI scheme. This tells Kiro to load the skill's metadata at startup but defer loading the full content until it's actually needed. No wasted context. (See Agent Configuration Reference in the Kiro docs: "skill:// — Skills progressively loaded on demand".)
mcpServers points to the remote MyTeslaMate MCP server in this case, no local mcp server needed.
allowedTools auto-approves read and all @tesla-mcp tools so you don't get prompted for every single API call.

How to set it up

Prerequisites: You'll need a Tesla vehicle (obviously) and a MyTeslaMate account. Sign up, link your Tesla account, and pick a subscription plan. This gives you access to the MCP server and the TeslaMate analytics dashboards.

Step 1: Clone the repo and copy the files.

git clone https://github.com/guyon-it-consulting/myteslamate-skills-and-power.git
cd myteslamate-skills-and-power

# Copy the skill
cp -r kiro/skills/tesla-commands ~/.kiro/skills/

# Copy the agent
cp kiro/agents/tesla.json ~/.kiro/agents/

Step 2: Start a new Kiro CLI session and switch to Tesla Agent

$ kiro-cli

/agent swap tesla

✔ Switched to agent: tesla
Tesla control ready. What would you like to do with your car?

Step 3: Authenticate with Tesla.

Run /mcp. The tesla-mcp server will show ⚠ auth-required. Follow the instructions to copy the OAuth URL, open it in your browser, and sign in with your Tesla account. This is a one-time step — the token persists across sessions.

Using it

Now the fun part. Just talk naturally:

> Is Sentry mode on?

Nope — Sentry Mode is currently off on your Model Y. 
It is available though, so I can turn it on for you if you'd like.
Want me to enable it?

> What's my battery at?

Fresh data from TeslaMate:
- Battery level: 80% (hit your charge limit!)
- Estimated range: ~411 km
- Charging state: Complete — plugged in but done charging
- Energy added this session: 34.1 kWh

Looks like it finished charging since we last checked (was at 77% earlier).
You're topped up to your 80% limit.

> Lock my car

Your car is already locked according to the latest status.
No action needed!

> How much did I spend on charging this month?

Here's your April charging summary (so far, through April 10):

┌──────────────────┬──────────┬───────────────┬────────────┐
│ Type             │ Sessions │ Energy        │ Cost       │
├──────────────────┼──────────┼───────────────┼────────────┤
│ Supercharger     │ 2        │ 105.0 kWh     │ €37.88     │
│ Home/Destination │ 5        │ 60.98 kWh     │ €0*        │
│ **Total**        │ **7**    │ **166.0 kWh** │ **€37.88** │
└──────────────────┴──────────┴───────────────┴────────────┘

No Data, estimating home/destination charging at ~€0.25/kWh, that's roughly €15 extra,
bringing the estimated total to around €53

> What's my battery health status ?

Your battery is in great shape:
- Battery health: 98.6%
- Current capacity: 75.7 kWh (out of 76.8 kWh max)
- Current max range: 506 km (vs 512 km when new)
- Degradation: only ~1.4% 

Very healthy for a car with 435 drives logged.
Nothing to worry about there.

The agent checks the current state before making changes, asks for confirmation on security-sensitive commands, and presents data with proper units. All of that behavior comes from the SKILL.md instructions.

Things to know

100+ tools, one endpoint. The MyTeslaMate MCP server covers vehicle control, vehicle data, energy/Powerwall/solar, charging history, and TeslaMate analytics. You don't need to know which API to call — the agent figures it out.
Wake before you command. Tesla vehicles go to sleep to save battery. The skill instructs the agent to wake the car before sending action commands. You'll see a brief delay the first time.
Safety checks. The skill explicitly tells the agent to confirm before executing unlock, disable Sentry, remote start, or erase data. You won't accidentally unlock your car because of a typo.
OAuth, not API keys. Authentication goes through Tesla's OAuth flow via MyTeslaMate. The token is scoped and can be revoked from your Tesla account at any time.

— Jérôme

DEV Community: AWS Community Builders

Event-driven media intelligence with AWS Step Functions and Bedrock

Why serverless is the right shape for this problem

Architecture at a glance

Walking through each component

Putting it together: an end-to-end request

Things that bite you in production

Where this design shines

Where to take it next

Resurface Claude Code Usage Across Your Team with CloudWatch OTEL (No Lambda)

Architecture

Why This Works

Setup

IAM Execution Role

API Gateway with AWS Service Integration

API Key Authentication

Configure Your Tools

Claude Code

Claude CoWork (Team & Enterprise)

GitHub Copilot CLI

Gemini CLI

Cursor (via Hooks)

What You Get

Region Availability

Gotchas

Cost

When NOT to Use This

Security Considerations

Beyond Coding Agents

Source Code & One-Click Deploy

Further Reading

AWS Data & AI Stories #02: Amazon Bedrock Data Automation

What is Amazon Bedrock Data Automation?

Why does BDA matter?

How I would position BDA in an AWS architecture

Main concepts to understand

1. Projects

2. Blueprints

Standard output vs custom output

Standard output

Custom output

What types of content can BDA process?

Where BDA fits best

1. Intelligent document processing

3. Audio and video understanding

4. Compliance and content review

A practical workflow example

Newer capabilities worth watching

Things to keep in mind

1. Start simple

2. Design for the business output

3. Watch input requirements

4. Treat prompts and blueprints carefully

Final thoughts

Supercharge AWS Diagrams in VSCode with Mermaid and Custom Icons

🔧 Icon Packs You'll Use

✅ Step 1: Install Markdown Preview Enhanced

⚙️ Step 2: Inject Icon Packs into Mermaid

How to set it up:

🖼️ Step 3: Create a Diagram with AWS Icons

🎉 That’s It!

🛠 Bonus Tips

Building a Multimodal Agent with the ADK, AWS Fargate, and Gemini Flash Live 3.1

Aren’t There a Billion Python ADK Demos?

In the Spirit of Mr. McConaughey’s “alright, alright, alright”

What Is Python?

Python Version Management

Amazon Fargate

Gemini Live Models

Gemini CLI

Testing the Gemini CLI Environment

Node Version Management

Agent Development Kit

Where do I start?

Setup the Basic Environment

Build the User Interface

Test The User Interface

Verify The ADK Installation

Test The ADK Web Interface

Lint and Test the Main Python Code