DEV Community

Running Claude Code in 4 Parallel Sessions Led to 'Team Development' — 7 Recipes to Prevent Collisions

orca_forge — Thu, 27 Aug 2026 00:43:40 +0000

📝 Originally published (in Japanese) at forge.workstyle.tech.

In a previous article, we introduced an environment for parallel execution of coding agents using Git worktrees. This article is a follow-up. As we progressed with parallelization, we ended up with 3-5 Claude Code sessions simultaneously developing the same microservices. What happened was no longer just "parallel execution of tools" but actual "team development".

All the issues that arise in human teams—miscommunication, deployment conflicts, and territorial overlaps—occur here as well. And the practices that work for human teams work almost identically here. We’ll share seven recipes that emerged from actual operations, along with real-life close calls.

Real-Life Story: Averting a Deployment Rollback Disaster at the Last Minute

One day, while Session A (responsible for voice functionality) was in the middle of a major refactor, Session B (responsible for streaming functionality) sent this message:

"We’re about to build the frontend as version 1.0.399 (based on main)."

At first glance, this seemed fine. However, in this repository, the authoritative branch for the production environment was not main but a dedicated deployment branch. The latest features from the past few dozen versions were only in the deployment branch, while main was outdated. If Session B had deployed an image based on main, weeks’ worth of features would have been rolled back in production.

Session A immediately sent a warning, and Session B halted the build before pushing. Session B then cherry-picked their changes into the deployment branch and rebuilt the image, avoiding the disaster entirely. All this communication was handled autonomously between the agents via session-to-session messages. I (the human) only learned about it later from the logs.

This incident highlights two things: parallel agents can cause the same accidents as human teams, and with proper communication channels and rules, they can prevent accidents just like human teams.

Recipe 1: Physically Separate Territories with Worktrees and Repositories

Assign a dedicated Git worktree to each session (as described in the previous article).
Explicitly define which session is responsible for which service/directory. For example, the voice session handles talk-related components, the streaming session handles broadcast-related components, and the phone session handles only the callgw directory.
For shared worktrees, enforce the rule: "Always check the branch and git status before committing." This became a strict rule after a past incident where one session almost committed staged changes from another session in a shared tree.

Recipe 2: Pre-Start Notification, Scope Declaration, and Completion Report

This is equivalent to a human team’s daily stand-up. Agents exchange session-to-session messages (or use a shared notes file if messaging isn’t available) to communicate:

Before starting: "I’ll be working on expressive_voice.py and env. I won’t touch the prompt section in talk_service.py."
Upon completion: "Base branch: X, commit: Y. Changes made in these two places. Image version 1.5.1072 reserved."

The key is declaring the scope. By stating not only "what will be done" but also "what won’t be touched," other sessions can safely continue parallel work. In practice, this alone nearly eliminated file conflicts.

Recipe 3: Reserve Image Tags and Version Numbers

Container image tags are shared namespace. If two sessions build different content with the same tag, say 1.0.399, it leads to tag overwrite, a hard-to-detect issue (we once experienced a nightmare where a chained command error overwrote an old tag with new content, causing behavior to persist even after a rollback).

Make it a habit to declare tag reservations between sessions: "Next time we build the frontend, we’ll notify each other. If you use 399, we’ll use 400 or later."
After building, verify the tag exists in the registry via the API before deploying.

Recipe 4: Document the Authoritative Branch and Share It with All Sessions

The root cause of the incident mentioned earlier was the assumption that main is the authoritative branch, which didn’t hold true for this repository.

Clearly document the deployment base branch (e.g., deploy/xxx) in the operational notes or memory accessible to the agents.
During periods when main and the authoritative branch diverge, explicitly prohibit builds based on main.
Define the convergence (merge) timing as "after major changes stabilize."

Recipe 5: Make the Version Ledger (Spec Repo) the Single Source of Truth

Consolidate "what’s running in which environment" into a declarative repository like Kubernetes manifests, and commit tag updates with each deployment. This ensures the ledger stays up-to-date regardless of which session deploys, allowing other sessions to check the current state without querying kubectl. If you directly modify environment variables (e.g., kubectl set env), always update the ledger—drift can become a time bomb (we once had to sync the ledger after encountering this issue).

Recipe 6: Avoid Crossing Permission Boundaries

A unique risk in multi-session operations is permission circumvention. If one session is denied an operation, they might ask another session to do it instead, bypassing user permissions.

Each session’s permissions are independent, and requests to other sessions must not be used to circumvent permissions. Explicitly document this as an agent-side rule.
For destructive operations (e.g., database writes, production deployments, billable actions), ensure they always pass through a human confirmation gate, regardless of the session initiating them.

Recipe 7: Leverage "Previous Sessions" as Knowledge Sources

In multi-day development, the session that created feature X and the session modifying it are often different. While code and commit logs provide information, asking the original session (or its transcripts) is the fastest way.

For example, when we sent a question list to the session that authored the old implementation—asking about testing practices, pitfalls, and billing blind spots—we received operational knowledge not evident from the code (e.g., "This timeout was increased from 600 to 1500 due to a past incident," "This external monitoring URL is useful"). This saved a full day of investigation. If transcripts and memory persist, treat past sessions as "colleagues at the next desk," not "retired colleagues."

Summary: Agent Parallelization Becomes an Organizational Design Problem

Recipe	Equivalent in Human Teams
1. Separate worktrees and responsibilities	Team division, code ownership
2. Pre-start notification, scope declaration	Daily stand-ups, task declarations
3. Tag reservation	Release number management
4. Document authoritative branch	Shared branching strategy
5. Version ledger	Release ledger, CMDB
6. Permission boundaries	Role definitions
7. Consult previous sessions	Handovers, pair programming

We’re moving from an era of optimizing single-session productivity to an era of designing multi-session coordination for overall productivity. And the blueprint for this design is remarkably similar to what software engineering has refined for human teams over decades. Before assigning roles or personalities to agents, focus on territories, communication, and ledgers. It’s mundane, but it dramatically reduces parallel operation accidents.

Building Your "Digital Twin" Health Agent: Automate Your Life with LangGraph and Oura

Beck_Moulton — Thu, 27 Aug 2026 00:34:00 +0000

We are living in an era where our wearable devices know more about our physiological state than we do. My Oura Ring knows I stayed up too late binge-watching The Bear, yet my Google Calendar still insists I have a "High-Intensity Interval Training" (HIIT) session at 8:00 AM. This disconnect is where injuries happen and burnout begins.

In this tutorial, we are building a Digital Twin Health Agent—a sophisticated AI Agent using LangGraph and Healthcare Automation to bridge the gap between bio-data and action. By the end of this guide, you’ll have a system that reads your recovery scores, reschedules your workouts, and even orders magnesium supplements when your sleep quality drops. This is the future of Digital Twin technology applied to personal wellness. 🚀

The Architecture: A Feedback Loop for Your Body

Unlike a simple linear script, a health agent needs to maintain state and make conditional decisions. If your recovery is 90+, push hard; if it's below 50, swap that CrossFit session for Yoga.

Here is how the data flows through our LangGraph state machine:

graph TD
    A[Start: Morning Trigger] --> B{Fetch Oura Data}
    B --> C[Analyze Recovery Score]
    C --> D{Is Score < 60?}
    D -- Yes --> E[Reschedule Google Calendar to 'Rest/Yoga']
    D -- No --> F[Confirm High-Intensity Workout]
    E --> G[Check Nutrient Deficiencies]
    F --> H[End Loop]
    G --> I{Low Magnesium/Sleep?}
    I -- Yes --> J[Draft Instacart Order]
    I -- No --> H
    J --> H

Prerequisites

To follow this advanced guide, you'll need:

LangGraph & LangChain: For orchestration.
Oura Cloud API: Access to your readiness/sleep data.
Google Calendar API: To modify your schedule.
Python 3.10+

Step 1: Defining the Agentic State

In LangGraph, everything revolves around the State. We need to track our physiological metrics and our current calendar status.

from typing import TypedDict, List, Annotated
from langgraph.graph import StateGraph, END

class HealthState(TypedDict):
    recovery_score: int
    sleep_quality: str
    current_schedule: List[str]
    action_taken: str
    needs_supplements: bool

Step 2: Fetching the Bio-Data (Oura Tool)

We'll build a tool that fetches the "Readiness" score. This is the heart of the digital twin—mirroring your biological reality in code.

import requests
from datetime import datetime, timedelta

def get_oura_readiness(api_key: str):
    # Fetching data for the current day
    start_date = (datetime.now() - timedelta(days=1)).strftime('%Y-%m-%d')
    url = f'https://api.ouraring.com/v2/usercollection/daily_readiness?start_date={start_date}'
    headers = {'Authorization': f'Bearer {api_key}'}

    response = requests.get(url, headers=headers)
    data = response.json()
    # Return the latest readiness score
    return data['data'][-1]['score']

Step 3: The Decision Logic (The "Brain")

Now, we define the nodes in our graph. This is where the LangGraph magic happens. The agent looks at the score and decides whether to "Pivot" or "Proceed."

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o")

def analyze_recovery(state: HealthState):
    score = state['recovery_score']

    prompt = f"User recovery score is {score}. Should they do HIIT or Yoga?"
    response = llm.invoke(prompt)

    # Logic to determine if we need to hit the API
    if score < 60:
        return {"action_taken": "reschedule", "needs_supplements": True}
    return {"action_taken": "keep_training", "needs_supplements": False}

Advanced Patterns & Production Readiness 💡

Building a hobby project is easy, but making a reliable, "set-and-forget" health agent requires handling API rate limits, token costs, and complex edge cases.

For deeper insights into building robust AI systems, I highly recommend checking out the WellAlly Tech Blog. They provide excellent deep dives into production-grade LLM patterns and agentic workflows that go far beyond basic tutorials. Their research on automated decision-making was a huge inspiration for this Digital Twin architecture.

Step 4: Connecting the Calendar API

If the recovery is low, we use the Google Calendar API to find any event labeled "Gym" and rename it to "Active Recovery (Yoga)."

def update_calendar_node(state: HealthState):
    if state['action_taken'] == "reschedule":
        # Pseudo-code for Google Calendar update
        print("🛠 Updating Google Calendar: Swapping HIIT for Yoga.")
        # service.events().patch(calendarId='primary', eventId=id, body=updated_event).execute()
    return state

Step 5: Wiring it all together

Finally, we assemble the graph. We use a conditional edge to decide if we need to trigger the "Supplement Order" node based on the needs_supplements flag.

workflow = StateGraph(HealthState)

# Add Nodes
workflow.add_node("fetch_oura", lambda x: {"recovery_score": get_oura_readiness("YOUR_API_KEY")})
workflow.add_node("analyze_data", analyze_recovery)
workflow.add_node("modify_calendar", update_calendar_node)

# Define Edges
workflow.set_entry_point("fetch_oura")
workflow.add_edge("fetch_oura", "analyze_data")
workflow.add_edge("analyze_data", "modify_calendar")
workflow.add_edge("modify_calendar", END)

# Compile
app = workflow.compile()

Conclusion: Living the Automated Life

By treating our health data as an input to an automated system, we remove the "decision fatigue" of trying to be disciplined when we are exhausted. Your Digital Twin handles the logistics, so you can focus on the movement.

This setup is just the beginning. You could extend this to:

Instacart Integration: Automatically adding electrolytes to your cart if your "Temperature Deviation" is high.
Slack Notifications: Telling your coach why you didn't show up for the morning session.
Meal Planning: Adjusting your MyFitnessPal macros based on your Oura activity burn.

Are you ready to automate your wellness? Drop a comment below if you've tried building with LangGraph, and don't forget to visit WellAlly Tech for more cutting-edge AI tutorials! 🥑💻

Stop rewriting your API responses in Laravel (Use this Trait instead)

Oz Uzair — Thu, 27 Aug 2026 00:25:25 +0000

If you are building API-driven applications, nothing clutters up your controllers faster than manually typing out response()->json(...) arrays every single time you need to return data or throw an error.

When you have inconsistent response structures, your frontend (and the developers consuming your API) will constantly have to guess whether the data is nested under ['data'], ['payload'], or just at the root of the object.

The cleanest way I've found to standardize this across an entire application is by creating a dedicated ApiResponse trait.

Instead of rewriting your JSON structure in every controller method, create this trait in your app/Traits directory:

namespace App\Traits;

use Illuminate\Http\JsonResponse;

trait ApiResponse 
{
    protected function success(mixed $data, ?string $message = null, int $code = 200): JsonResponse 
    {
        return response()->json([
            'status' => 'success',
            'message' => $message,
            'data' => $data
        ], $code);
    }

    protected function error(string $message, int $code = 400, array|string $errors = []): JsonResponse 
    {
        // Force errors into an array format for consistent frontend parsing
        $formattedErrors = is_string($errors) ? [$errors] : $errors;

        return response()->json([
            'status' => 'error',
            'message' => $message,
            'errors' => $formattedErrors
        ], $code);
    }
}

Next, simply use this trait inside your base Controller.php.

Now, your actual endpoints become incredibly readable and strictly standardized:

namespace App\Http\Controllers;

use App\Models\Task;
use Illuminate\Http\Request;
use Illuminate\Http\JsonResponse;
use Throwable;

class TaskController extends Controller
{
    public function store(Request $request): JsonResponse
    {
        $validated = $request->validate([
            'title' => 'required|string|max:255',
            'description' => 'nullable|string'
        ]);

        try {
            $task = Task::create($validated);

            return $this->success($task, 'Task successfully generated', 201);

        } catch (Throwable $e) {
            // Note: Exposing raw exception messages is fine for local dev, 
            // but should be sanitized or logged in production environments.
            return $this->error('Failed to generate task', 500, [$e->getMessage()]);
        }
    }
}

This guarantees that every single endpoint in your application returns the exact same JSON signature. Your frontend will thank you.

How are you handling global API responses in your current stack? Do you use traits, or do you prefer wrapping everything in dedicated Resource classes? Let me know below.

Disclosure: Formatted using Ai so I don't get laughed at with grammatical mistakes 😂

Azure ExpressRoute vs VPN Gateway: the honest comparison

Victor — Thu, 27 Aug 2026 00:24:06 +0000

Your datacenter needs to talk to Azure. You can send that traffic through an encrypted tunnel over the public internet, or over a private circuit that never touches it. That single choice — shared road or private rail — decides cost, speed, and reliability.

Almost every organization moving to Azure keeps something on-premises, and those two worlds have to connect privately. Azure gives you two hybrid-connectivity options, and they take opposite routes to the same destination: VPN Gateway and ExpressRoute. Understanding them is really understanding one question — does your traffic ride the public internet, protected by encryption, or a dedicated line that bypasses it entirely?

VPN Gateway: an encrypted tunnel over the internet

Microsoft's description is exact: Azure VPN Gateway "can be used to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet." Your traffic still travels the ordinary internet, but inside an IPsec/IKE tunnel, so it is private even though the road is shared. It comes in a few shapes: site-to-site (your datacenter's VPN device to Azure), point-to-site (an individual remote worker to the VNet), and VNet-to-VNet. It is quick to stand up, needs no third party, and is inexpensive — the pragmatic default for dev/test and small-to-medium production links.

ExpressRoute: a private, dedicated circuit

ExpressRoute takes the other road entirely. It "lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider." The defining fact: because ExpressRoute connections do not go over the public internet, they offer "more reliability, faster speeds, consistent latencies, and higher security than typical connections over the internet." You are not tunnelling through shared roads; you have a private rail line into Microsoft's network, arranged through a connectivity provider. That extra reliability and consistency costs more and takes longer to provision — but for a bank, a hospital, or a latency-sensitive enterprise workload, it is the answer.

	VPN Gateway	ExpressRoute
Path	Public internet (encrypted tunnel)	Private dedicated circuit
Reliability & latency	Best-effort internet	More reliable, consistent latency
Setup	Fast, self-service	Via a connectivity provider
Cost	Lower	Higher
Best for	Dev/test, small-medium prod, remote users	Enterprise, regulated, latency-sensitive

A VPN tunnels privately through the public road. ExpressRoute gives you a private road of your own. Same destination, very different guarantees.

They are not mutually exclusive. The grown-up pattern often uses both: ExpressRoute as the primary private connection, with a site-to-site VPN as a secure failover path if the circuit goes down. Microsoft supports this coexistence directly. So the question is not always "which one" — sometimes it is "ExpressRoute with a VPN safety net."

How to choose

Getting started, dev/test, or a small-to-medium workload where good-enough internet connectivity is fine? VPN Gateway. Fast, cheap, no provider to involve.
Remote individual users needing into the VNet? A point-to-site VPN.
Enterprise scale, strict reliability or latency needs, regulated industry, or heavy sustained data transfer? ExpressRoute — the private, consistent circuit is worth the cost and the lead time.
Mission-critical link that cannot go dark? ExpressRoute primary, VPN failover.

The mistake is treating them as "cheap one vs expensive one." They are "shared road with a lock" versus "your own private line," and the right pick follows from how much reliability, consistency, and privacy the workload genuinely demands. Say "a site-to-site VPN for now, and ExpressRoute when we need consistent latency and an SLA on the connection — with the VPN kept as failover" and you are talking hybrid networking like an architect.

Questions people also ask

Is ExpressRoute more secure than VPN Gateway?

ExpressRoute keeps traffic off the public internet, which removes a whole class of exposure a VPN carries by design. But an ExpressRoute circuit is not encrypted by default. For data that must be encrypted in transit, add MACsec on the circuit or run an IPsec VPN over ExpressRoute. VPN Gateway is encrypted from the start, just over a shared path.

Can you use ExpressRoute and VPN Gateway together?

Yes, and Azure supports the coexistence directly. The common pattern runs ExpressRoute as the primary private circuit and a site-to-site VPN as the failover path, so if the circuit drops, traffic falls back to an encrypted tunnel over the internet instead of going dark.

How much does ExpressRoute cost compared to a VPN Gateway?

ExpressRoute costs more. Its tiers run from a metered Local option up to Standard around $300 a month for 1 Gbps, plus a Premium add-on, before you add the connectivity provider's own charges. A VPN Gateway has a much lower flat cost since it rides the internet you already pay for and needs no third-party provider.

What is the difference between ExpressRoute and a site-to-site VPN?

A site-to-site VPN connects your on-premises network to Azure through an encrypted tunnel over the public internet. ExpressRoute connects the same two networks through a private circuit arranged with a connectivity provider, bypassing the internet entirely for more consistent latency and reliability.

Which is faster, ExpressRoute or VPN Gateway?

ExpressRoute is faster and more consistent. Because it does not share the public internet's congestion and routing variability, it delivers predictable latency and higher throughput. A VPN Gateway's speed depends on internet conditions between your site and Azure, which vary and can degrade under load.

MyZubster Is Not Trying to Build Another App — We're Exploring a Verifiable Digital Ecosystem

Daniel Ioni — Thu, 27 Aug 2026 00:21:32 +0000

MyZubster Is Not Trying to Build Another App — We're Exploring a Verifiable Digital Ecosystem

For years, software development has largely followed the same pattern:

User → Application → Database → Service

AI changed part of that equation.

IoT changed another part.

Blockchain introduced new models for provenance and ownership.

But there is still a difficult problem connecting all of them:

How can a digital system verify what actually happened in the real world?

This is one of the questions driving the development of MyZubster.

MyZubster is an Italian open-source digital ecosystem currently under development.

It hasn't reached its final public form yet.

And that's important.

Because we're not presenting a finished platform.

We're documenting how the architecture evolves.

From application to ecosystem

Calling MyZubster simply an "app" increasingly feels incomplete.

The architecture we're exploring connects several layers:

                MYZUBSTER

         ┌─────────────────┐
         │   REAL WORLD    │
         │ people / places │
         │ devices / events│
         └────────┬────────┘
                  │
                  ▼
         ┌─────────────────┐
         │      DATA       │
         │ sensors / users │
         │ external sources│
         └────────┬────────┘
                  │
                  ▼
         ┌─────────────────┐
         │   PROVENANCE    │
         │ source / time   │
         │ context / proof │
         └────────┬────────┘
                  │
                  ▼
         ┌─────────────────┐
         │       AI        │
         │ interpretation  │
         │ automation      │
         └────────┬────────┘
                  │
                  ▼
         ┌─────────────────┐
         │    EVIDENCE     │
         │ verification    │
         │ reproducibility │
         └────────┬────────┘
                  │
                  ▼
         ┌─────────────────┐
         │ DIGITAL SERVICES│
         └─────────────────┘

The goal isn't to put every technology imaginable into one application.

The interesting part is the connection between these layers.

AI needs evidence

Generative AI can produce extraordinary outputs.

But generation and verification are fundamentally different operations.

An AI system can say:

"This intervention reduced water consumption by 30%."

But where did that number come from?

What sensor produced the original measurement?

What period was compared?

What methodology was used?

Was the dataset modified?

Can somebody reproduce the calculation?

This leads to a principle we're increasingly using when thinking about MyZubster:

AI ≠ Source of Truth

Instead:

Evidence
↓
AI
↓
Interpretation
↓
Verification
↓
Decision

AI becomes a tool operating on evidence, rather than a machine expected to manufacture truth.

Connecting software to physical reality

This becomes particularly interesting with IoT.

Imagine an environmental pilot containing:

soil sensors
water meters
weather data
field observations
images
timestamps
GPS/context information

Collecting those values isn't enough.

We need provenance.

A measurement should ideally answer:

WHAT was measured?
WHERE?
WHEN?
BY WHICH DEVICE?
USING WHICH METHOD?
WHO/WHAT processed it?
WHAT transformation occurred?
CAN IT BE REPRODUCED?

Only then can we begin transforming raw measurements into meaningful digital evidence.

Why we're exploring MRV

This is also why we're increasingly interested in MRV: Measurement, Reporting and Verification.

A simplified pipeline might look like:

REAL EVENT
↓
MEASUREMENT
↓
RAW DATA
↓
PROVENANCE
↓
PROCESSING
↓
KPI
↓
REPORT
↓
VERIFICATION

This model is useful far beyond environmental projects.

It could eventually matter for:

sustainability;
circular economy;
agriculture;
digital identity;
decentralized systems;
IoT;
supply chains;
community contributions;
public-interest infrastructure.
The LIFE 2027 direction

We're currently exploring whether a focused part of this architecture could eventually support a future LIFE 2027 proposal.

The important word is exploring.

This is not an announcement of EU funding or a finalized consortium.

The work happening now is about understanding what could realistically be measured and validated.

We're beginning conversations around areas such as environmental data, agronomic information, circular water, irrigation reuse, scientific methodology, KPI/MRV and data governance.

The question isn't:

How do we fit MyZubster into a European project?

The better question is:

Is there a measurable environmental problem where this architecture can demonstrate something useful?

That's a much harder question.

And therefore a much more interesting engineering problem.

Open source becomes part of verification

Open source normally means that people can inspect the code.

But imagine extending that principle.

Developers inspect the implementation.

Researchers inspect the methodology.

Machines inspect structured evidence.

Communities inspect results.

Independent contributors attempt reproduction.

CODE
+
DATA
+
METHODOLOGY
+
EVIDENCE
+
REPRODUCIBILITY
=
TRUST

Not absolute trust.

Inspectable trust.

That distinction matters.

GitHub isn't just where the code lives

In this architecture, repositories can become part of the project's historical record.

Commits document changes.

Pull requests document discussion.

Issues document problems.

CI documents whether assumptions survive automated tests.

Releases document specific states of the system.

This doesn't make GitHub a source of real-world truth.

But it can provide something extremely valuable:

software provenance.

And software provenance can be connected to data provenance.

Failure needs to remain visible

There's another principle we're trying to preserve.

If everything always appears successful, the evidence isn't very useful.

Tests must be allowed to fail.

Experiments must be allowed to produce negative results.

AI conclusions must be challengeable.

Scientific hypotheses must be falsifiable.

Open-source contributors must be able to say:

"This doesn't work."

A trustworthy system isn't one where failure disappears.

It's one where failure becomes observable information.

What exists today?

MyZubster remains under active development.

There is code.

There are repositories.

There are experimental components.

There are prototypes.

There are architectural proposals.

And there are ideas that still need to survive contact with reality.

Those categories shouldn't be confused.

We don't want to call a roadmap feature "production."

We don't want to call an exploratory discussion a "partnership."

And we don't want to call an AI-generated conclusion "verified evidence."

The distinction between these states is becoming part of the architecture itself.

What comes next

The biggest challenge isn't adding more features.

It's proving one complete pipeline.

Something like:

Physical Event
↓
Measurement
↓
Provenance
↓
Evidence
↓
AI Analysis
↓
KPI
↓
Independent Validation
↓
Reproducible Result

If we can make that pipeline work on a real use case, we have something meaningful.

Then it can be improved.

Then replicated.

Then scaled.

If it fails, we document why.

That's still progress.

The future may belong to software that can show its work

The first generation of the web connected documents.

Social networks connected people.

Cloud platforms connected services.

IoT connected devices.

AI is connecting knowledge and computation in entirely new ways.

The next challenge may be connecting all of this to verifiable reality.

That's the direction we're exploring with MyZubster.

Not:

"Trust the platform."

But:

"Inspect the evidence."

MyZubster

Build → Measure → Verify → Connect → Replicate

opensource #ai #iot #softwaredevelopment #sustainability #blockchain #greentech #programming #data #myzubster

Fintech Shipment Fan-Out: SaaS Retention Cleanup and the Node.js Cron-Queue Boundary

eliasfischer8351 — Thu, 27 Aug 2026 00:20:29 +0000

Short answer: use a scheduled cleanup endpoint when one indexed, bounded pass can finish predictably; use a queue when cleanup must be divided into independently retriable batches. For a fintech SaaS that fans out shipment updates to many subscribers, latency and cost should be judged at the system boundary: a cheap cleanup run is not a good bargain if it contends with delivery or leaves retention evidence incomplete.

The first design decision is to keep shipment fan-out separate from retention work. A shipment update has a latency-sensitive path. Expired subscriptions, old delivery attempts, and temporary fan-out records usually have a policy-driven path. They may share a database, but they should not share an unbounded transaction or an execution budget.

This distinction matters more than the spelling of a cron expression. It also gives the team a useful test: can the cleanup be repeated safely while the shipment update path continues to make progress?

How should a Node.js SaaS choose a cron or queue for scheduled cleanup?

Measure the worst case first. Count eligible records by tenant, check the relevant index, estimate lock pressure, and measure a bounded pass while the database is serving normal shipment traffic. The median duration is not the decision variable; the tail is. A scheduled data cleanup is a good fit for one HTTP-triggered run when its cutoff, tenant scope, batch size, and completion state can be recorded and the run has room to finish before its execution limit.

The cutoff should be computed by the application and persisted with the run. A schedule has jitter, and a paused schedule may not replay every missed invocation. “Delete records older than the cutoff captured at run start” is therefore more auditable than silently recalculating the boundary for every page. The query should also exclude legal holds, active disputes, and any retention exception required by the business policy.

Keep it bounded.

The boundary is operational.

When a tenant can monopolize a scan, when the pessimistic duration approaches the execution limit, or when one failed slice should not restart the entire pass, let the scheduled trigger produce work for queue consumers. Cron still supplies the clock; workers supply the execution boundary. A process-local Node.js timer does neither reliably in a multi-replica deployment, because each replica can make its own decision about when to run.

Consider a cleanup run with tenant-17 as the largest scope. The producer records one cutoff and emits a sequence of batch identities, each representing a bounded ordinal rather than a mutable list of row IDs. A worker claims the next slice using the eligibility predicate and a limit, records the claim, and commits the expiration transition with its completion marker. A retry does not need to know whether the first attempt reached the database, lost its connection after commit, or was made visible again after its timeout; it checks the marker and the conditional state, then reports a duplicate completion as a normal outcome. Meanwhile, a separate delivery worker can continue to process shipment updates because cleanup concurrency is capped and because the cleanup query uses the intended index rather than scanning the delivery history without a boundary. If the tenant has more eligible records than one run can handle, the next scheduled run continues from recorded state or creates the next immutable batch set, depending on the storage model. Neither choice should silently move the cutoff, because doing so makes the audit trail ambiguous: an operator could no longer tell whether a record was outside policy at the first run or merely missed by a later page. This is the kind of detail that makes a queue worthwhile, but it is also the detail that makes a queue expensive to operate.

Why do old records need idempotency and an audit trail?

Deletion is an irreversible business effect, even if the database operation itself is ordinary. Exactly-once transport is not a sound assumption. The stronger and more practical invariant is an exactly-once business effect: a retry must find an already completed state and become a no-op, or it must apply the same conditional transition without changing the result.

Give each cleanup run a stable identifier, cutoff, tenant scope, batch identity, attempt count, and outcome. Store discovered, processed, skipped, and remaining counts separately. Those numbers answer different reconciliation questions. A single success flag cannot show whether the producer stopped before batch 12, whether a worker received it twice, or whether a transaction committed the state marker but not the intended record transition.

For a queue, publish a compact reference containing the tenant, cutoff, and batch ordinal rather than copying all records into the message. A worker can load the current eligible set, claim a bounded slice, and commit its completion marker with the state change where the storage model permits it. Redelivery then encounters the marker and exits cleanly. I've found that this evidence is more valuable than a promise that a particular scheduler will never retry.

There is a second boundary when the cleanup signs callbacks or batch manifests. Use a keyed construction rather than treating a hash of public fields as authentication. RFC 2104 defines HMAC as a keyed-hash mechanism; the key belongs in secret management, and the signed material should include the immutable cutoff and batch identity. Authentication does not make deletion reversible, so it cannot replace legal holds or a carefully scoped eligibility query.

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "strconv"
    "time"
)

func batchID(key []byte, tenant string, cutoff time.Time, ordinal int) string {
    mac := hmac.New(sha256.New, key)
    fmt.Fprintf(mac, "%s\x00%s\x00%s", tenant, cutoff.UTC().Format(time.RFC3339), strconv.Itoa(ordinal))
    return hex.EncodeToString(mac.Sum(nil))
}

func main() {
    cutoff := time.Date(2026, 8, 1, 0, 0, 0, 0, time.UTC)
    fmt.Println(batchID([]byte("secret-from-a-secret-store"), "tenant-17", cutoff, 12))
}

The function creates a deterministic identity; it does not by itself deduplicate work. The completion record still needs a transactional write with the expiration effect, or an equivalent conditional operation. Small details matter here. A batch identity built from a different timestamp format on the producer and consumer is not the same identity, even though both strings may look reasonable.

What does a queue add to Node.js cleanup cost and latency?

The comparison is not “cron is simple, queue is fast.” A single scheduled pass has little orchestration overhead and may be the least expensive operational shape for small, predictable datasets. A queue adds messages, workers, visibility management, metrics, and reconciliation, but it can lower the tail latency of individual batches, cap concurrency, and isolate a slow tenant from other tenants.

Shape	Good fit	Main trade-off
One scheduled HTTP cleanup	One indexed pass with a clear cutoff and bounded work	The invocation is the failure and retry unit
Scheduled producer plus queue workers	Uneven or large datasets and independently retriable batches	More state, metrics, and duplicate-delivery handling
Durable workflow	Dependencies, approvals, or compensating steps	Unnecessary machinery for one bounded delete pass

AWS describes an SQS visibility timeout as the period during which a received message is hidden from other consumers; if the consumer does not finish and delete it within that period, it can become visible again. Set that timeout from observed worker duration, with room for database latency, and retain an idempotent consumer because timeout tuning cannot remove every duplicate-delivery path.

A queue is not automatically faster. If consumers contend for the same index or table locks, added concurrency can increase both tail latency and cost. Start with a small concurrency limit, watch database wait time and the age of the oldest unresolved batch, then increase concurrency only when the storage layer can absorb it. I'm not sure any universal concurrency number would survive a change in tenant distribution; measure the workload you actually retain.

The catch is that a queue creates more evidence to reconcile: enqueue success, worker receipt, visibility timeout, completion marker, and final deletion. Choose the timer when batch-level evidence is unnecessary. Choose the queue when that evidence, independent retry, or tenant isolation is worth the operational cost.

Which cleanup boundary protects shipment fan-out?

The cleanup worker should never decide that shipment delivery is complete merely because a record was selected for deletion. Keep delivery state, subscriber acknowledgement, and retention eligibility as separate facts. An old delivery attempt can be removable only after the policy says it is removable; it should not disappear because the fan-out producer is under pressure.

In practical terms, give the cleanup path its own database budget, concurrency limit, and alerts. Watch delivery latency alongside cleanup duration, lock waits, oldest eligible record, and unresolved batch age. A green process metric is insufficient if records are steadily accumulating or shipment notifications are waiting behind a broad delete.

The recommended shape is not suitable when retention requires approval per tenant, deletion has compensating steps, or a complete audit record must exist for every independent batch. In those cases, use a queue or durable workflow even if a timer could technically perform the deletes. Stick with a single scheduled pass when the dataset is indexed, bounded, and policy decisions are already settled.

A cautious rollout for scheduled data cleanup

Start in report-only mode. Produce the eligible count and oldest candidate per tenant without changing data, and compare the result with retention configuration, legal holds, disputes, and the shipment subscriber model. Then run a narrow age window, persist the cutoff and counts, and inspect database load before widening the window.

For a queue migration, have the scheduler emit immutable batch identities. Workers should be restartable, bounded, and quiet when they see a completed identity. Alert on the age of the oldest unresolved batch, not only on process exit, because a healthy worker can still be starved by a bad partition or an oversized tenant.

The decision rule is compact: use a cron-style scheduled cleanup for a short, repeatable pass; use queue workers when the work needs independent retry, throttling, or tenant isolation. The correct design preserves the shipment update's latency budget and leaves enough audit evidence to explain every retention decision later.

References

Latest Trends in GPU Cloud Cost Reduction and Containerized Data Centers

orca_forge — Thu, 27 Aug 2026 00:12:38 +0000

📝 Originally published (in Japanese) at forge.workstyle.tech.

Introduction

In recent years, the demand for GPUs has surged with the widespread adoption of AI and machine learning. Particularly, the demand for the latest NVIDIA GPUs is notable, leading to an increase in GPU cloud services offered by cloud providers. Among these developments, containerized data centers are gaining attention. This article explores cost reduction in GPU cloud services and the latest trends in containerized data centers.

Main Content

Benefits of Containerized Data Centers

Containerized data centers offer the following advantages:

Rapid Deployment: Compared to traditional building-based data centers, they can be deployed much faster.
Suitability for Regional Locations: They can be utilized as locally-focused infrastructure.
Expanded Options: Alongside traditional data centers, containerized options are increasingly being offered as an alternative.

Efforts to Reduce GPU Power Consumption

GPU power consumption significantly impacts data center operational costs. Recent efforts include:

Power Consumption Reduction: Proof-of-concept experiments have reported up to 80% reduction in power consumption.
Visualization Technology: Combined with locally-focused containerized data centers, next-generation infrastructure solutions are being explored.

Key Trends in Japan

In Japan, the following trends are observed:

Cloud Provider Entry: Multiple cloud providers have launched GPU cloud services.
Adoption of Latest GPUs: Services are being deployed with early adoption of NVIDIA's latest GPUs (e.g., H200).
Power Issue Solutions: High-efficiency conversion, high-density, and containerization are proposed as solutions to power-related challenges.

Conclusion

With the growing demand for GPU cloud services, containerized data centers are attracting significant attention. Their benefits, including rapid deployment and reduced power consumption, are diverse. In Japan, services adopting the latest GPUs are emerging successively, drawing attention to future developments. For companies aiming for cost reduction and efficient infrastructure, containerized data centers present a compelling option.

reimagine-it v2.4.2 — One command, 15 design tokens, 80% source-fidelity floor

K Merchant — Thu, 27 Aug 2026 00:12:00 +0000

What it is

reimagine-it is a one-command agent skill that redesigns an existing HTML file into a beautiful, working artifact — using only the nouns, dates, colors, links, and numbers already in that file. No mood boards, no gold layouts with swapped labels. The output is a real page you can open.

npx reimagine-it@2.4.2 -i mypage.html -o redesigned.html

What's new in v2.4.2

1. Source fidelity floor raised to 80% across every token

Before v2.4.2, 61 of 105 token×source cells fell below 80% fidelity — the engine preferred headings over real source anchors, so phrases like "Venator Become" or "Arcade Tee" never rendered. Now:

Anchors = headings + source anchors, deduplicated — every clickable phrase survives.
All 105 token×source cells ≥80% (worst token: 80%).
All seven shipped examples report 100% fidelity in their auto.json reports.

2. Links and emails surface on every token

A shared Source-index footer renders all content.links and emails on every generated page — not just the webpage/landing tokens.

3. All 15 design tokens in the browser extension

The popup now exposes all 15 tokens: webpage, landing, dashboard, infographic, cinematic, artistic, photography, svg, 3js, simulation, glass, editorial, motion, gradient, showcase.

4. Docs can't drift anymore

A new docs-drift CI job regenerates the case tables and fails the build if they diverge from ground truth.

The 15 design tokens

Token	What it builds
`webpage`	Clean content-first page
`landing`	Conversion-focused landing
`dashboard`	KPI dashboard from facts
`infographic`	Paper-poster argument
`cinematic`	Film-poster energy
`artistic`	Expressive art direction
`photography`	Photo-led layout
`svg`	Living SVG mark
`3js`	WebGL orbit scene
`simulation`	Interactive timeline
`glass`	Glassmorphism UI
`editorial`	Magazine layout
`motion`	Animated micro-interactions
`gradient`	Bold gradient arena
`showcase`	Product showcase

Measured, not vibes

57/57 unit tests pass
15-token benchmark: all tokens hold the 100/100 usability bar
100-source stress test: 0 errors, fidelity avg 99.7, min 80
7 end-user examples at 100% fidelity

Try it — no install

Live gallery (no install): https://kayforkind.github.io/reimagine-it/
Repo: https://github.com/Kayforkind/reimagine-it
npm: npx reimagine-it@2.4.2

Give it one HTML file. It gives you back something worth opening.

RFLCT: Bringing Runtime Type Metadata to TypeScript 7

Remo H. Jansen — Thu, 27 Aug 2026 00:11:08 +0000

If you've built large-scale applications in TypeScript, chances are you've used a Dependency Injection (DI) container. As the creator of InversifyJS, I've spent years thinking deeply about inversion of control, decoupling, and how to make enterprise patterns feel natural in TypeScript.

But for all those years, there has been a glaring elephant in the room: our heavy reliance on experimentalDecorators and emitDecoratorMetadata.

These compiler flags have served us well, but they are exactly that—experimental. They tie us to legacy decorator implementations, require specific compiler configurations, and often feel like a magic black box that doesn't perfectly align with modern build pipelines. I've spent a lot of time recently thinking about how we could finally drop these flags entirely while keeping the developer experience pristine.

With the release of TypeScript 7, I'm thrilled to introduce the solution: 🪞 RFLCT.

What is RFLCT?

RFLCT is an ahead-of-time (AOT) reflect metadata injector for TypeScript 7. It injects design:symbols and design:arguments directly at build time.

Zero decorators. Zero emitDecoratorMetadata.

It integrates seamlessly with virtually any build tool (Vite, Rollup, webpack, esbuild) via unplugin, or you can use the built-in CLI using the TypeScript 7 API for standalone tsgo projects.

Let's look at how it actually feels to write code with RFLCT.

The Magic: Before and After

With RFLCT, you annotate the types you want to expose to your runtime metadata using a special Reflect<T> wrapper type.

What you write:

import { Reflect, resolve } from "rflct";

interface Shape { sides: number; }

class Polygon {
  constructor(
    public shape: Reflect<Shape>,
    public label: Reflect<string, { optional: true }>
  ) {}
}

// resolve<T>() → the runtime identity of T (Symbol for interfaces, class for classes)
container.bind(resolve<Shape>()).to(Polygon);

What RFLCT compiles it to:

Notice how the interfaces are safely converted into global Symbols, and metadata is explicitly registered without a single decorator in sight.

import "reflect-metadata";

const __RFLCT_Shape = Symbol.for("@acme/shapes@1|src/geo.ts|Shape");

class Polygon {
  constructor(shape, label) {}
}

Reflect.defineMetadata("design:arguments", [
  { type: __RFLCT_Shape, metadata: {} },
  { type: String, metadata: { optional: true } }
], Polygon, undefined);

container.bind(__RFLCT_Shape).to(Polygon);

Reflect.defineMetadata("design:symbols", Object.assign(
  Reflect.getMetadata("design:symbols", Reflect) ?? {}, {
    "@acme/shapes@1|src/geo.ts|Shape": __RFLCT_Shape,
    "@acme/shapes@1|src/geo.ts|Polygon": Polygon,
  }
), Reflect);

Broader Than Just InversifyJS

While my primary motivation for building RFLCT was to pave the way for the next generation of InversifyJS, this underlying primitive—a reliable, decorator-free way to emit runtime type metadata—unlocks so much more.

Because RFLCT standardizes how types are mapped to memory at build time, it has massive potential across the ecosystem:

Custom DI Engines: Build your own lightweight inversion of control containers without metadata boilerplate.
Object Mapping & Hydration: Easily map database or API JSON results directly back into instantiated classes.
RPC Frameworks: Guarantee type-safe network boundaries by validating incoming arguments against compile-time metadata.
Runtime Validation: Perform deep runtime validation by reading exactly what types a constructor or method expects.

How It Works: The Three Transformations

Under the hood, RFLCT performs three core transformations during your build step:

1. `design:symbols` — The Global Type Registry

Every class, interface, and type alias in a file is registered in a process-wide Map on the global Reflect object.

Interfaces & Types become universally unique Symbols (e.g., Symbol.for(qualifiedName)).
Classes map directly to their constructor.

2. `design:arguments` — Parameter Type Metadata

Any parameter annotated with Reflect<T> (or Reflect<T, Metadata>) tells the compiler to produce a Reflect.defineMetadata("design:arguments", [...], target, key) call:

Constructors: target = ClassName, key = undefined
Methods: target = ClassName.prototype, key = "methodName"

3. `resolve<T>()` — Compile-Time Type Resolution

Writing resolve<T>() acts as a macro. It is replaced at compile time with the actual runtime identity of T:

resolve<Shape>() compiles to Symbol.for("...Shape")
resolve<Triangle>(Triangle) compiles simply to Triangle

Smart Symbol Qualification

A massive headache with metadata in the past has been duplicate dependencies causing symbol collisions. Generated symbols use Symbol.for(qualifiedName) structured as packageName@majorVersion|packageRelativePath|TypeName. This prevents collisions, allows minor/patch versions to share symbols, and ensures that shared library types resolve to the exact same symbol reference in memory.

Getting Started (Alpha Preview)

⚠️ **Note:* RFLCT is currently in its early 0.0.1-alpha.0 stage and the npm module has not yet been published to the public registry.*

For now, to try it out, you will need to download the source directly from GitHub and build it locally.

1. Build from Source

git clone https://github.com/your-username/rflct.git
cd rflct
npm install
npm run build
npm link

2. Project Setup

Link the local package to your project:

npm link rflct
npm install reflect-metadata

You'll need to import reflect-metadata once at your application's entry point to polyfill the global Reflect.defineMetadata APIs:

// entry.ts
import "reflect-metadata";

3. Configure Your Build Tool

Because RFLCT is built on top of unplugin, it drops straight into your existing pipeline.

Vite:

// vite.config.js
import { vitePlugin } from "rflct/vite";

export default {
  plugins: [vitePlugin()],
};

(Plugins for Rollup, esbuild, and webpack are also available out of the box!)

If you are running a standalone tsgo project without a bundler, the CLI leverages the TS 7 API:

npx rflct -p tsconfig.json -o dist --check

Looking Forward & Next Steps

Dependency Injection in TypeScript is finally growing up. By moving metadata generation to a clean, predictable build step, we can leave experimental decorators in the past and write DI code that feels native to modern TypeScript.

So, what's next?
The immediate next step for me is to start experimenting with integrating RFLCT directly into InversifyJS. I'll be testing how seamlessly we can migrate existing IoC containers to this new AOT metadata approach.

I can't wait to see what you build with it! Clone the repo, try it in your projects, and let me know what you think.

Agent-to-Agent Discovery in SMESH: Why Coordination Isn't Enough Without Runtime Introductions

mech.app — Thu, 27 Aug 2026 00:06:59 +0000

You can build a working agent mesh with QUIC transport, encrypted messaging, and decentralized coordination. Five processes can reinforce independent conclusions and let unsupported signals decay. The mesh works. Then you try to introduce it to another agent and discover you have no standard way to ask what the swarm can do. No retained task to retrieve after an internal signal expires. No interoperable progress stream. No cancellation contract. No artifact another framework would understand.

SMESH is a Rust-based decentralized agent framework that hit this boundary. The author had built a society with no border crossing. The solution was Google's Agent2Agent (A2A) protocol, announced in April 2025 and moved under Linux Foundation governance in June 2025. A2A provides the missing public contract: a way for agents built by different vendors to discover one another, exchange messages, and collaborate without sharing private memory, tools, or internal plans.

The Cold-Start Problem in Agent Meshes

Traditional service meshes solve discovery with a central registry. Kubernetes has etcd. Consul has its catalog. Envoy has xDS. You register your service, get a DNS name or IP, and other services find you. This works because services are relatively static and the registry is the source of truth.

Agent meshes are different. Agents are ephemeral, context-dependent, and often spawned on demand. They need to:

Discover peers without a central registry
Exchange capability metadata at runtime
Negotiate protocols without pre-shared configuration
Maintain security boundaries during introduction

The coordination primitives (message passing, consensus, signal decay) assume agents already know about each other. Discovery is the layer below coordination. SMESH had the top layer working but no way to bootstrap the bottom layer without manual wiring.

What A2A Provides

A2A is not a coordination protocol. It is an introduction protocol. The spec defines:

Discovery handshake: How agents announce themselves and query peer capabilities
Capability exchange: Structured metadata about what an agent can do (tasks, inputs, outputs)
Message envelope: Standard format for task requests, progress updates, cancellations, and results
Security boundary: Agents expose capabilities without revealing internal state, tools, or memory

This maps to the HTTP layer in microservices, not the application layer. A2A is the contract that lets heterogeneous agents talk. What they say after introduction is up to them.

SMESH Architecture Before A2A

SMESH uses a decentralized coordination model:

QUIC transport: Encrypted, multiplexed connections between agent processes
Signal propagation: Agents broadcast observations and reinforce conclusions from peers
Decay mechanism: Unsupported signals lose weight over time
No central orchestrator: Coordination emerges from peer interactions

The missing piece was the gateway layer. Agents inside the mesh could coordinate. Agents outside the mesh had no entry point. The author describes this as "a society with no border crossing."

Adding the A2A Gateway

The implementation added a tested gateway layer that:

Exposes A2A-compliant discovery endpoints
Translates A2A task requests into SMESH internal signals
Maps SMESH coordination state to A2A progress updates
Handles cancellation by injecting decay signals

The gateway is not a proxy. It is a protocol adapter. Internal agents still use QUIC and signal propagation. External agents use A2A. The gateway translates at the boundary.

Discovery Flow

Here is how an external agent discovers and tasks a SMESH mesh:

Capability query: External agent sends A2A discovery request to gateway
Gateway response: Returns aggregated capabilities from internal agents (tasks, input schemas, output schemas)
Task submission: External agent sends A2A task request with inputs
Internal translation: Gateway converts task to SMESH signal and broadcasts to mesh
Coordination: Internal agents reinforce or decay the signal based on their observations
Progress streaming: Gateway polls internal state and emits A2A progress updates
Result or cancellation: Gateway returns final result or handles cancellation via decay injection

The gateway maintains no task state. It is a stateless translator. Task retention happens inside the mesh via signal persistence.

Security Boundaries

A2A enforces separation between public and private state:

Layer	Exposed	Hidden
Capabilities	Task names, input/output schemas, supported protocols	Tool implementations, internal prompts, model weights
Task state	Progress percentage, status enum, public artifacts	Internal signals, peer votes, decay timers
Coordination	Final consensus result	Signal propagation graph, reinforcement weights
Transport	A2A HTTP/JSON or gRPC	QUIC connections, encryption keys, peer topology

The gateway is the trust boundary. Internal agents trust each other (authenticated via QUIC). External agents trust only the gateway's A2A contract.

Testing Discovery Without Flaky Timing

The author mentions the gateway is tested but the six-organization incident is a deterministic simulation. This is the right approach. Testing decentralized discovery is hard because:

Timing dependencies cause flakes (agent A discovers agent B before agent C)
Network partitions are non-deterministic
Signal decay depends on wall-clock time

The solution is to separate gateway tests from mesh tests:

Gateway tests (deterministic):

Mock internal mesh state
Verify A2A request/response contracts
Test cancellation translation
Validate schema mappings

Mesh tests (simulation):

Inject deterministic signals
Advance virtual time
Verify coordination without external A2A layer

This keeps the A2A boundary testable without requiring a full mesh spin-up.

What Is Still Missing

The author notes several gaps:

Task retention: No way to retrieve a task after its internal signal expires
Interoperable progress stream: A2A progress updates exist but are not standardized across meshes
Cancellation contract: Decay injection works but has no formal cancellation guarantee
Artifact persistence: Results are ephemeral unless an agent explicitly stores them

These are not A2A problems. They are mesh-level design questions. A2A provides the introduction layer. What happens after introduction is still framework-specific.

Implementation Sketch

Here is a simplified Rust sketch of the gateway's task submission handler:

async fn handle_a2a_task(
    req: A2ATaskRequest,
    mesh: Arc<SmeshCoordinator>,
) -> Result<A2ATaskResponse, A2AError> {
    // Validate task against published capabilities
    let capability = mesh.get_capability(&req.task_name)
        .ok_or(A2AError::UnknownTask)?;

    capability.validate_inputs(&req.inputs)?;

    // Convert A2A task to internal signal
    let signal = Signal {
        task: req.task_name.clone(),
        inputs: req.inputs.clone(),
        weight: 1.0,
        timestamp: Instant::now(),
    };

    // Broadcast to mesh (non-blocking)
    let signal_id = mesh.broadcast(signal).await?;

    // Return task handle (gateway does not block)
    Ok(A2ATaskResponse {
        task_id: signal_id.to_string(),
        status: A2AStatus::Accepted,
        progress_url: format!("/a2a/tasks/{}/progress", signal_id),
    })
}

The gateway does not wait for coordination. It translates the request, broadcasts the signal, and returns a handle. Progress polling is a separate A2A endpoint that queries mesh state.

Comparison to Service Mesh Discovery

Aspect	Service Mesh (Envoy/Consul)	Agent Mesh (SMESH + A2A)
Registry	Central (etcd, Consul catalog)	Decentralized (peer broadcast)
Discovery timing	Pre-deployment registration	Runtime introduction
Capability schema	Static (Kubernetes Service spec)	Dynamic (A2A capability exchange)
Security model	mTLS + RBAC	A2A boundary + QUIC auth
State retention	Service endpoints persist	Signals decay over time
Failure mode	Registry outage breaks discovery	Mesh degrades gracefully

Service meshes assume long-lived services with stable identities. Agent meshes assume ephemeral participants with dynamic capabilities. A2A bridges the gap by providing a stable introduction protocol over an unstable mesh.

Likely Failure Modes

Gateway becomes a bottleneck: If all external requests funnel through one gateway, it becomes a SPOF. Solution: run multiple gateways with shared mesh access.

Capability drift: Internal agents add new tasks but gateway cache is stale. Solution: gateway polls mesh capabilities periodically or subscribes to capability change signals.

Signal flooding: Malicious external agent submits thousands of A2A tasks. Solution: rate-limit at gateway, require authentication, or use proof-of-work for task submission.

Cancellation race: External agent cancels task but internal signal has already produced a result. Solution: treat cancellation as best-effort, return result if available.

Schema mismatch: A2A input schema does not map cleanly to internal signal format. Solution: validate at gateway, reject incompatible requests early.

Technical Verdict

Use A2A discovery when:

You have a working agent mesh with internal coordination but no external interface
You need to interoperate with agents from other frameworks or vendors
You want a tested, standard protocol instead of inventing your own RPC layer
You can tolerate eventual consistency (signals may decay before external agent sees result)

Avoid A2A discovery when:

You need strong consistency guarantees (A2A is best-effort over a decentralized mesh)
Your agents are tightly coupled and do not need runtime introduction
You already have a working service mesh and agents are just another service type
You need sub-millisecond task dispatch (A2A adds translation overhead)

A2A solves the cold-start problem for decentralized agent meshes. It does not solve coordination, state retention, or artifact persistence. Those are mesh-level concerns. A2A is the border crossing, not the immigration policy.

Source Links

Primary article: My agent mesh could coordinate. It couldn't introduce itself. So I added A2A.

AgentCore Evaluations: How AWS Built a Framework-Agnostic Eval Layer Using OpenTelemetry as the Contract

mech.app — Thu, 27 Aug 2026 00:06:58 +0000

Amazon Bedrock AgentCore Evaluations solves a real problem: you build agents on LangGraph, your teammate uses LlamaIndex, and the platform team is experimenting with the OpenAI Agents SDK. Every framework has its own evaluation story, and none of them talk to each other.

AWS's answer is to treat OpenTelemetry telemetry as the evaluation contract. If your agent emits the right spans and attributes, AgentCore can score it without knowing which framework you used. The service works with LangGraph, LlamaIndex, OpenAI Agents SDK, Google ADK, Claude Agent SDK, and Strands Agents. It also works with custom stacks, as long as you instrument them correctly.

This is the first major cloud vendor to decouple agent evaluation from framework choice using a telemetry-based contract. Here's how the plumbing works.

The OpenTelemetry Contract

AgentCore Evaluations expects agents to emit structured telemetry in OpenTelemetry format. The service looks for specific span types and attributes:

Agent spans: Top-level execution context for a single agent invocation
Tool call spans: Individual tool invocations, including input, output, and latency
LLM spans: Model calls with prompt, response, token counts, and model ID
Retrieval spans: Vector search or knowledge base queries

Each span must include semantic attributes that map to evaluation dimensions. For example:

# Pseudo-code for manual instrumentation
from opentelemetry import trace

tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span("agent.run") as agent_span:
    agent_span.set_attribute("agent.id", "customer-support-v2")
    agent_span.set_attribute("agent.framework", "langgraph")

    with tracer.start_as_current_span("tool.call") as tool_span:
        tool_span.set_attribute("tool.name", "get_order_status")
        tool_span.set_attribute("tool.input", json.dumps({"order_id": "12345"}))
        result = get_order_status("12345")
        tool_span.set_attribute("tool.output", json.dumps(result))
        tool_span.set_attribute("tool.success", True)

The key insight is that AgentCore doesn't care about your framework's internal state machine or graph structure. It only cares about the observable events: what tools were called, what the LLM said, how long things took, and whether they succeeded.

Framework Adapters and Instrumentation Gaps

Most popular frameworks already emit some OpenTelemetry telemetry, but the coverage varies:

Framework	Native OTel Support	Instrumentation Gap	Workaround
LangGraph	Partial (LangSmith integration)	Missing tool success/failure attributes	Manual span enrichment
LlamaIndex	Good (built-in OTel exporter)	Inconsistent span naming	Span processor to normalize
OpenAI Agents SDK	Minimal	No tool spans by default	Wrap tool calls with custom tracer
Claude Agent SDK	None	Everything	Full manual instrumentation
Custom stacks	None	Everything	Build from scratch

If your framework doesn't emit the required telemetry, you have three options:

Manual instrumentation: Wrap your agent code with OpenTelemetry API calls
Auto-instrumentation: Use OpenTelemetry's auto-instrumentation libraries for HTTP, database, and LLM calls
Span processors: Intercept and enrich spans after they're created but before they're exported

AWS doesn't provide framework-specific shims. You're responsible for making sure your agent emits the right telemetry shape. The documentation includes example instrumentation for each supported framework, but you'll need to adapt it to your specific agent architecture.

Evaluation Metrics and Scoring

Once AgentCore receives telemetry, it computes metrics across several dimensions:

Task success rate: Percentage of agent runs that completed without errors
Tool accuracy: Whether the agent called the right tools in the right order
Response quality: LLM-as-judge scoring of final outputs against ground truth
Latency: P50, P95, and P99 for agent runs, tool calls, and LLM calls
Cost: Token usage and estimated inference cost per run

The service stores evaluation results in a time-series database (likely Amazon Timestream, though AWS doesn't specify). You can query results via the AgentCore API or view them in the AWS console.

Retention is 90 days by default. After that, you need to export results to S3 if you want long-term storage.

Deployment Shape and Data Flow

Here's the typical data flow:

Your agent runs in your AWS account (Lambda, ECS, EC2, or on-prem)
The OpenTelemetry SDK batches spans and exports them to the AWS Distro for OpenTelemetry (ADOT) Collector
The ADOT Collector forwards spans to AgentCore Evaluations via AWS PrivateLink
AgentCore processes spans, computes metrics, and stores results
You query results via the AgentCore API or console

The ADOT Collector runs as a sidecar container or daemon process. It handles batching, retries, and credential management. You configure it with a YAML file:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

exporters:
  awsxray:
    region: us-east-1
  agentcore:
    endpoint: agentcore.us-east-1.amazonaws.com
    region: us-east-1

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [awsxray, agentcore]

The agentcore exporter is a custom plugin that ships with ADOT. It handles authentication via IAM roles and forwards spans to the AgentCore service.

Latency and Cost Overhead

Shipping telemetry to AgentCore adds latency and cost:

Latency: 10-50ms per agent run, depending on span volume and network conditions. The ADOT Collector batches spans, so the overhead is amortized across multiple runs.
Cost: AgentCore charges per span ingested. AWS hasn't published pricing yet, but expect $0.10-$0.50 per million spans based on similar services (X-Ray, CloudWatch Logs Insights).

If you're running high-throughput agents (thousands of runs per second), the cost can add up. You can reduce it by:

Sampling telemetry (e.g., only export 10% of runs)
Filtering spans (e.g., only export tool calls and LLM calls, skip internal framework spans)
Running evals asynchronously (export telemetry to S3, process in batch)

For local development or low-stakes testing, you can run evals in-process using the AgentCore SDK. It computes metrics locally without shipping telemetry to AWS. This is faster and cheaper, but you lose the centralized dashboard and historical comparison.

Security Boundaries

AgentCore Evaluations runs in AWS's account, not yours. Your telemetry data crosses an account boundary, which raises two questions:

Data residency: Spans are stored in the AWS region you specify, but they're not in your VPC. If you have strict data residency requirements, you'll need to run your own evaluation stack.
Sensitive data: Spans can include tool inputs, LLM prompts, and user queries. If these contain PII or secrets, you need to scrub them before export. The ADOT Collector supports span processors that can redact attributes, but you have to configure them yourself.

AWS encrypts spans in transit (TLS) and at rest (KMS). You can use customer-managed KMS keys if you want full control over encryption.

Failure Modes

Here are the most likely failure modes:

Missing telemetry: If your agent doesn't emit the required spans or attributes, AgentCore can't compute metrics. The service doesn't fail gracefully. It just returns empty results.
Schema drift: If you change your agent's tool signatures or add new tools, the evaluation metrics may become inconsistent over time. You'll need to version your evaluation datasets and re-run historical evals.
Collector downtime: If the ADOT Collector crashes or loses network connectivity, spans are buffered in memory. If the buffer fills up, spans are dropped. You won't know about it unless you monitor the collector's own telemetry.
Rate limiting: AgentCore has undocumented rate limits on span ingestion. If you exceed them, spans are rejected with HTTP 429 errors. The ADOT Collector will retry, but you may lose data if the backlog grows too large.

Technical Verdict

Use AgentCore Evaluations if:

You run agents on multiple frameworks and want a single evaluation dashboard
You already use OpenTelemetry for observability and want to reuse the same telemetry pipeline
You need historical comparison and trend analysis across agent versions
You're willing to pay for a managed service and accept the latency/cost overhead

Avoid it if:

You have strict data residency requirements or can't send telemetry outside your VPC
You run high-throughput agents and need sub-10ms latency
Your framework doesn't emit OpenTelemetry telemetry and you don't want to instrument it manually
You need custom evaluation metrics that AgentCore doesn't support (e.g., domain-specific accuracy measures)

For teams running heterogeneous agent stacks, the framework-agnostic contract is a real win. But you're trading flexibility for operational complexity. You'll need to manage the ADOT Collector, monitor span ingestion, and handle instrumentation gaps yourself.

Source Links

AWS Machine Learning Blog: Evaluate any agent framework with Amazon Bedrock AgentCore Evaluations

Rate Limiting Basics: Protecting Your API from Abuse

Tech Forge — Thu, 27 Aug 2026 00:02:35 +0000

Why Rate Limiting Matters

Every public API eventually faces abuse. It could be a malicious script hammering your endpoints, a misconfigured client retrying in a loop, or just a sudden spike in traffic. Without rate limiting, your backend can get overwhelmed, leading to slow responses or crashes. Rate limiting protects your service, keeps costs predictable, and ensures fair usage among all consumers.

I remember my first production incident: a client accidentally sent thousands of requests per second to a search endpoint. The database CPU spiked to 100%, and the whole app became unresponsive for minutes. A simple rate limit would have prevented that entirely.

What Is Rate Limiting?

Rate limiting controls how many requests a client can make within a given time window. It's a policy that defines a threshold and an action when the threshold is exceeded. Common actions include rejecting the request with 429 Too Many Requests or delaying it.

The key concepts are:

Limit: Maximum requests allowed in a window (e.g., 100 requests per minute).
Window: The time period for the limit (e.g., 1 minute, 1 hour).
Identifier: Who is being limited? Usually an IP address, API key, or user ID.

Simple Fixed Window Algorithm

The simplest approach is the fixed window. You track requests per identifier in a time bucket. For example, allow 10 requests per minute. When a request comes in, you increment the counter for the current minute. If the counter exceeds 10, reject.

Here's a minimal implementation in Node.js using an in-memory map:

const rateLimit = (limit, windowMs) => {
  const requests = new Map();

  return (req, res, next) => {
    const key = req.ip;
    const now = Date.now();
    const windowStart = Math.floor(now / windowMs) * windowMs;

    if (!requests.has(key)) {
      requests.set(key, { count: 0, windowStart });
    }

    const entry = requests.get(key);

    if (entry.windowStart !== windowStart) {
      entry.count = 0;
      entry.windowStart = windowStart;
    }

    entry.count += 1;

    if (entry.count > limit) {
      return res.status(429).json({ error: 'Too many requests' });
    }

    next();
  };
};

app.use('/api', rateLimit(10, 60000));

This works for simple cases, but has a flaw: a client can burst at the end of one window and the start of the next, effectively doubling the rate. For example, 10 requests at 59 seconds, then 10 more at 61 seconds.

Sliding Window Log

A more accurate approach is the sliding window log. You store timestamps of each request and count how many fall within the last windowMs. This avoids the burst issue but uses more memory.

const slidingWindow = (limit, windowMs) => {
  const timestamps = new Map();

  return (req, res, next) => {
    const key = req.ip;
    const now = Date.now();

    if (!timestamps.has(key)) {
      timestamps.set(key, []);
    }

    const list = timestamps.get(key);
    // Remove timestamps outside the window
    while (list.length > 0 && list[0] <= now - windowMs) {
      list.shift();
    }

    if (list.length >= limit) {
      return res.status(429).json({ error: 'Too many requests' });
    }

    list.push(now);
    next();
  };
};

This is more precise but can be slow if the list grows large. For high-traffic APIs, you'd want a more efficient structure like a token bucket.

Token Bucket Algorithm

The token bucket is popular because it allows bursts while smoothing out long-term rate. Think of a bucket that holds up to capacity tokens. Each request consumes one token. Tokens are added at a fixed rate (e.g., 1 token per second). If the bucket is empty, the request is rejected.

Here's a simple implementation:

class TokenBucket {
  constructor(capacity, refillRate) {
    this.capacity = capacity;
    this.refillRate = refillRate; // tokens per second
    this.tokens = capacity;
    this.lastRefill = Date.now();
  }

  tryConsume() {
    this.refill();
    if (this.tokens >= 1) {
      this.tokens -= 1;
      return true;
    }
    return false;
  }

  refill() {
    const now = Date.now();
    const elapsed = (now - this.lastRefill) / 1000;
    this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillRate);
    this.lastRefill = now;
  }
}

// Usage per key
const buckets = new Map();

function rateLimit(req, res, next) {
  const key = req.ip;
  if (!buckets.has(key)) {
    buckets.set(key, new TokenBucket(10, 1)); // 10 burst, 1 per second
  }
  const bucket = buckets.get(key);
  if (bucket.tryConsume()) {
    next();
  } else {
    res.status(429).json({ error: 'Too many requests' });
  }
}

This allows a client to make 10 requests immediately, then 1 per second afterwards. It's a good balance between responsiveness and protection.

Real-World Considerations

In production, you rarely write your own rate limiter. Libraries like express-rate-limit for Node, or services like Redis-based limiters (e.g., rate-limiter-flexible) handle distributed scenarios. But understanding the basics helps you choose the right one.

Key points to consider:

Distributed systems: In-memory maps don't work across multiple instances. Use a shared store like Redis with atomic operations.
Identify clients properly: IP addresses can be shared (NAT, proxies). Prefer API keys or user IDs when available.
Response headers: Include X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After so clients know how to behave.
Graceful degradation: When a limit is hit, return a clear error with a Retry-After header so clients can back off.

Testing Your Rate Limiter

Always write tests. For a simple limiter, test that:

Requests within the limit pass.
Requests over the limit get 429.
The window resets correctly.

Here's a quick test using Node's built-in test runner:

const test = require('node:test');
const assert = require('node:assert');

// Assume your limiter is a function that returns middleware
const limiter = rateLimit(3, 1000);

const mockReq = (ip) => ({ ip });
const mockRes = () => {
  const res = {};
  res.status = (code) => {
    res.statusCode = code;
    return res;
  };
  res.json = (data) => { res.body = data; };
  return res;
};

test('allows up to limit requests', () => {
  const res = mockRes();
  limiter(mockReq('1.2.3.4'), res, () => {});
  limiter(mockReq('1.2.3.4'), res, () => {});
  limiter(mockReq('1.2.3.4'), res, () => {});
  assert.strictEqual(res.statusCode, undefined);
});

test('blocks over limit', () => {
  const res = mockRes();
  for (let i = 0; i < 4; i++) {
    limiter(mockReq('5.6.7.8'), res, () => {});
  }
  assert.strictEqual(res.statusCode, 429);
});

Final Thoughts

Rate limiting is a fundamental tool for any API developer. Start with a simple fixed window if you're prototyping, but for production, consider a token bucket or a battle-tested library. The most important part is being intentional: know your limits, document them, and handle the 429s gracefully on the client side as well.

Your future self, and your users, will thank you when the inevitable traffic spike doesn't take down your service.

DEV Community

Running Claude Code in 4 Parallel Sessions Led to 'Team Development' — 7 Recipes to Prevent Collisions

Real-Life Story: Averting a Deployment Rollback Disaster at the Last Minute

Recipe 1: Physically Separate Territories with Worktrees and Repositories

Recipe 2: Pre-Start Notification, Scope Declaration, and Completion Report

Recipe 3: Reserve Image Tags and Version Numbers

Recipe 4: Document the Authoritative Branch and Share It with All Sessions

Recipe 5: Make the Version Ledger (Spec Repo) the Single Source of Truth

Recipe 6: Avoid Crossing Permission Boundaries

Recipe 7: Leverage "Previous Sessions" as Knowledge Sources

Summary: Agent Parallelization Becomes an Organizational Design Problem

Building Your "Digital Twin" Health Agent: Automate Your Life with LangGraph and Oura

The Architecture: A Feedback Loop for Your Body

Prerequisites

Step 1: Defining the Agentic State

Step 2: Fetching the Bio-Data (Oura Tool)

Step 3: The Decision Logic (The "Brain")

Advanced Patterns & Production Readiness 💡

Step 4: Connecting the Calendar API

Step 5: Wiring it all together

Conclusion: Living the Automated Life

Stop rewriting your API responses in Laravel (Use this Trait instead)

Azure ExpressRoute vs VPN Gateway: the honest comparison

VPN Gateway: an encrypted tunnel over the internet

ExpressRoute: a private, dedicated circuit

How to choose

Questions people also ask

Is ExpressRoute more secure than VPN Gateway?

Can you use ExpressRoute and VPN Gateway together?

How much does ExpressRoute cost compared to a VPN Gateway?

What is the difference between ExpressRoute and a site-to-site VPN?

Which is faster, ExpressRoute or VPN Gateway?

Further reading — the Microsoft docs

MyZubster Is Not Trying to Build Another App — We're Exploring a Verifiable Digital Ecosystem

opensource #ai #iot #softwaredevelopment #sustainability #blockchain #greentech #programming #data #myzubster

Fintech Shipment Fan-Out: SaaS Retention Cleanup and the Node.js Cron-Queue Boundary

How should a Node.js SaaS choose a cron or queue for scheduled cleanup?

Why do old records need idempotency and an audit trail?

What does a queue add to Node.js cleanup cost and latency?

Which cleanup boundary protects shipment fan-out?

A cautious rollout for scheduled data cleanup

References

Latest Trends in GPU Cloud Cost Reduction and Containerized Data Centers

Introduction

Main Content

Benefits of Containerized Data Centers

Efforts to Reduce GPU Power Consumption

Key Trends in Japan

Conclusion

reimagine-it v2.4.2 — One command, 15 design tokens, 80% source-fidelity floor

What it is

What's new in v2.4.2

1. Source fidelity floor raised to 80% across every token

2. Links and emails surface on every token

3. All 15 design tokens in the browser extension

4. Docs can't drift anymore

The 15 design tokens

Measured, not vibes

Try it — no install

RFLCT: Bringing Runtime Type Metadata to TypeScript 7

What is RFLCT?

The Magic: Before and After

What you write:

What RFLCT compiles it to:

Broader Than Just InversifyJS

How It Works: The Three Transformations

1. design:symbols — The Global Type Registry

2. design:arguments — Parameter Type Metadata

3. resolve<T>() — Compile-Time Type Resolution

Smart Symbol Qualification

Getting Started (Alpha Preview)

1. Build from Source

2. Project Setup

3. Configure Your Build Tool

Looking Forward & Next Steps

Agent-to-Agent Discovery in SMESH: Why Coordination Isn't Enough Without Runtime Introductions

The Cold-Start Problem in Agent Meshes

What A2A Provides

SMESH Architecture Before A2A

Adding the A2A Gateway

1. `design:symbols` — The Global Type Registry

2. `design:arguments` — Parameter Type Metadata

3. `resolve<T>()` — Compile-Time Type Resolution