Laxmikant Sharma

Agents Are Speedrunning the History of RPC

Sun, 09 Aug 2026 00:00:00 GMT

Part 4 of the agentic-web series. Part 1, Part 2, and Part 3 came before.

When an agent's tool call fails, nothing in the current protocol stack can tell you whether it executed, and nothing lets the retry say "I'm the same request, don't run me twice." MCP made this worse on 28 July, when it went stateless and dropped its recovery machinery. A2A opened a public epic admitting the same hole five weeks earlier. Both teams are now rediscovering, issue by issue, machinery that RPC systems shipped in 1984 and fintech reinvented as the idempotency key a decade ago.

If your tools move money, merge branches, or send messages, this is a layer you own today without having agreed to. At the end are the three changes I think both specs should make. Everything before that is why.

Say your tool charges a card. Under MCP 2026-07-28 the call goes out looking like this:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: charge_card
Accept: application/json, text/event-stream
Content-Type: application/json

{"jsonrpc":"2.0","id":7,"method":"tools/call",
 "params":{"name":"charge_card",
   "arguments":{"amount":4000,"currency":"usd"},
   "_meta":{
     "io.modelcontextprotocol/protocolVersion":"2026-07-28",
     "io.modelcontextprotocol/clientCapabilities":{}}}}

The stream dies before anything comes back. You're now holding a request you can't classify. Either it never landed, or it landed and the card is charged and the reply evaporated, or it's still running on a box that hasn't noticed you left.

Look at the frame for anything that would let the server spot a second attempt. id: 7 won't do it:

The request ID MUST NOT match the ID of any other request the sender has issued and not yet received a response for.

Unique among in-flight requests, and that's all. It's a demux handle for concurrent calls on a connection, which is what JSON-RPC always meant by it, and it carries no identity across attempts. Nothing else in the envelope helps either: the reserved _meta keys are progressToken, the io.modelcontextprotocol/ set, and the three OpenTelemetry trace-propagation keys. No idempotency key, no dedup token, nowhere to put one that means anything.

Somebody wrote this exact problem up in 1994:

The only way to fix this is to change the protocol to add request IDs. But since this is a standardized interface, there is no way to do this.

Jim Waldo, Geoff Wyant, Ann Wollrath and Sam Kendall, A Note on Distributed Computing, about a queue interface they made up for the argument. The system they actually autopsy later in that paper is NFS.

What 28 July changed

The stateless core got all the coverage and deserved it. Dropping initialize and Mcp-Session-Id means any request lands on any instance behind an L4 round robin, and you stop running sticky sessions just to keep a tool server alive. Real win. I'd take it.

Item nine of the major changes is the one nobody quoted:

Remove SSE stream resumability and message redelivery (the Last-Event-ID header and SSE event IDs) from the Streamable HTTP transport. A broken response stream loses the in-flight request; clients MUST re-issue it as a new request with a new request ID.

Before this revision a dropped stream could be resumed, if the server implemented it: reconnect with Last-Event-ID, the server could replay from that cursor, final response included. Every step was a MAY, but the recovery path existed. Now the retry is mandated and the correlation is deliberately destroyed, in the same sentence. Mutating tools/call is at-least-once with no dedup anywhere in the stack, and it fails quietly. You don't get a duplicate error. You get a second charge.

SEP-2575 is straight about the trade, under a heading called Resumable Streams Are Removed:

Because connection drops now implicitly cancel a request, resumable SSE streams (via Last-Event-ID reconnection) are removed. They contradict the stateless-by-default paradigm: resuming would require the server to retain per-request state across connection failures.

Workloads that need durability or resumability MUST use the tasks primitive instead, which provides explicit mechanisms for fetching results after a connection drop.

That first clause is doing more work than it looks like. Closing the response stream is now defined as cancellation. Clean at the transport, since each request owns its stream. Fiction at the application, where your handler is four frames deep in somebody's payment SDK and will finish what it started regardless. gRPC hit this years ago and says so out loud: the library "does not have a mechanism to interrupt the application-provided server handler," so a long-running handler has to poll for its own cancellation. Nobody's tool handler polls for anything.

And durability-via-tasks inherits the same hole at its own front door, because tasks mint their IDs server side. Hold a task ID and you can poll tasks/get forever. Lose the response that carried it and you have no way to learn the task exists. The same release removed tasks/list, reasonably, on the grounds that it can't be scoped safely without sessions. It was also the one workaround. A client that loses a task ID now has no path back to it.

The idempotency gap itself came up while tasks were being designed and was deliberately deferred to a proposal of its own. That proposal went up last week. More on it at the end.

A2A, same wall, opposite direction

Eight epics landed against A2A on 25 June under v1.1-candidate. #1987 is [Epic] Idempotency & safe retries. Zero comments on it as of today.

If a client crashes (or the connection drops) after sending the first message but before it receives and persists the server-generated taskId/contextId, it has no way to learn whether a task was started on its behalf

The proximate cause is one line in section 3.4.2:

Client-provided taskId values for creating new tasks is NOT supported.

The identifier that names the work gets minted on the far side, one round trip after you needed it. There was a real reason: a client-chosen ID could become a handle into another client's task, and #1987's acceptance criteria say the retry key they add back must not reopen that. But the fix took the retry story out with it, which is why this epic is harder than it looks and why it has no comments.

A2A does have a client-minted identifier, message_id, required on every message. It even has a section headed Idempotency, and the modal verbs are the entire story:

Send Message operations MAY be idempotent. Agents may utilize the messageId to detect duplicate messages.

MAY and may. The raw material is on the wire and the obligation isn't, so you can't know whether a given agent implemented dedup and can't write a retry policy that leans on it. Push notifications are more upfront about where that leaves you: "Clients SHOULD process notifications idempotently, as duplicate deliveries may occur."

Epic #1986 covers the streaming half: "no per-task event ordering, no cursor to resume from, no defined replay behavior on tasks/resubscribe." And resubscribe keys on taskId rather than on a stream, so with two streams live against one task you get both streams' events fired at you.

Two protocols, two teams, five weeks apart, same wall.

The prior art

Exactly-once delivery isn't implementable. Over a lossy channel no finite protocol gets two parties to agree a message arrived, because the agreement needs an ack, and the ack needs an ack. Akkoyunlu, Ekanadham and Huber proved it at SOSP in 1975, where the parable is two gangs of gangsters coordinating a job rather than generals on hilltops. Jim Gray gave it the name that stuck three years later.

Fifty years old.

Exactly-once effect is implementable, and the recipe hasn't changed. Accept at-least-once delivery, have the caller mint a key, have the receiver keep a table of executed keys and replay the stored result on a repeat. Three conditions decide whether it actually holds:

The dedup record and the side effect commit together. Writing the key to Redis and then charging the card is the same race with more moving parts. If the effect is a third-party call, you need an outbox or that provider's own idempotency key.
The retention window is finite and published. The contract has to say how long a retry is honoured and what a late duplicate gets.
The caller's key namespace survives restart. A client that reboots and restarts its counter gets live requests eaten as duplicates, which is a miserable bug to chase.

Birrell and Nelson shipped most of that in 1984, in Implementing Remote Procedure Calls. A call identifier made of machine, process, and a monotonic sequence number; a server table keeping the highest number seen per caller and discarding anything at or below it; state discarded once retransmission stops being plausible, which they put at roughly five minutes; and a conversation identifier so a rebooted caller can't collide with the corpse of its old self. That's a modern idempotency-key implementation, including the restart case most of them still get wrong. The piece they don't solve is the atomic commit, which is the one that keeps biting people forty-two years later.

They also never wrote "exactly once" or "at most once." Their guarantee: if the call returns, the procedure ran precisely once, and if you get an exception it ran "either once or not at all" with the caller not told which. They named the ambiguity window instead of pretending they'd closed it, which is more than most retry documentation manages today.

ONC RPC, still the specification behind NFS, put it in Standards Track language. RFC 5531, unchanged from RFC 1831 in 1995:

A server may wish to remember previously granted requests from a client and not regrant them, in order to insure some degree of execute-at-most-once semantics. [...] The server is not allowed to examine this ID in any other way except as a test for equality.

The XID is an idempotency key and that last clause is the opaque-key rule, still violated by everyone who parses structure out of a request ID because it looked like it had a timestamp in it.

DCE RPC did the thing I keep wishing somebody would copy. Call semantics were an operation attribute in the IDL: idempotent, broadcast, maybe, with at-most-once as the default when you declared nothing. The interface stated the retry contract and the runtime enforced it. You couldn't ship a mutating call that a stub would cheerfully replay, because the safe behaviour was what you got by saying nothing.

MCP is closer to this than I gave it credit for, and the distance is the interesting part. ToolAnnotations has carried an idempotentHint all along. But the schema says annotations are hints, not guaranteed to describe behaviour faithfully, and tells clients not to trust them from unknown servers. So it's an assertion by the one party with an incentive to make it, verified by nobody, and it says nothing about what the server should do when the same call shows up twice. DCE's idempotent was enforced. MCP's is a comment.

gRPC declined on purpose

From PROTOCOL-HTTP2.md:

Unless explicitly defined to be, gRPC Calls are not assumed to be idempotent. Specifically:

Calls that cannot be proven to have started will not be retried.

There is no mechanism for duplicate suppression as it is not necessary.

Calls that are marked as idempotent may be sent multiple times.

End-to-end argument, applied correctly. Duplicate suppression needs application semantics the transport doesn't have, so the transport shouldn't pretend. Even gRPC's hedging, which fires the same call at several backends on purpose, fits: it's only meant to be enabled for methods already safe to run twice.

The catch is that "the application" meant one team's code in one repo. When the caller is a model picking tools at runtime and the callee is another company's agent behind an agent card, there's no shared application to push the problem down into. The end-to-end argument tells you where the mechanism belongs. In this topology that place has no owner.

The standardisation attempt tells you the rest. draft-ietf-httpapi-idempotency-key-header got to -07 in October 2025 and expired on 18 April 2026 without becoming an RFC. Its own implementation status section lists nine organisations shipping that exact header, Stripe and Adyen and WorldPay among them, then ten more shipping the same idea under names they picked themselves: PayPal-Request-Id, I-Twilio-Idempotency-Token, BBVA's X-Unique-Transaction-ID. Square and Google Standard Payments put it in the body instead.

Nineteen independent implementations of one mechanism. Six years of drafts. No RFC.

Deadlines, same story

grep -inE 'deadline|expire|expiry|ttl' specification/a2a.proto gives you nothing. Issue #857 has been asking since 10 July 2025:

A deadline is an absolute timestamp by which the server must complete the task or stream of tasks.

It's assigned. It's not on the v1.1 candidate list.

A gRPC call to an A2A agent can carry an RPC deadline, because every gRPC call can; that's the transport's doing, and A2A's spec never mentions deadlines at all. What doesn't exist anywhere is a task deadline: one that outlives a single RPC, survives push delivery and resubscribe, and means something in the JSON-RPC and HTTP+JSON bindings, which are co-equal in v1.0.

The mechanics people usually get backwards: some gRPC language APIs take an absolute deadline, others a relative timeout, but what goes on the wire is only ever grpc-timeout, a relative value, 1500m or 30S. Relative on purpose, because an absolute timestamp is only as trustworthy as the clock agreement between two machines and there is no clock agreement. One budget set at the root, each hop forwarding what's left after its own elapsed time.

The SRE book has the counterexample. A gives B ten seconds. B takes eight to start, then calls C with a hardcoded twenty instead of the two it actually has. C dequeues five seconds later and gets to work believing it has fifteen in hand. A gave up three seconds before C even started.

Stack that five agents deep with nobody propagating and the chain has no bounded completion time at all. The depth makes it worse: the agent burning the most speculative compute is the one furthest from anyone who could tell it to stop.

Nelson had a word for this in 1981. An orphan is a remote call whose ancestor is running on a crashed node. Every agent framework that fans out sub-agents and then loses the parent is manufacturing orphans in exactly his sense. His remedy, exterminating them after a crash, assumed a runtime that could see the call tree. No agent runtime sees the call tree once it crosses an org boundary.

The part that actually is harder

One piece of this is genuinely new, and it's worth being precise about which piece.

Sagas are the answer to a half-completed workflow. Garcia-Molina and Salem, 1987. Split the long transaction, give the sub-transactions compensating transactions, unwind backwards when something fails. It works, and people have built a lot on it.

Then you read the assumptions. The paper scopes itself to "a centralized database system." It merges the saga log and the transaction log into one. It allows saga code outside the database's control on the basis that sagas are written by trusted application programmers. And when a compensation itself fails, its remedies are an alternate implementation or a human, the second described, honestly, as "definitely not an elegant solution, but it is a practical one."

One database, one log, one coordinator, everybody trusted. Agent-to-agent delegation violates all four.

Step three of your workflow ran inside another company's agent and it billed you. There's no rollback here. You can't execute a compensating transaction in their system, they're under no obligation to run one for you, and if they say they did you can't check. That's a claim, not a compensation, and no agent protocol has a message type for it.

There's a footnote in the paper that reads differently now than it can have in 1987: forward recovery works only if every sub-transaction eventually succeeds given enough retries. Inside one company, a resourcing assumption. Across a trust boundary, false, because the counterparty is allowed to say no and keep saying it.

And the limit case hasn't moved: "if a transaction fires a missile, it may not be possible to undo this action."

What I think the specs should do

Both protocols are moving. A2A has eight epics open and a TSC decision pending between two proposals that directly contradict each other on multi-turn state. SEP-3182 went up against MCP on 1 August, no sponsor, no reviewers, no labels. Its motivation runs long but it reaches the right sentence fast:

A tools/call that mutates state (charges a payment, merges a branch, sends a notification) carries no field that would let the server recognize a retry and return the original outcome instead of executing the side effect again.

If it were mine to fix, three changes. None of them invents anything; all three adopt designs with decades of production behind them, and none needs a new protocol or a working group. Three PRs and the willingness to write MUST.

One: a client-minted execution key on every mutating call. In MCP, a declared field on tools/call params, not _meta. Opaque, compared by equality only, the RFC 1831 rule. Within a published retention window, a repeated key returns the stored result and MUST NOT re-execute. SEP-3182 is the right vehicle and deserves a sponsor. In A2A, the same key on message/send closes #1987 without reopening the security hole that killed client-set task IDs, because the key is scoped to the authenticated caller: the task ID stays server-minted and names the work, the key is per-principal and names the attempt. That split is the entire design, and it's been sitting in Birrell and Nelson's activity table since 1984.

Two: make the retry contract declarative and enforceable. idempotentHint should grow up into a declared semantic: at-most-once, idempotent, or unsafe, safe default when nothing is declared, tested by the conformance suite MCP already gates spec features on. A hint nobody can trust protects nobody. A declared contract with a test behind it changes what clients can safely automate.

Three: a relative time budget, decremented hop by hop. budgetMs on the call, gRPC's design lifted whole: relative on the wire so clock skew can't corrupt it, every hop forwarding the remainder, any hop receiving a spent budget failing fast. That's the task deadline #857 has wanted for a year, and it gives a five-hop delegation chain a bounded completion time, which today it does not have.

One thing I wouldn't do: put exactly-once in the transport. gRPC's refusal was correct, and Two Generals says the transport can't deliver it anyway. The protocol's job is to carry the key, the contract, and the budget. Effect semantics belong to the endpoint that owns the side effect. That line has held since 1975 and nothing about agents moves it.

While you wait

Until something like that lands, you own this layer in application code:

Mint your own key and put it in tool arguments, not _meta. Declare it in your inputSchema so the model carries it across retries. SEP-3182 argues several popular frameworks strip _meta, and a guarantee riding on a field that might not survive the trip isn't one.

Commit the key and the effect in one transaction. Or an outbox, or the downstream provider's own idempotency key. Two separate network calls just relocate the race.

Publish the retention window. Pick twenty-four hours, enforce it, decide what a late duplicate gets back.

Set one deadline at the root and decrement it. A hop that receives a spent budget should fail immediately rather than start work nobody wants.

Assume every mutating tool call arrives twice. Write the handler that way and the transport stops being your problem.

Everyone building agents is carrying this separately and incompatibly right now, which is roughly where HTTP APIs sat on idempotency keys a decade ago, and where RPC sat in 1984.

Waldo and his co-authors called the loop. Their section heading was Déjà Vu All Over Again:

Every ten years (approximately), members of the language camp notice that the number of distributed applications is relatively small. They look at the programming interfaces and decide that the problem is that the programming model is not close enough to whatever programming model is currently in vogue (messages in the 1970s, procedure calls in the 1980s, and objects in the 1990s). A furious bout of language and protocol design takes place and a new distributed computing paradigm is announced that is compliant with the latest programming model. After several years, the percentage of distributed applications is discovered not to have increased significantly, and the cycle begins anew.

Tools in the 2020s. New paradigm, same partial failure.

Earlier parts of this series covered protocol discovery, agent identity and delegation, and the contract layer between work and payment, the last of which became draft-laxsharma-pact at the IETF.

This site is home now

Sat, 08 Aug 2026 00:00:00 GMT

I have been writing in other people's houses for a while: Medium, LinkedIn, and a few conference PDFs scattered around the internet. Those places are good at distribution and bad at permanence. Feeds change, formats change, and none of it is really mine.

This domain fixes that. Everything I publish lands here first: articles, short notes, papers, talks, and eventually videos. The platform copies become pointers back to this address.

The site is plain by design. Text, a feed you can subscribe to, and URLs that will not break. If you want to follow along, RSS is the reliable way.

When Agents Hire Agents: PACT, the Missing Layer 4 of the Agentic Web

Tue, 28 Jul 2026 00:00:00 GMT

Part 3 of the agentic-web series. Part 1 and Part 2 mapped what already exists. This one proposes something new. Part 4 continues with the retry nobody owns.

Picture a thousand agents assembling around a single job. A sealed-bid auction resolves in one round-trip. A tree of subcontracts forms underneath it. Work streams through payment channels with payouts landing as it arrives, one fraud proof slashes a subcontractor that cut corners, and every participant's reputation updates the moment escrow closes. Paid in seconds. Final in an hour, once the last challenge window closes clean. Humans involved: zero. Every hop provable, forever.

Nothing in today's stack can run that scene. I spent two posts mapping the protocols and the trust machinery underneath them, and when I lined it all up, one hole stood out.

The stack has an OSI problem

Transport ships. Messaging ships, in the form of MCP tools and A2A tasks. Trust ships too: signed cards, DIDs, act-chains, mandates. But watch what happens when an agent actually tries to hire another agent. A2A moves tasks, except they carry no price. x402 moves money, but unconditionally. AP2 authorizes payments without ever verifying the work. Nowhere in the 2026 stack is there an object that binds work to money to proof. Agent-to-agent commerce today is pay a stranger and hope.

There is even a 45-year-old blueprint for the missing piece. R.G. Smith's Contract Net Protocol (1980) described almost exactly this: task announcement, bidding, awarding. It got built, too, but only inside closed and mutually trusting systems. FIPA standardized it in 2002 and factories ran it on JADE. What never existed was the substrate for running it among strangers, meaning identity, money, and verification between parties with no reason to trust each other. That substrate exists now. PACT is Contract Net with teeth.

PACT: Propose, Agree, Complete, Trust

Propose. The buyer broadcasts a call-for-bids carrying the task spec, a deadline, a maximum price, and the verification tier the work will be judged by. Sellers answer with sealed bids plus a staked bond. The award goes to the best bid at the second-best price, which is to say a Vickrey auction.

But what does the broadcast actually say? The spec inside it is a layered TaskSpec, and each layer has a different reader:

{
  "description": "Dedupe 2.1M customer rows",
  "skill": "data-cleaning/dedupe",
  "inputs": {
    "sample_uri": "…/sample-10k.csv",
    "size_hint": { "rows": 2100000 }
  },
  "deliverable": { "format": "csv" },
  "acceptance": {
    "tier": "T0-reexec",
    "harness_uri": "…/acceptance-tests.tar",
    "thresholds": { "dup_rate_max": 0.001 }
  },
  "constraints": {
    "tools_prohibited": ["external-APIs"]
  }
}

The seller's LLM reads description to understand the job. The schemas and the sample let it price the effort, and the acceptance harness lets it price the risk, since what it is really estimating is its probability of passing against a bond it could lose. Which surfaces PACT's quiet precedence rule: where prose and tests disagree, the acceptance instrument governs. Settlement is gated on verification, so the only economically real definition of "done" is the one the verifier applies. Prose is intent. The harness is the contract. (Confidential work? Publish the call-for-bids with the spec behind an authenticated fetch. The hash commitment stops any bait-and-switch.)

Why an auction rather than letting the agents haggle? Because negotiation between LLMs is an attack surface. Persuasion exploits, prompt-injecting your counterparty, strategic hallucination, none of it patchable with guardrails. Under a sealed-bid second-price award, truthful bidding is the dominant strategy, so game theory removes the incentive to manipulate instead of asking you to detect manipulation afterwards. Two details matter for safety. Bids are cryptographic commitments, so the buyer can't peek, and can't quietly insert a fake price-setting second bid either. And awards cover one task per auction, because Yokoo's classic result says single-item second-price survives fake-identity bidding while bundle auctions don't.

Agree. Both parties co-sign a Verifiable Task Contract: one typed JSON object, canonicalized (RFC 8785), signed (JWS), binding everything the stack currently leaves loose.

{
  "pact": "0.1",
  "type": "VerifiableTaskContract",
  "id": "vtc_9f2c",
  "parties": {
    "buyer":  "did:web:acme.ai:buyer-7",
    "seller": "did:web:dataforge.io:etl-3"
  },
  "task": {
    "spec_hash": "sha256:4be1…",
    "deadline": "2026-08-01T00:00:00Z"
  },
  "price": {
    "amount": "180.00",
    "currency": "USDC",
    "settlement": "pact-escrow",
    "channel": "ch_88a1"
  },
  "verification": {
    "tier": "T1-tee",
    "criteria_hash": "sha256:77d0…",
    "arbiter": "did:web:arbiter.example"
  },
  "liability": {
    "seller_bond": "18.00",
    "parent": "vtc_31aa"
  },
  "challenge": { "window_seconds": 3600 },
  "signatures": [
    { "kid": "buyer#k1",  "sig": "MEQCIA…" },
    { "kid": "seller#k1", "sig": "MEUCIQ…" }
  ]
}

A note on those hashes, because they are doing quiet work. spec_hash is a commitment, not a pointer. The full spec travels with the call-for-bids, either inline or at a spec_uri, and every party verifies it against the hash before signing and keeps the preimage through the dispute window. So in any later argument, presenting content that matches the co-signed hash proves exactly what was agreed. RFC 6920, "naming things with hashes," gives the format.

The price locks in escrow through a proposed pact-escrow x402 payment scheme, and the word choice there is deliberate. In x402 v2's taxonomy, anything that changes settlement semantics is a scheme, alongside exact and upto, while "extensions" are non-payment add-ons. The landing zone is well prepared. Cloudflare has proposed a deferred scheme with an escrow deposit up front, off-chain vouchers per request, and batch redemption, and there is an open PR in the x402 repo for a usage-based escrow scheme. What none of them provide is release gated on verified work, with bonds and challenge windows. That last step is what pact-escrow adds. Meanwhile the buyer's authority arrives as an act-chain token from Part 2. Keep an eye on that parent field, it matters shortly.

Complete. Work streams in hash-committed checkpoints, and payment releases optimistically, which is the rollup pattern applied to labor. The seller gets paid at delivery. A challenge window follows, during which anyone can submit a fraud proof that reverts the payment and slashes the bond. A valid challenger is then paid out of that slashed bond: costs reimbursed plus a capped bounty, with the remainder going to a neutral sink. That clause isn't generosity, it's game theory. The rollup literature proved that unpaid watchmen stop watching, which is the verifier's dilemma, and deployed systems like Arbitrum's BoLD pay defenders a capped bounty for exactly this reason. Verification cost moves off the critical path, the same trick optimistic rollups pulled for Ethereum. What counts as a valid fraud proof depends on the tier the contract named up front:

I want to stress that this ladder is not speculative, but let me give you the honest numbers rather than the marketing ones. Lagrange's DeepProve proves full GPT-2 inference at roughly 174 tokens per minute with about 1.2-second verification. Polyhedra's zkPyTorch has pushed the ceiling to Llama-3 8B at around 150 seconds per token, which is provable but not yet economical, and NANOZK-style layerwise proofs (43 s proving, 23 ms verification at GPT-2 scale) point at how T2 eventually gets practical. Meanwhile TEE-attested inference is the production tier today: NVIDIA's confidential-computing mode costs 2 to 8% throughput with a one-time attestation of a second or three, and the attestation itself now has a stable IETF format in EAT, RFC 9711. Re-execution covers code and data work, TEE covers provenance, zkML covers high stakes, and staked juries handle the subjective residue.

Trust. Escrow settles and both parties receive a co-signed Work Attestation. Here is the part I find genuinely satisfying: reputation becomes the exhaust of settlement. Every rating system ever built eventually drowns in Sybils and fake reviews. An attestation that exists only because escrowed money moved through a bonded contract is a different animal, because fabricating a work history means actually funding it, contract by contract, fee by fee. Collusion doesn't come free either, since wash-trading your own reputation costs facilitator fees and locked bonds on every fake job. The agent credit bureau builds itself. And selective-disclosure proofs (SD-JWT, BBS) let an agent show "1,000+ settled contracts, under 1% disputes" without naming a single client.

Machine speed and recursion

Two more borrowed patterns make the economics work at agent tempo. Contract channels are Lightning, for work: open one master escrow, stream thousands of micro-contracts off-ledger, net-settle on close. Contract formation drops to effectively zero cost, so hiring can happen inside an inference loop. Channels also inherit Lightning's hardest operational lesson, which is that someone must be watching during the challenge window or an offline party can be defrauded with a stale state. So monitoring is delegable to watchtowers, exactly as Lightning's BOLT 13 draft does it. Sellers can also start work before contract finality, speculative execution with rollback priced into the bond.

Now the parent field. A contract can spawn child contracts, so a prime contractor decomposes a job into a tree. Bonds sit at every node. A failed leaf slashes upward until the buyer's remedy is covered. And the root attestation carries a Merkle commitment over every child attestation, so a single signature proves an entire delegation hierarchy. Authority flows down the act-chain and accountability flows back up it. Insurers get a per-node price surface to underwrite, which is a liability market for machine labor, born the day someone quotes the first premium.

One more thing, because markets of millisecond actors fail like flash crashes rather than recessions. The protocol carries its own circuit breakers: velocity caps per identity, position limits, and CAEP-triggered market-wide halts. The SEC of the machine economy will be a policy engine subscribed to a signal feed.

Nothing here is invented, and that's the point

Every element maps onto something already shipping. Discovery via /.well-known/pact.json (RFC 8615, sitting right next to the server and agent cards from Part 1). DIDs and signed cards for identity. Act-chain token exchange for authority (RFC 8693). JWS and JCS for signing. x402 plus AP2 mandates for settlement, AuthZEN for approvals, CAEP for revocation, Kleros-style juries and TEE or zkML for proof. PACT contributes exactly one missing object, the contract, and composes everything else.

A seller advertises what it can do at /.well-known/pact.json:

{
  "pactVersion": "0.1",
  "roles": ["seller"],
  "verification_tiers": [
    "T0-reexec", "T1-tee"
  ],
  "settlement": ["pact-escrow"],
  "channels": true,
  "min_bond_pct": 10,
  "attestation_jwks": "…/jwks.json"
}

One distinction worth being precise about: this card is static discovery, telling you who I am and which roles, tiers, and rails I support. The call-for-bids and the sealed bids are different animals entirely, being dynamic, per-auction, signed protocol messages with their own media types in the draft. The card tells you whom to invite. The messages run the auction.

PACT has neighbors, and that's good news

While writing this I went looking for parallel efforts and found the layer already stirring. VCAP (draft-stone-vcap) does marketplace-mediated escrow with verify-then-release settlement. AGTP builds an agent transport with runtime negotiation. An early Agentic Dispute Protocol exists, ATEP proposes a portable "agent passport" for track records, and ERC-8004 put on-chain agent identity and reputation registries on Ethereum mainnet in January. Even DeepMind's Virtual Agent Economies paper from September 2025 calls for auction-based allocation and verifiable reputation as the design agenda for agent markets, though at the economics level and without a wire protocol. The neighborhood has kept growing since: Virtuals' on-chain Agent Commerce Protocol pairs escrow with evaluator agents, ERC-8183 standardizes client, provider, and evaluator transactions on Ethereum, the RAILS paper develops verification-native clearing with graded verifier classes, and Stripe's Machine Payments Protocol from March 2026 gives x402 a second major rail, which is exactly why PACT's settlement bindings are deliberately rail-agnostic. I read all of this as confirmation the gap is real. Multiple people are digging at it from different sides.

Where PACT stakes out its own ground: no marketplace in the middle, auctions instead of negotiation, pay-then-challenge instead of verify-then-release, bonded liability that survives subcontracting, and reputation derived from settlement rather than declared. Attestations can then be exported into an ATEP-style passport or anchored in an ERC-8004 registry, and the escrow profile picks up where x402's deferred scheme leaves off. Composition, not competition. The draft cites and differentiates each of these, and if their authors are reading, I'd like to compare notes.

The draft, and three predictions

I've written the full strawman up properly, and as of this week it isn't just written, it's submitted. draft-laxsharma-pact-00, "PACT: A Contract Layer for Autonomous Agent Commerce" is live on the IETF Datatracker, with the spec, JSON Schemas, and hash-verified examples at github.com/pact-spec/spec. If you work on A2A, x402, AP2, or agent infrastructure and this collides with problems on your desk, I want to hear where it's wrong. That isn't politeness. A -00 draft is a request for demolition.

Three falsifiable predictions, so you can hold me to something. By mid-2027: an escrow or conditional-settlement extension ships in the x402 ecosystem; some standards venue, whether an IETF side meeting, a W3C community group, or a Linux Foundation working group, charters agent work-contracts as an actual item; and someone announces the first insurance product for autonomous-agent liability. If all three miss, the thesis was wrong, and I'll write that post too.

The last two years wired the agentic web and made it trustworthy. Whether it becomes an economy gets decided next, and economies don't run on tasks and tokens. They run on contracts.

References

Smith, R.G., "The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver," IEEE Trans. Computers (1980)
A2A v1.0 · AP2 · x402 + v2 extensions · MCP
RFC 8615 · RFC 8693 · RFC 7515 · RFC 8785
zkML and TEE: DeepProve (eprint 2026/1112) · zkPyTorch / Llama-3 8B · NANOZK (arXiv 2603.18046) · optimistic TEE-rollups (arXiv 2512.20176) · RATS RFC 9334 · EAT RFC 9711
Fraud-proof economics: Luu et al. (CCS 2015) · TrueBit (arXiv 1908.04756) · rollup validator incentives (arXiv 2308.02880) · Arbitrum BoLD (arXiv 2404.10491)
x402 security analysis (arXiv 2605.30998) · financial risk management for AI agents (arXiv 2604.03976)
Parallel drafts: VCAP (draft-stone-vcap) · AGTP (draft-hood-independent-agtp) · Agentic Dispute Protocol · ATEP (draft-stone-atep) · TessPay (arXiv 2602.00213)
Agent economies and registries: Virtual Agent Economies (arXiv 2509.10147) · ERC-8004 "Trustless Agents" (Ethereum mainnet, Jan 2026) · x402 v2 spec + schemes
Mechanism design: Vickrey, "Counterspeculation, Auctions, and Competitive Sealed Tenders," J. Finance (1961) · Ausubel & Milgrom, "The Lovely but Lonely Vickrey Auction" · Yokoo on false-name bids · Kleros · SD-JWT, RFC 9901
Agent-economy neighbors: Virtuals ACP · RAILS (arXiv 2606.08790) · Stripe MPP · x402 escrow-scheme PR #873

The Agentic Web Is Being Wired Right Now: A Field Guide to MCP, A2A, Skills, and Agent Payments

Thu, 23 Jul 2026 00:00:00 GMT

Part 1 of the agentic-web series. Continue with Part 2, Part 3, and Part 4.

An AI agent that can only chat is a demo. An agent that can do things needs plumbing: a way to reach tools, talk to other agents, carry know-how, and pay. Two years ago that plumbing didn't exist as a standard. Today it's a stack of open protocols — moving weekly, and increasingly the layer your architecture decisions depend on.

How we got here in 24 months

Anthropic open-sourced MCP (November 2024) for tools; Google answered with A2A (April 2025) for agent-to-agent work; payments arrived through 2025 (Coinbase's x402, Google's AP2, OpenAI + Stripe's checkout standard); Anthropic shipped Agent Skills with Claude in October 2025 and published SKILL.md as an open, cross-platform standard that December. The discovery layer evolved in parallel and is still moving: MCP's SEP-1649 ratified a card at /.well-known/mcp.json, its successor SEP-2127 is converging on /.well-known/mcp/server-card.json, and A2A's card moved from agent.json to agent-card.json before gaining signatures in v1.0. Along the way, most of it — MCP, A2A (absorbing IBM's ACP), AGNTCY, the x402 Foundation — moved under the Linux Foundation: the clearest signal this is shared infrastructure, not any vendor's moat.

Problem 1 — Reaching tools and data: MCP

MCP is "the USB-C for AI": write an integration once, and any MCP-aware client (Claude, Cursor, VS Code…) can use it. The architecturally interesting part is discovery — how a client vets a server before connecting, via a self-describing card:

// GET https://api.example.com/.well-known/mcp/server-card.json
{
  "protocolVersion": "2025-06-18",
  "serverInfo": { "name": "example-crm", "title": "Example CRM",
                  "version": "1.4.0" },
  "transport": { "type": "streamable-http", "endpoint": "/mcp" },
  "capabilities": { "tools": { "listChanged": true }, "resources": {} },
  "tools": [{
    "name": "search_contacts",
    "description": "Search CRM contacts by name, company, or email",
    "inputSchema": {
      "type": "object",
      "properties": { "query": { "type": "string" },
                      "limit": { "type": "integer", "default": 10 } },
      "required": ["query"]
    }
  }],
  "authentication": { "type": "oauth2" }
}

The card can embed the server's actual tool definitions — names, descriptions, JSON-Schema inputs — which is what makes pre-connect vetting real: registries can index tools, and security scanners can statically classify tool descriptions (prompt-injection screening included) before any client connects. Note the churn: SEP-1649 ratified /.well-known/mcp.json; its successor SEP-2127 (an active draft) moved to /.well-known/mcp/server-card.json. An official MCP Registry (preview since September 2025) indexes servers at scale.

Problem 2 — Talking to other agents: A2A

When agents delegate to each other across vendors, A2A is the wire. Its core artifact is the Agent Card at /.well-known/agent-card.json — a JSON "business card" doing three jobs at once: identity, résumé, and API contract.

// GET https://acme.ai/.well-known/agent-card.json
{
  "protocolVersion": "1.0",
  "name": "Acme Travel Agent",
  "description": "Books flights and hotels",
  "url": "https://acme.ai/a2a",
  "preferredTransport": "JSONRPC",
  "capabilities": { "streaming": true },
  "securitySchemes": { "oauth2": { "type": "oauth2" } },
  "skills": [{
    "id": "book-flight",
    "name": "Book a flight",
    "description": "Finds and books flights within constraints",
    "tags": ["travel", "booking"],
    "examples": ["Book SFO→NYC next Friday under $500"],
    "inputModes": ["text"], "outputModes": ["text"]
  }],
  "supportsAuthenticatedExtendedCard": true,
  "signatures": [{ "protected": "eyJhbGciOi...", "signature": "MEUCIQ..." }]
}

The AgentSkill objects are what registries index and LLM routers rank; supportsAuthenticatedExtendedCard splits the public shingle from a richer private catalog revealed after auth; and signatures (JWS over a canonicalized card, new in v1.0) makes the card tamper-evident through caches and relays. A2A also absorbed IBM's rival ACP under the Linux Foundation — consolidation, not fragmentation. (Part 2 dissects the card and its trust model in depth.)

Problem 3 — Carrying know-how: Agent Skills

Tools tell an agent what it can touch; Skills tell it how your organization works. A Skill is a folder with a SKILL.md — YAML frontmatter plus instructions and optional scripts. The elegant idea is progressive disclosure: agents preload only each Skill's name and description, loading the body on demand — hundreds of Skills, no context bloat. An open standard since December 2025, running across 20+ platforms; a Skill written once is portable across agents, which makes your Skills reusable IP.

Problem 4 — Paying: AP2, ACP, and x402

The messiest frontier — three overlapping efforts, each with a different center of gravity.

AP2 (Agent Payments Protocol) — Google's open standard, launched September 2025 with 60+ partners (Mastercard, PayPal, Amex, Coinbase). Its trust model is a chain of signed mandates, each a selectively disclosable SD-JWT credential (RFC 9901): an Intent Mandate ("concert tickets ≤ $150, before Friday"), a Cart Mandate (the exact approved order), and a Payment Mandate that tells the network an agent was involved and whether the human was present. The asymmetry is the design insight — human watching? The strong signature lands on the final cart. Human absent? A detailed intent is signed up front and the agent closes within its bounds:

// AP2 Intent Mandate (human-not-present) — the user's signed "contract"
{
  "intent_mandate": {
    "natural_language_description": "Concert tickets, max $150, before Friday",
    "merchants": null,                      // any merchant allowed
    "requires_refundability": true,
    "intent_expiry": "2026-07-24T00:00:00Z",
    "user_cart_confirmation_required": false  // agent may close the cart
  },
  "user_authorization": "eyJhbGciOi..."     // user-signed SD-JWT credential
}

It's already reaching real rails: Mastercard Agent Pay ran its first authenticated agentic transaction in Q3 2025, and Visa's Intelligent Commerce Connect targets GA in June 2026.

Agentic Commerce Protocol — OpenAI + Stripe's merchant-centric standard powering ChatGPT's Instant Checkout. OpenAPI-specified, date-versioned (in beta since 2025-09-29), built around a Delegate Payment spec: the buyer's agent passes a scoped, single-use payment token (Stripe's Shared Payment Token) authorized for a specific amount and merchant — so the merchant stays the merchant of record and the agent never holds raw card data.

// ACP delegate_payment — mint a scoped, single-use token
POST /agentic_commerce/delegate_payment
{
  "payment_method": { "type": "card", "number": "4242…", "exp_month": "11" },
  "allowance": {
    "reason": "one_time",
    "max_amount": 15000, "currency": "usd",    // ≤ $150.00, cents
    "merchant_id": "merchant_123",             // this merchant only
    "expires_at": "2026-07-22T12:00:00Z"
  },
  "risk_signals": [ { "type": "card_testing", "score": 5 } ]
}
// → { "id": "vt_abc123" }  — the only thing the agent ever carries

x402 — Coinbase's revival of the dormant HTTP 402 Payment Required status code, now run by an independent x402 Foundation under the Linux Foundation (40 members including AWS, Visa, Cloudflare). The flow is HTTP-native: server responds 402 with payment requirements, client retries with a signed payment header, a facilitator verifies and settles in stablecoins — machine-speed micropayments with no accounts:

GET /api/market-report          → 402 Payment Required
{ "x402Version": 1, "accepts": [{
    "scheme": "exact", "network": "base",
    "maxAmountRequired": "10000",              // 0.01 USDC, atomic units
    "payTo": "0xAbC…", "asset": "0xA0b8…",     // USDC contract
    "resource": "/api/market-report", "maxTimeoutSeconds": 60 }] }

GET /api/market-report
X-PAYMENT: eyJzaWduYXR1cmU…                    // signed payment payload
→ 200 OK  + X-PAYMENT-RESPONSE (settlement receipt)

A Google-backed A2A x402 extension already wires it in as a settlement rail beneath A2A/AP2.

They compose rather than compete head-on: AP2 supplies the authorization evidence, ACP the merchant checkout rail, x402 the HTTP-native settlement. One sticky-note warning: "ACP" means three unrelated things — Agent Communication (IBM, merged into A2A), Agentic Commerce (OpenAI/Stripe), Agent Connect (Cisco AGNTCY). Always disambiguate.

The pattern underneath: `.well-known` is quietly becoming the spec

Every protocol above converges on the same move: fetch a self-describing card from a well-known URL, verify who published it, then speak its native protocol.

This isn't a convention the agent world invented — /.well-known/ is a formal IANA registry (RFC 8615), and the agent specs are just registering new tenants in the table that already holds the web's auth plumbing. That's why agents don't reinvent login: an MCP server is a standard OAuth resource server, and an agent bootstraps everything from the base URL alone — server card for capabilities, 401 → /.well-known/oauth-protected-resource (RFC 9728) → /.well-known/oauth-authorization-server (RFC 8414) for the token, then connect.

The next fight is already visible here: a cross-protocol draft of ai-catalog.json would let one domain advertise all its agents, servers, and skills; Google's ARD spec (June 2026) layers registries and trust on top. Discovery and identity — not the protocols — are the unsettled frontier. Also circling: ANP and MIT's NANDA (decentralized identity), Cisco's AGNTCY, and MCP Apps (tools returning interactive UI).

What this means if you're building

Adopt MCP now — the mature, safe bet; the cheapest way to make your systems agent-usable.
Design for A2A, deploy later — model capabilities as skills today so exposing an Agent Card is trivial tomorrow.
Treat Skills as reusable IP — likely more durable than any model choice.
Watch payments, don't commit — pilot behind an abstraction; AP2 vs. ACP vs. x402 is unsettled.
Reuse the web's auth plumbing — ship MCP servers as OAuth 2.1 resource servers (RFC 9728), never bespoke agent auth.
Build to the pattern, not the filename — mcp.json → mcp/server-card.json; agent.json → agent-card.json. Wrap discovery behind your own interface so spec churn is a config change.

We're watching the early web's standardization arc replay — messy, vendor-driven, then consolidated under neutral governance. The teams treating these protocols as strategic infrastructure now are the ones whose agents will actually participate when the wiring is done.

Part 2 goes beneath the protocols: identity, delegation, and why an OAuth token is nowhere near enough for an autonomous agent. What are you betting on — MCP-first, A2A-ready, or waiting for the dust to settle?

Correction (2026-08-09): AP2's mandates are selectively disclosable SD-JWT credentials (RFC 9901) presented over OpenID4VP, not W3C Verifiable Credentials as this piece originally said, and the Intent / Cart / Payment Mandate vocabulary shown here is AP2 v0.1; v0.2 reworked it. AP2 stewardship moved to the FIDO Alliance in April 2026. The LinkedIn original preserves the earlier text.

References

MCP specification & discovery: modelcontextprotocol.io · SEP-1649 · SEP-2127 (Server Cards) · MCP Registry
A2A: spec · v1.0 announcement (signed Agent Cards) · ACP merges into A2A (LF AI & Data)
Agent Skills: agentskills.io · Anthropic engineering deep-dive
Payments: AP2 spec · Agentic Commerce Protocol · x402 · A2A x402 extension
Discovery substrate: RFC 8615 (well-known URIs) · RFC 9728 (Protected Resource Metadata) · ai-catalog.json working repo · Google ARD announcement

Can You Trust an Autonomous Agent? The Identity and Delegation Layer Behind MCP, A2A, and AP2

Thu, 23 Jul 2026 00:00:00 GMT

Part 2 of the agentic-web series. Start with Part 1; Part 3 proposes what's missing, and Part 4 follows the retry problem.

Give an agent a valid OAuth token and it can call an API. For years, that was the whole trust conversation. But an agent that acts on its own, spends money, and hands work to other agents raises four questions a bearer token can't answer — and each now has its own standard.

Layer 1 — Identity: who is this agent?

TLS proves you fetched a card from acme.ai — but the moment that card is cached, indexed by a registry, or relayed agent-to-agent, the channel proof is gone. That's why A2A v1.0 made Agent Cards signed artifacts: canonicalize (RFC 8785), sign (JWS, RFC 7515), publish the signature on the card, verify against the publisher's keys. For identity that outlives any one platform, did:web:acme.ai resolves to /.well-known/did.json — decentralized identity, same discovery substrate.

The Agent Card, up close

The card itself is one JSON file doing three jobs: identity (who signed it), résumé (skills that registries index and LLM routers rank), and API contract (which transport and auth to use). Two field pairs do the heavy lifting: skills[] + supportsAuthenticatedExtendedCard splits your public shingle from your private catalog, and securitySchemes + signatures makes the card enforceable rather than descriptive.

Layer 2 — Authorization: which flow gets the token?

Identity is not authorization — a verified agent still needs a scoped token from the server's /.well-known/oauth-protected-resource chain. The real design decision is which grant flow, and one question routes it: where is the human relative to the agent at token time?

Two of these five deserve sequence diagrams, because they're the newest and the most agent-shaped.

CIBA is the standards answer to human-in-the-loop: the agent pushes an approval to your phone mid-task, keeps working, and polls for the token — no browser redirect, no "reply YES to approve" hack. Auth0, Okta, and WSO2 all shipped agent-focused CIBA in the past year; it's under active MCP-WG discussion.

ID-JAG / Cross-App Access (IETF OAuth WG, draft -04, 2026) lets an enterprise agent swap the user's existing SSO assertion for tokens to other apps — making the IdP, not each SaaS app, the governance point for agent access.

Whatever the flow, three hardeners are defaults: DPoP (RFC 9449) binds tokens to the agent's key, RAR (RFC 9396) replaces blunt scopes with authorization_details like "spend ≤ $150 at merchant X," and PAR (RFC 9126) protects the request itself.

Layer 3 — Delegation: on whose behalf, and how far?

Real agentic work is a chain — user → orchestrator → specialist → merchant MCP — and a single shared token loses whose authority is in play. Token Exchange (RFC 8693) fixes the foundation: every hop re-mints the token, delegation nests inside the act claim, scope shrinks while attribution grows. Delegation, not impersonation. What's new in 2026 is the control plane around the chain: Identity Chaining carries it across trust domains, Transaction Tokens propagate it inside your domain, AuthZEN's agent profiles (COAZ, AARP) externalize the per-tool decision, and Shared Signals/CAEP revokes it mid-task. The chain proves, AuthZEN decides, Txn-Tokens propagate, CAEP revokes.

Layer 4 — Accountability: can we prove it later?

"The agent decided to" is not an audit record. AP2's mandates — each a selectively disclosable SD-JWT credential (RFC 9901) — encode one elegant asymmetry: the riskier the autonomy, the earlier and more detailed the human signature. Human present: the strong signature lands on the final cart. Human absent: the user signs a detailed Intent Mandate up front, and the agent closes within its bounds. Every party ends up holding cryptographic proof instead of logs — and the rails are live: Mastercard Agent Pay ran its first authenticated agentic transaction in Q3 2025, Visa's Intelligent Commerce Connect hits GA in June 2026, and FIDO is aligning verifiable intent with passkeys.

How it composes

An MCP tool call, an A2A hand-off, and an AP2 purchase are the same motion at different stakes: present a verifiable identity, carry a scoped delegation, leave a provable record — at every hop. A production platform needs six components, each mapped to a standard rather than invented: an agent runtime (workload identity + DPoP keys), a discovery layer (.well-known cards and catalogs), an authorization server speaking the full grant playbook, a policy decision point (AuthZEN/RAR), verifying resource servers, and an evidence store for mandates. If a box in your architecture maps to none of these, ask why it exists.

What's unsettled, and what to do

Agent identity is the contested layer — enterprise IAM (Entra Agent ID, Okta), DIDs/VCs, and SPIFFE are all claiming it, and consolidation will be messy. Until then, five defaults serve builders well:

Sign your cards, publish a did:web, regenerate both in CI — never hand-edit a signed card in production.
Match the grant to the moment; if your agent asks for approvals over chat, you needed CIBA.
Never share a service account across hops — token exchange with act chains, always.
DPoP + RAR on every flow — sender-constrained, fine-grained by default.
Anything that spends gets a signed mandate and a human at the mandate boundary.

Part 1 mapped the protocols; this mapped the trust underneath them. The uncomfortable truth: most agent deployments today run on layer 2 alone. The stack above is how "autonomous" stops meaning "unaccountable."

Correction (2026-08-09): AP2's mandates are selectively disclosable SD-JWT credentials (RFC 9901) presented over OpenID4VP, not W3C Verifiable Credentials as originally published. The LinkedIn original preserves the earlier text.

The Hardware-Accelerated Mesh: How DPUs and Ambient Topologies Killed the Data Center Tax

Thu, 26 Feb 2026 00:00:00 GMT

For the last five years, cloud architects have been fighting a losing battle against the Data Center Tax.

As monolithic applications decomposed into thousands of microservices, organizations deployed service meshes (like Istio and Linkerd) to handle mutual TLS (mTLS), L7 routing, and observability. The dominant architecture was the sidecar model: injecting a proxy (typically Envoy) into every single application pod.

While elegant in theory, the physics of this design are brutal at scale. Traffic originating in user space must traverse the kernels TCP/IP stack to the local Envoy sidecar, get encrypted, traverse the kernel again to the physical network, and repeat the process in reverse on the receiving end. In dense multi-tenant environments, this software proxy layer can consume up to 30% of host CPU cycles—resources that should be generating revenue. Furthermore, this architecture adds approximately 0.63ms to 0.88ms of P99 latency per hop.

In the era of high-frequency trading and Agentic AI workflows—where hundreds of containerized inference microservices must communicate in microseconds—software-bound sidecars are a fatal bottleneck.

In 2026, the solution has arrived through a perfect marriage of software redesign and silicon innovation.

1. The Software Metamorphosis: Istio Ambient Mesh

You cannot offload a bloated architecture to hardware and expect miracles. The software had to evolve first. This evolution culminated in the General Availability of Istio Ambient Mesh, a sidecarless architecture.

Ambient Mesh solves the proxy bloat by bifurcating the data plane into two distinct layers:

The ztunnel (Zero Trust Tunnel): A lightweight, Rust-based DaemonSet deployed once per node. It handles strictly Layer 4 traffic—enforcing mTLS, SPIFFE identity, and TCP authorization.
Waypoint Proxies: Dedicated L7 Envoy proxies deployed only when advanced HTTP routing or payload inspection is required, configured on a per-namespace basis.

By removing L7 parsing from the default path, the ztunnel reduces the base mesh latency from ~0.85ms down to a blistering 0.16ms. But the true magic of Ambient Mesh is that its per-node ztunnel architecture maps perfectly to the physical topology of a Data Processing Unit (DPU).

2. Enter the DPU: The Third Pillar of Compute

A DPU or IPU (Infrastructure Processing Unit) is essentially a fully functional mini-server residing on your PCIe bus. They combine high-speed network interfaces (400G/800G) with programmable packet pipelines (like P4) and arrays of embedded ARM cores.

By 2026, the silicon capabilities of these devices have reached staggering levels:

NVIDIA BlueField-4: Pushing the boundaries with 800 Gb/s throughput and 64 ARM cores, delivering 6x the compute power of its predecessor.
Intel IPU E2200: Featuring 24 Arm Neoverse N2 cores, a 32MB system-level cache, and 400 Gb/s networking.
AMD Pensando Salina 400: Utilizing a massive array of 232 proprietary Match Processing Units (MPUs) programmed via P4 to handle stateful connections at 400 Gbps.

3. Offloading the Mesh: Zero Trust at Line Rate

When we combine Ambient Mesh with DPUs, we fundamentally alter the security and performance profile of the data center.

Instead of running the ztunnel as a software process on the host x86 CPU, the ztunnel and its cryptographic keys are deployed directly onto the embedded ARM cores of the DPU.

This achieves true Hardware-Enforced Zero Trust. Because the routing rules, policies, and certificates live on the DPU, the host operating system has zero visibility into the control plane. Even if a tenants container is entirely compromised by a malicious actor, they cannot alter network topologies or extract mTLS keys, because the enforcement mechanism sits on an isolated physical processor.

Furthermore, leveraging native eBPF (Extended Berkeley Packet Filter) frameworks like Cilium, traffic is intercepted at the exact moment the network driver pulls the packet from the NICs receive ring. Utilizing the DPUs inline cryptographic engines (like the BlueFields Public Key Accelerator), asymmetric RSA/ECC handshakes and symmetric AES-GCM encryption are executed at line-rate (400Gbps+) with virtually zero latency penalty.

4. The Economic Reality: Power, TCO, and AI Inference

Ultimately, the shift to hardware-accelerated meshes is driven by extreme data center economics. General-purpose x86 CPUs are highly inefficient at moving and encrypting packets.

1. Massive Power Reductions:

In large-scale clusters, power availability is the ultimate constraint. Benchmark testing reveals that offloading Open vSwitch (OVS) and SDN tasks to a DPU reduces peak server power consumption by up to 29% (roughly 127 Watts per server). Across a 10,000-node cluster, this represents millions of dollars in direct electricity and cooling savings.

2. Complete CPU Reclamation:

By moving the service mesh and security boundary to the DPU, platform engineers reclaim 100% of the host CPU for revenue-generating workloads. In some hyperscale deployments, just two DPU cards have successfully replaced the networking overhead of 52 general-purpose CPU cores.

3. Turbocharging Agentic AI:

For AI inference, network latency dictates user experience. When deploying a hardware-accelerated L7 Waypoint proxy (such as F5 BIG-IP Next) directly on an NVIDIA BlueField-3 DPU, benchmarks show a 30% increase in LLM token throughput and a massive 60% reduction in Time-to-First-Token (TTFT).

The Bottom Line

We have officially moved past the era where infrastructure software competes with application logic for CPU time. Thanks to open standards pushed by the Open Programmable Infrastructure (OPI) project , these DPU offload architectures are becoming vendor-agnostic and accessible to mainstream enterprises.

If you are scaling Kubernetes, AI inference, or high-throughput microservices today, the service mesh is no longer just a software daemonset. It is the silicon sitting on your PCIe bus.

WebMCP: The HTTP of the Agentic AI Age

Tue, 17 Feb 2026 00:00:00 GMT

For the last three years, we’ve been forcing AI agents to browse the web like a human trying to read a book through a telescope.

They render a page, take a massive screenshot, send millions of pixels to a vision model, and hope the AI guesses that the blue rectangle saying "Submit" is actually a button. It’s slow, expensive, and honestly, it’s fragile engineering.

This week, that era effectively ended.

With the release of Google’s Web Model Context Protocol (WebMCP) in Chrome 146, the web has fundamentally shifted. We are moving from a "visual-first" web, built for human retinas, to an "agentic-first" web built for AI reasoning. The browser is no longer just a document viewer; it is now a standardized API server that lets agents "talk" directly to websites.

If you are a CTO, Architect, or Engineering Lead, your roadmap just changed. Here is the deep technical breakdown of how WebMCP works, how to deploy it on Kubernetes with Zero Trust, and, most importantly, how to secure it when your "users" are no longer human

1. The Core Shift: The Browser as a Client-Side Server

To understand WebMCP, you have to flip your mental model of the web upside down.

In the traditional web, the browser is a client requesting data from a backend. In the WebMCP architecture, the browser tab becomes a server. It exposes a list of "tools" (capabilities) that a client (the AI agent) can call.

When an agent visits your site, instead of parsing DOM nodes or guessing CSS selectors, it performs a structured handshake:

Agent: "OPTIONS /capabilities" (Metaphorically)
Browser: "I can search_flights, add_baggage, and checkout."

This eliminates the "Execution Gap." The agent doesn't need to calculate X/Y coordinates for a simulated click; it simply invokes a function.

2. Two Roads to Integration: Declarative vs. Imperative

WebMCP gives us two distinct interfaces to expose these capabilities. One is for the HTML purists (SEO-style), and the other is for the JavaScript power users (Application-style).

The Declarative API: "Agent Optimization" (AO)

If you have a legacy application or a Server-Side Rendered (SSR) site, you don't need a rewrite. You just need to annotate your existing HTML forms. Think of this as Agent Optimization (AO), the new SEO.

The Code: You add toolname and tooldescription attributes. The browser automatically synthesizes these into a JSON schema for the agent.

The Imperative API: Full Programmatic Control

For Single Page Applications (SPAs) or complex state changes (like a "Crop Image" feature), HTML forms aren't enough. You need the Imperative API, which lives on the navigator.modelContext object.

3. Zero Trust Security: Inverting the Perimeter

Deploying WebMCP in an enterprise environment introduces a terrifying variable: The user might be an autonomous agent.

Traditional security relies on "Ingress Control" (stopping bad guys from getting in). Agentic security requires Egress Control (stopping your own agents from sending data out to the wrong place).

The "Lethal Trifecta"

Security researchers define the "Lethal Trifecta" for agents as the combination of:

Access to Private Data (e.g., reading emails).
Access to Untrusted Content (e.g., reading a webpage).
External Communication (e.g., sending an API request).

If an agent has all three, a malicious website can use "Prompt Injection" (hidden text on a page) to trick your agent into exfiltrating secrets

Mitigation: The Reference Pattern

WebMCP solves this by enforcing a Reference Pattern. The rule is simple: Never give the LLM the raw sensitive data. Give it a token instead.

❌** INSECURE:**

✅** SECURE (WebMCP Reference Pattern):**

4. Enterprise Architecture: Kubernetes, Service Mesh & Edge

How do you deploy this at scale? You don't just run it on a laptop. You deploy MCP Servers as microservices within your existing infrastructure.

The "Agent Mesh" (Istio Ambient Mode)

In a Kubernetes cluster, you treat Agents and Tools as distinct workloads.

Identity Sprawl: Every agent instance needs a SPIFFE ID. You must audit exactly which agent instance (e.g., spiffe://cluster.local/ns/agents/sa/finance-bot-v2) accessed a resource.
mTLS: Use Istio Ambient Mode (sidecar-less) to enforce mutual TLS between the Agent Pod and the MCP Server Pod. This ensures that even if the cluster is breached, an attacker cannot spoof an agent's identity.

Authorization: Why RBAC Fails & The Need for ABAC

In a traditional app, Role-Based Access Control (RBAC) works: "User is an Admin, so they can Delete."

For agents, RBAC is dangerous. An agent might be "acting as an Admin," but it shouldn't have carte blanche to delete the database because it hallucinated a command. You need Attribute-Based Access Control (ABAC) to evaluate the context of the request.

The Policy Check (Open Policy Agent / Cerbos style):

Immutable Auditing: The "PhysicalTask" Protocol

For regulated industries (Finance, Healthcare), "The AI did it" is not a valid legal defense. We are seeing the adoption of Cryptographic Intent Logging.

Every time an agent constructs a tool call, the infrastructure generates a SHA-256 hash of the prompt (intent) and the payload (action).
This hash is written to an immutable ledger. If an agent goes rogue, the SOC can replay the cryptographic chain to prove exactly why the agent made that decision.

5. Strategic Takeaway: The "Dual-Layer" Web

We are witnessing the bifurcation of the internet.

Layer 1 (Visual): Built with CSS, Canvas, and React for human eyes.
Layer 2 (Agentic): Built with WebMCP, JSON Schema, and Policy-as-Code for AI minds.

If you are a technical leader, "Agent Optimization" is the new battleground. Deploying WebMCP endpoints isn't enough; you must secure them with Zero Trust principles, govern them with ABAC policies, and optimize them at the Edge.

The bots are coming to your website. Make sure you speak their language.

What are your thoughts on the security implications of client-side agent servers? Let’s discuss in the comments. 👇

The Invisible Revolution: How AI is Rewiring the Data Center Network

Thu, 12 Feb 2026 00:00:00 GMT

The assumption that "Ethernet is Ethernet" is officially dead.

For years, hyperscale networking was dominated by generic Ethernet relying on TCP/IP. It was designed for resilience over unreliable links. If a packet dropped, TCP noticed, waited, and retransmitted. In the world of web applications, this latency was acceptable.

In the world of AI supercomputing, it is catastrophic.

AI training is a massive distributed computing problem. Thousands of GPUs must constantly synchronize vast amounts of data (gradients). If one packet in that synchronization phase is dropped due to switch buffer congestion, the entire cluster—potentially 20,000 GPUs—waits for the retransmission. This "tail latency" event destroys training efficiency.

We are witnessing a fundamental shift from "Generic Ethernet" (best effort, lossy) to "AI-Tuned Ethernet" (predictable, lossless). This shift is being codified by platforms like NVIDIA Spectrum-X and open standards like the Ultra Ethernet Consortium (UEC). They are redefining Ethernet to support RDMA (RoCE v2) at massive scale.

Here is a detailed look at how this new fabric changes critical infrastructure concepts.

1. Redefining the "Transaction" at High Scale

In standard networking, a transaction might be a database query. In AI networking, a transaction is often a "Collective Operation" (like an All-Reduce), where every GPU shares data with every other GPU simultaneously.

This leads to unique traffic patterns that break generic Ethernet:

Elephant Flows: Massive, long-lived streams of data, unlike the "mice flows" of web traffic.
Incast: The moment when hundreds of senders transmit to a single receiver simultaneously, causing instantaneous buffer overflows in standard switches.

The AI-Tuned Fix: Instead of reactive TCP congestion control (dropping packets when full), AI fabrics are proactive. Through advanced telemetry, the switch communicates directly with the NIC (Network Interface Card) to throttle traffic before congestion occurs, ensuring the "transaction" completes without packet loss.

2. The Evolution of the "Service Mesh" into Hardware

We are used to Service Meshes (like Istio) operating at the software layer to manage traffic between microservices. In AI, the performance demands are too high for software proxies.

The "Service Mesh" is moving down into the hardware, specifically into DPUs (Data Processing Units) and SmartNICs used in Spectrum-X and UEC designs.

Generic Ethernet: Uses ECMP (Equal-Cost Multi-Path) routing, which hashes a flow to a single path. If two "Elephant Flows" hash to the same path, they collide, causing congestion, while other paths remain idle.
AI-Tuned Fabric: Utilizing advanced techniques like Packet Spraying (a key feature of UEC), a single large transaction is split into individual packets and sprayed across all available paths simultaneously, reassembling them at the destination. This ensures 100% utilization of fabric bandwidth and acts as a hardware-based traffic manager.

3. Security in a Direct-Memory-Access World

The magic of modern AI speed is RDMA (Remote Direct Memory Access). It allows one GPU to write data directly into the memory of another GPU across the network, bypassing the remote CPU entirely.

In a multi-tenant cloud, this is terrifying.

If not properly secured, Tenant A could potentially read the memory of Tenant B. Generic Ethernet security (firewalls, IP ACLs) is too slow and CPU-intensive for 800Gbps line rates.

The AI-Tuned Fix: Security is enforced at the NIC hardware level. Modern fabrics implement technologies like Zero Trust RoCE (ZTR). This uses strict memory protection keys and hardware-based encryption (like IPsec or PSP) executed at line rate on the DPU. A tenant can only access memory regions explicitly authorized for their specific job ID. Any unauthorized RDMA attempt is dropped instantly by the hardware, providing isolation without the performance penalty of software checks.

4. Dynamic Configuration via SONiC

In traditional networking, network configurations were relatively static. In an AI cloud, the network topology needs to logically reshape itself constantly.

When a Kubernetes scheduler places a new training job, the network must instantly reconfigure to optimize for that specific workload. A large language model training run has different traffic patterns than an image generation model.

The AI-Tuned Fix: This requirement has solidified SONiC (Software for Open Networking in the Cloud) as the operating system of choice for AI fabrics. SONiC allows the entire network stack to be managed via APIs.

The fabric can dynamically adjust switch buffer allocations, change routing protocols, and push specific congestion control profiles to the NICs based on the job type—all automatically, in seconds.

The Bottom Line

The transition from Generic Ethernet to AI-Tuned Ethernet fabrics like Spectrum-X and UEC is not merely an upgrade in speed; it is a fundamental change in networking philosophy.

We are moving from a world that tolerates loss to one that demands deterministic performance. For organizations investing billions in GPU infrastructure, the network is the critical bottleneck determining whether that investment yields a return in weeks or months.

If you are building for AI, you cannot rely on the networking assumptions of the past two decades.

The Enterprise AI Gap isn't Model IQ anymore. It’s Execution + Trust

Thu, 05 Feb 2026 00:00:00 GMT

We are crossing the chasm from "AI that helps" to "AI that does."

OpenAI’s recent Frontier announcement confirmed what many of us in enterprise infrastructure have suspected: The bottleneck isn't model IQ anymore. It’s execution + trust.

Frontier isn't just about smarter chatbots; it reads like a blueprint for operationalizing AI coworkers.

The "Frontier Stack": Layered Defense

What Frontier Signals (Beyond the Headline)

The platform is positioned to build and deploy AI coworkers by giving them the "skills" we use to scale people: shared context, onboarding, feedback loops, and clear boundaries.

Shared Context is a First-Class Primitive: Agents aren't trained on isolated docs; they connect to enterprise systems (CRM, ticketing, internal apps) to build a shared semantic understanding of the business.
From Conversation to Execution: The framing shifts from "AI answers questions" to "AI completes workflows"—coordinating multi-step tasks across tools, which is where both ROI and risk appear.
The Execution Environment Matters: Frontier highlights a dependable runtime (files, code, tools, memory), making it a controlled operating environment, not just an API call.
Identity & Permissions are the Scaling Lever: Agent systems need workload identity, least privilege, and auditability to be safe in real workflows.

The Reality Check

But here is the hard truth: If agents are the new runtime for work, security cannot be an afterthought. As we move from conversation to execution, the risk surface explodes.

We aren't just worried about wrong answers anymore. We are worried about over-permissioned agents, authorized incidents, lateral movement through tools, and silent failures at scale.

If you are building agentic systems, you need a new architecture. You need Zero Trust for Agents.

Here is a practical blueprint for a trust fabric that allows agents to act autonomously without becoming an unbounded risk.

The 8-Point "Zero Trust Agent" Blueprint

1. Strong Agent Identity (Workload Identity) Treat agents like production microservices with unique, short-lived identities. Use mTLS with context claims for every call.

2. The Tool Gateway (Your New Perimeter) This is the most critical choke point. Nothing bypasses the gateway, which enforces allowlists, schema validation, and rate limits.

3. Policy-as-Code Authorization (Beyond the Prompt) Stop putting auth logic in natural language prompts. Move it to a deterministic policy engine that evaluates who, what, why, and real-time risk signals.

4. Governed Context Retrieval Shared context is vital but must not become data sprawl. Implement retrieval boundaries and DLP scanning on inputs and outputs.

5. Runtime Isolation & Egress Control Assume breach. Sandbox execution environments and ruthlessly restrict network egress.

6. The Immutable Action Ledger Observability is your safety net. Every agent decision must produce a trace ID and write to an append-only audit record.

7. Continuous Evaluation Loops Drift is inevitable. Constantly run offline eval suites for expected behavior and online scoring for safety and quality.

8. Step-Up for High-Risk Actions Design patterns for "human-in-the-loop" interrupt circuits when risk scores hit a threshold.

The Takeaway

The winners in this next phase won't just be the ones with the smartest agents. It will be the teams that build the strongest trust fabric around those agents.

If you are building agentic systems today, I have one question for you:

Where is your policy enforcement living—inside the app logic, at a platform gateway, or scattered across a service mesh? Let me know in the comments. 👇

#AgenticAI #ZeroTrust #AIInfrastructure #PlatformEngineering #Cybersecurity #EnterpriseAI #MLOps

AI Agents vs. Agentic AI vs. MCP Server–Based AI vs. A2A AI: Technical Angle

Thu, 09 Oct 2025 00:00:00 GMT

This is the part 2 of the previous post where we went over the differences in AI Agents, Agentic AI, MCP servers and A2A AI from business angle. Lets do a deep dive from technical perspective.

Technical Version

Clear boundaries

AI Agent: A goal-directed software entity with a control loop: observe → plan → act → reflect → stop/iterate. Uses tools/APIs, memory, and policies (budgets, approvals).
Agentic AI: The toolkit that makes agents competent: ReAct-style reasoning, function calling, planners (flat/hierarchical), working and long-term memory, critique/reflection, stop criteria.
MCP server–based AI: Model Context Protocol links assistants (clients) to tools/resources exposed by MCP servers. The client discovers capabilities, requests permission, invokes with typed args, and receives structured results. Transport commonly via JSON‑RPC over stdio/WebSockets.
A2A AI: Agents messaging and coordinating—either orchestrated (a coordinator delegates) or peer-to-peer. Requires identity, policy, convergence, and observability across boundaries.

Minimal implementation details

Agent loop (pseudocode-ish)

state = load_task_state()
steps = 0
while not done and steps < max_steps and within_budgets():
ctx = gather_context(state) // working memory + retrievalplan = model.
plan(goal, ctx) // planner prompt/tool
tool, args = pick_tool(plan)
args = validate_against_schema(tool.schema, args)
result = call_tool(tool, args) // retries, timeouts, idempotency
critique = model.reflect(result, plan)
update_memory(state, plan, result, critique)
done = check_stop(result, steps, policies)
steps += 1

Tooling and memory

Tools: Function calling with strict JSON schemas; idempotent writes; safe sandboxes; rate limits.
Memory:
Working memory (recent steps).
Retrieval (RAG) for domain docs.T
ask memory/state (DB row keyed by task_id).
Optional episodic log for evaluations.

MCP servers (practical)

Server advertises:
Tools: name, description, JSON schema, auth/policy, rate limit, idempotency hints.
Resources: datasets/files/endpoints, scopes, read/write modes.
Prompts: reusable templates.
Client flow:
Connect → discover → request scopes/consent → invoke → stream/receive → log.
Security/governance:
Secrets stay in servers; per-tool scopes; approval prompts on risky operations; full audit trail.
Operability:
Versioned servers; health checks; retries/backoff; quotas; central registry for approved servers (CRM, ERP, ticketing, DW).

A2A messaging (nuts and bolts)

Message envelope:
id, correlation_id, sender, recipients, intent, payload, policy_context, ttl, signature.
Coordination patterns:
Orchestrator-led: Simpler to reason about; one source of truth for state.
Peer-to-peer: Needs convergence criteria, leader election or arbitration, deadlock/timeouts.
Identity/trust:
Keys per agent; allow/deny lists; capability attestations; optional budget/credit tokens; per-partner policies.
Safety:
Policy engine (think OPA-style) evaluates intent+context; high-risk actions require human sign-off.
Observability:
Semantic traces, tool-call logs, message timelines, state diffs; redaction for PII.

Reference deployment topologies

Single agent serviceLLM + tool registry + memory store + policy engine; deployed as a stateless API with a task DB.
Agent + MCPThin assistant client; integrations live in MCP servers; policy and audit centralized; assistants across products reuse the same servers.
Multi-agent (A2A)Agents publish/subscribe on a message bus; orchestrator or broker enforces policy; external partner agents connect via API gateway with contract SLAs.

Expanded technical use cases (with brief flows)

Analytics assistantPlan analysis → run SQL via MCP Postgres server (read-only) → chart → self-check outliers → revise → export to BI.
Data quality agentScan tables → compute drift/anomaly metrics → file tickets via MCP Jira server → open PR to fix dbt tests with human review.
SRE incident agentParse alert → run runbook steps via tool calls (kubectl, logs) in a safe sandbox → propose rollback → request approval via MCP Slack server → execute rollback tool.
Contract review agentChunk contract → check clauses against a policy KB → propose redlines → route to legal approver; store artifacts via MCP DMS server.
Procurement A2ABuyer agent posts RFQ → supplier agents respond with quotes → pricing/legal agents score → buyer agent negotiates within budget → ERP PO created via MCP server.

Design trade-offs and guardrails

Determinism vs autonomy: Cap steps/time/cost; approval gates for writes; rollback plans.
Latency/cost: Multi-step plan-act loops, add hops; cache retrieval; pre-plan batches; prefer streaming where possible; aggressive timeouts.
Reliability: Retries/backoff; circuit breakers; schema-first tools; idempotent operations; golden tasks for regression.
Security: Secrets in servers; least privilege; prompt shielding; allow/deny lists; redact PII; comprehensive audit.
Evaluation: Track task success, human intervention rate, tool error rate, convergence time, cost per completed task, and user satisfaction.

Anti-patterns to avoid

Unbounded loops or no stop criteria.
Write access to prod without strong approvals.
Embedding credentials in prompts or client code.
Multi-agent chatter where one specialist agent would suffice.
Copy-pasting integrations into each agent instead of centralizing via MCP.

Technical comparison table

Technical Usaecases

How they correlate and stack together

Conceptual stack

Agentic AI is the “how” (methods) that gives an AI the ability to plan, use tools, and self-correct.
AI Agent is the “who” (entity) that uses those methods to achieve a goal under policies and budgets.
MCP server–based AI is the “plumbing” that safely connects agents to enterprise tools and data.
A2A AI is the “network” pattern where multiple agents interact to complete cross-boundary workflows.

Practical lifecycle

Start: Add Agentic AI patterns to a capable model to handle multi-step work.
Wrap: Package it as an AI Agent with policies, memory, and evaluation.
Connect: Use MCP servers to grant governed access to your systems and data.
Scale: Introduce A2A when tasks naturally span teams/companies and benefit from automated negotiation/coordination.

Selection guidance by maturity

Selection process

End-to-end example (correlated)

Research-to-brief

Agentic AI: Plan sources → fetch → synthesize → self-critique → finalize.
AI Agent: Orchestrates steps, maintains state, manages budgets.
MCP: Provides safe access to Confluence, CRM, data warehouse, and web search.
A2A: Hands off to a localization agent and a legal-review agent; resolves comments and publishes.

Final takeaways

AI Agent is the unit of action. Agentic AI is how you make it capable and reliable. MCP server–based AI is how you connect it to your world safely. A2A AI is how multiple agents cooperate across boundaries.
Start small, add autonomy gradually, centralize integrations via MCP, and only move to A2A once single-agent value and governance are proven.
Measure outcomes, not demos: task success, time saved, error rate, cost per outcome, and human intervention rate.

If you’re piloting agents today, pick one high-value but bounded workflow. Use agentic patterns for reliability, MCP servers for safe access, and only add A2A when the process truly spans multiple parties. Ship with guardrails, instrument everything, and iterate with metrics.

AI Agents vs. Agentic AI vs. MCP Server–Based AI vs. A2A AI: Business Angle

Tue, 07 Oct 2025 00:00:00 GMT

Summary

If you’ve sat through a few “agent” demos lately, you’ve probably heard four terms thrown around as if they mean the same thing: AI Agent, Agentic AI, MCP server–based AI, and A2A AI. They don’t. Here’s a clean way to think about them—and how to put them to work without tripping over hype.

This article clarifies four terms and then shows where each fits, how they differ, and when to use which. I will be publishing two versions of the explanations, this article covers business friendly version.

Part 1 — Business Version

Quick mental model

AI Agent is the doer, a software helper that can decide and act on goals (the digital teammate that takes steps and uses tools).
Agentic AI is the work-style, making today’s AI models behave like real assistant (planning, using tools, remembering, self-correcting).
MCP servers are the door keys and turnstiles (connect AI safely to your company’s systems using a safe, standardized, auditable connector layer).
A2A (Agent-to-Agent) is the meeting room (agents coordinating with other agents to negotiate, collaborate, or transact, sometimes across companies).

Plain-English definitions

AI Agent: A goal-driven digital assistant that can take multiple steps, use approved tools/APIs, and bring back a result with varying levels of autonomy and oversight. Think “junior teammate you can supervise.”
Agentic AI: The way we make today’s models act like that teammate—planning, using tools, iterating, checking their work and reflecting so they behave more like assistants that can get things done.
MCP server–based AI: An enterprise-friendly, standard, auditable way to connect AI to your systems (CRM, ERP, ticketing, data warehouse) with permissions and logs.
A2A AI: Agents coordinating with other agents to get a cross-team or cross-company job done end-to-end (request, reply, negotiate, approve).

Where each one is best suited

AI Agent: When you want a single digital assistant to complete a complex task end-to-end (e.g., triaging a support ticket, compiling a competitive brief, preparing a meeting with data pulls).
Agentic AI: When you need your existing AI capabilities to be more effective—plan better, use tools reliably, self-correct, and handle multi-step work.
MCP server–based AI: When you must connect AI to internal systems safely and at scale, with strong controls, audit logs, and a standardized way to add/remove integrations.
A2A AI: When workflows span multiple teams or companies and can be automated as a “conversation” among agents (e.g., procurement quoting, price negotiation, supply chain updates).

Concrete examples

- AI Agent

Sales ops: Clean leads, enrich from a data vendor, draft outreach, schedule the first call.
Support: Triage a ticket, look up known issues, run basic diagnostics, propose fixes.
Finance: Reconcile payments and invoices, flag mismatches, draft variance notes.
HR: Screen resumes against must-have criteria, schedule interviews, prep scorecards.
Marketing: Research competitors, collect examples, draft a brief and a social thread.
IT: Read logs, run predefined checks, prepare an escalation with crisp context.

- Agentic AI

Reporting: Plan which data to pull, run queries, chart results, check anomalies, revise.
Content: Outline → draft → fact-check → tone adjustment → final polish.
Coding: Plan a change, run tests/linters, fix failures, produce a PR summary.
Research: Draft a research plan, visit sources, cross-verify, synthesize into a brief.

- MCP server–based AI

One connector hub: A single, approved place for assistants to reach Salesforce, Jira, Slack, Notion, a read-only warehouse, etc.—with permissions and audit.
Regulated work: Read-only access for PII systems; redaction; time-bound permissions.
Reuse: The chat assistant, IDE copilot, and voice bot all reuse the same connectors.

- A2A AI

Procurement RFQ: Buyer agent requests quotes; supplier agents reply; pricing/legal agents score; buyer agent negotiates within budget; ERP updates the PO.
Supply chain: Inventory agent flags low stock; logistics agent finds lanes; warehouse agent schedules receiving; finance agent reserves funds.
Customer service concierge: Intake agent triages; billing agent processes refunds; policy agent approves exceptions; shipping agent prints labels.
Travel: Employee agent requests trip; policy agent approves; airline/hotel agents quote; itinerary gets booked.

How to choose (quick tests)

If there’s a clear outcome and you can supervise it: AI Agent.
If your current AI answers questions but can’t follow a plan, act and self correct: Agentic AI.
If the assistant needs access to your systems and you care about governance and scale: MCP servers.
If the process spans multiple teams or companies and requires negotiation: A2A.

Mini storylines (how they play together)

**- Quarter-end close (Finance) **

Agentic AI drafts a reconciliation plan.
AI Agent pulls transactions, flags discrepancies, drafts explanations.
MCP servers unlock ERP and bank APIs safely.
A2A coordinates with a vendor invoicing agent to fix a mismatch.

- E‑commerce returns (Operations/Support)

Agentic AI designs a decision tree for returns.
AI Agent validates orders, checks warranty, proposes options.
MCP servers connect to OMS/WMS/CRM with least-privilege access.
A2A negotiates pickup slots with a logistics agent and issues a label.

- Field service dispatch (IT/Facilities)

Agentic AI triages an incident and suggests steps.
AI Agent books a tech and reserves parts.
MCP servers integrate ticketing, inventory, and calendars.
A2A loops in a third‑party maintenance agent for after-hours coverage.

What to watch out for

Autonomy risk: Add guardrails and approval points for risky actions.
Data security: Use governed connectors (MCP) instead of hardwiring API keys into prompts.
Reliability: Start small, measure success/interventions, add fallbacks.
Compliance: Log prompts, tool calls, data touched; review integrations centrally.

Business comparison table

Final Thoughts

If you’re piloting agents today, pick one valuable, bounded workflow and ship it with guardrails. Use Agentic patterns for reliability, MCP servers for safe access, and only move to A2A once single-agent value is proven. Iterate with metrics, not demos.

AI x APIs: The new power couple

Mon, 29 Sep 2025 00:00:00 GMT

A decade ago, “mobile-first” wasn’t a slogan. It was survival. Today, the same turning point is here for “AI-first.” If you’re building anything—product, platform, or prototype—AI is no longer an add-on. It’s the operating principle.

Here’s what’s changed: AI and RESTful APIs aren’t just interoperating. They’re completing each other.

From idea to GTM, AI is in the loop

Ideation and brainstorming with copilots
Architecture and design with patterns auto-suggested
Mocks, POCs, and dev with agents scaffolding code
Testing and deployment with automated checks and release flows

This isn’t hype. It’s a productivity compounding effect. And it gets supercharged by standards like MCP and the A2A protocol that let agents discover, reason about, and safely use your APIs as “tools.”

APIs grew up—now they speak “agent” RESTful APIs remain the cleanest way to expose capability. Pair that with OpenAPI 3.x and you get contracts, documentation, and automation for free. But here’s the unlock:

Your OpenAPI spec can be converted into an MCP server where each endpoint becomes a tool.
Little-to-no extra backend code. Your existing API suddenly becomes agent-ready.
MCP clients/hosts can auto-discover, test, and consume your services safely and consistently.

What this looks like in practice

Spec-to-tools: Feed your OpenAPI 3.1 file into a generator. Instantly, your endpoints show up as callable tools agents can reason about (“create_invoice,” “get_inventory,” “book_shipment”).
AI-native QA: Contract tests, synthetic data, and agent-driven test plans spin out from the spec—catching regressions and schema drift early.
A2A orchestration: One agent plans calls, another validates responses against the schema, a third handles retries/observability. Clean, governed autonomy.

Why this wins

Faster build cycles: Ship features without re-coding integration glue.
Lower maintenance: Single source of truth—the spec—drives docs, SDKs, tests, and tools.
Safer execution: Clear auth scopes and typed schemas reduce misuse and hallucinations.
Better DX: Teams work from contracts, not tribal knowledge.

A quick AI-first playbook

Declare the contract first: Standardize on OpenAPI 3.x with rich descriptions, examples, and error models.
Make it discoverable: Publish specs to your MCP registry so agents can find and reason about capabilities.
Automate quality: CI validates specs, generates tests, and runs agent-based checks.
Design for safety: Auth scopes and rate hints in the spec guide agent behavior.
Instrument everything: Structured logs and traces tuned for both humans and agents.
Close the loop: Use real usage to evolve the spec—not just the code.

Avoid these trapdoors

“Pretty JSON,” empty semantics: Missing examples, vague descriptions, no error shapes. Agents struggle; humans too.
Proprietary glue everywhere: Fragmented adapters make scaling agents painful.
AI as an afterthought: Retrofitting later costs 10x more than designing for agents from day one.

If your API isn’t agent-ready, it’s already behind.

At Emachinelabs, we practice AI-first by default. Our APIs and backend services natively power MCP servers for instant discovery, inventory, and safe consumption by both AI agents and API clients. Result: faster iteration, cleaner governance, and measurable reductions in development and maintenance costs.

Curious how to turn your API catalog into an agent-ready platform—without boiling the ocean? Let’s talk!

Agentic AI in Healthcare: From Monitoring to Meaningful Action

Tue, 23 Sep 2025 00:00:00 GMT

Clinicians and patients are awash in data—from continuous heart monitors and wearables to lab results and imaging. Yet the value of that data is only realized when the right insight reaches the right person at the right time. In telemetry units today, signals from continuous cardiac monitors are streamed to the cloud and scanned by technicians. Despite best efforts, human bottlenecks can delay recognition of potentially life‑threatening rhythms or subtle deterioration. Agentic AI—goal‑driven AI systems that can sense, reason, act, and collaborate with care teams—offers a path to faster interventions, more personalized care, and lower cost.

Why the Status Quo Isn’t Enough

Alarm fatigue and missed events: The Joint Commission documented big alarm-related adverse events (several deaths) in 2009–2012, and ECRI has repeatedly listed alarm hazards among top health technology risks. High alarm volumes and non-actionable alerts make it harder to catch the true emergencies.
Time is clinical currency: In conditions like ventricular tachycardia, complete heart block, or sepsis, minutes matter. Even small delays from manual triage can change outcomes.
Rising workload and costs: Health systems face staffing shortages and growing telemetry volumes; manual monitoring doesn’t scale.

What Is Agentic AI? Agentic AI systems:

Monitor continuously: Ingest and interpret multimodal data (ECG, SpO2, BP, notes) in real time.
Reason with context: Combine vitals with history, meds, and care protocols to assess risk.
Act with guardrails: Triage, escalate, and recommend next steps via approved workflows, keeping clinicians in the loop.
Learn and adapt: Improve specificity, personalization, and clinician trust through feedback and audit.

How Agentic AI Improves Outcomes and Operations

1. Monitoring and Rapid Response

Event detection with fewer false alarms: AI agents filter noise and corroborate signals (e.g., cross-checking ECG, pleth, and movement) before escalating. Studies in alarm management show 40–60% reductions in nonactionable alarms in ICUs after algorithmic and policy improvements, easing alarm fatigue and improving responsiveness.
Faster, structured escalation: When sustained VT, high-grade AV block, or a significant ST change is detected, the agent can 1.) Verify signal quality and confirm multi-lead consistency. 2.) Auto-prioritize severity and notify the right on-call role via secure channels. 3.) Present a concise, clinically framed summary (trend strips, vitals trajectory, recent labs, medications) and next-step options aligned to local protocols. 4.) Track acknowledgment and re-escalate if needed.
Evidence that earlier action saves lives: Real-world early warning systems show that timely AI-supported alerts can be associated with mortality reductions. For example, a large multi-hospital study of an AI sepsis early warning tool (TREWS) found earlier treatment initiation and an associated relative reduction in mortality when clinicians engaged with the alert promptly (Nature Medicine, 2022).

2. Personalized Treatment Plans

Tailored care pathways: Agents synthesize comorbidities, prior responses, and guideline logic to suggest individualized titration, diagnostics, or consults. For cardiac patients, that can mean nuanced beta-blocker adjustments, anticoagulation considerations in new AFib, or expedited echo based on dynamic risk.
Continuous reassessment: As new data arrives, the agent updates risk and recommendations, closing the loop between monitoring and management.
Population impact: Remote patient monitoring programs have shown meaningful benefits at scale. The US Veterans Health Administration’s Home Telehealth program reported a 19% reduction in hospital admissions and a 25% reduction in bed days among enrolled patients—illustrating how continuous oversight and timely intervention can reduce acute events.

3. Lower Total Cost of Care

Fewer avoidable escalations: Earlier detection and tailored interventions reduce code events, ICU transfers, and readmissions—major cost drivers.
Productivity gains: Automating triage, summarization, and protocol matching frees technicians and nurses for higher-value care. Industry analyses estimate AI could unlock tens to hundreds of billions of dollars in annual value in US healthcare through efficiency and quality gains; McKinsey has projected up to $360B per year as capabilities mature.
Right-sizing monitoring: Agents can identify stable patients and safely decrease monitoring intensity, saving consumables and staff time without compromising safety.

A Day-in-the-Life: Continuous Heart Monitoring with an Agent

00:00: An inpatient’s telemetry shows intermittent nonsustained VT. The agent confirms lead integrity, corroborates with pleth, and notes recent potassium of 3.2 mmol/L and a missed dose of beta-blocker.
00:01: Risk stratified as “urgent.” The agent pages the telemetry nurse and on-call hospitalist with a one-screen summary and recommended actions per local policy (recheck K+, replace potassium, consider magnesium, resume/titrate beta-blocker, obtain 12‑lead ECG).
00:03: Nurse acknowledges and accepts potassium replacement order set (provider cosign required). The agent sets a 30-minute re-check for rhythm and electrolytes.
00:35: VT resolves after correction; event, actions, and outcomes are auto-documented for quality review.

Safety, Equity, and Compliance by Design

Human-in-the-loop: Alerts and orders follow clearly defined approval pathways; clinicians retain authority.
Guardrails and auditability: Versioned models, explainable rationales, and full audit trails support safety and regulatory needs.
Bias mitigation: Continuous monitoring for performance across demographics and comorbidities; retraining and thresholds adjusted to ensure equitable care.
Privacy and security: HIPAA-compliant architecture, least-privilege access, encryption, and secure messaging; adherence to IEC 62304 and ISO 14971 for software lifecycle and risk management. Pursue FDA pathways as clinical functionality warrants.

Measuring What Matters

Time from event onset to clinician acknowledgment
Time from alert to intervention
Nonactionable alarm rate and alarm-to-action ratio
Unplanned ICU transfers, rapid response calls, and code blue rates
30-day readmissions and length of stay
Cost per monitored patient and staff productivity
Clinician satisfaction and patient experience

Getting Started: An Implementation Blueprint

Start with a high-impact use case (e.g., cardiac telemetry). Map current workflows and escalation paths.
Integrate data sources: Telemetry waveforms, EHR vitals/labs/meds, staffing rosters, secure messaging.
Co-design protocols with clinical leaders; encode local policies.
Pilot with clear KPIs, safety triggers, and a feedback loop; run A/B periods to quantify impact.
Scale thoughtfully: Expand to other units and conditions (heart failure, COPD, post-op monitoring, sepsis early warning), maintaining governance and model oversight.

The Bottom Line Agentic AI turns monitoring into meaningful, timely action. By filtering noise, surfacing context, and orchestrating the next best step—always with clinician oversight—health systems can reduce adverse events, deliver more personalized care, and lower operating costs.

Emachinelabs is building Agentic AI solutions for healthcare domain that make this future practical, safe, and scalable. To learn more or pilot with us, please contact us.

Automate. Predict. Grow: Why Managed AI Is the Fastest Path to Scale for SMBs

Thu, 04 Sep 2025 00:00:00 GMT

For years, small and mid-sized businesses had two choices: complex tools they couldn’t staff, or simple tools that couldn’t scale. That era is over. AI has made enterprise-grade capability simple, affordable, and outcome-driven—exactly what SMBs need to grow.

The gap

SMBs rarely have large IT teams or deep infrastructure budgets.
They get stuck with bloated, aging systems that are hard to customize.
Big consultancies chase big accounts—leaving SMBs underserved.
Result: missed insights, manual work, slow decisions, stalled growth.

What SMBs actually want

SMBs don’t need bigger IT. They need bigger outcomes, AI-powered, managed solutions to unlock growth

End-to-end products that “just work”—not toolkits that need armies.
Customization where it matters, without custom overhead.
Predictive insights to grow: who to target, what to stock, when to act.
Managed SaaS so they can focus on customers, not servers.

How AI changes the game

Stop Buying IT. Start Buying Outcomes: Solution is in the Managed AI Growth Stacks Built for SMBs

Personalization at scale: offers, pricing, and experiences tailored per customer.
Predictive analytics: demand, churn, cash flow, inventory, staffing.
Automation everywhere: marketing, support, invoicing, scheduling, document processing.
Natural language interfaces: ask questions, get answers, act fast.

What great looks like for SMBs

A single, managed platform that connects sales, ops, marketing, finance, and support.
Built-in AI copilots that surface insights and automate workflows.
Purpose-built templates by vertical—fast to deploy, easy to adapt.
Clear pricing, low maintenance, high ROI.

Where AI delivers fast wins

Retail and eCommerce: predictive demand, dynamic bundles, AI-assisted merchandising, returns triage.
Restaurants and services: staffing forecasts, smart scheduling, review-response automation.
Professional services: lead scoring, proposal drafting, document automation, client comms.
Healthcare and clinics: intake triage, appointment optimization, billing assistance, patient follow-up.
Trades and field ops: route optimization, job quoting, parts forecasting, voice-to-job notes.

**What we do at **EmachineLabs

EmachineLabs builds AI-powered, managed, customized products for SMBs—so you grow faster without the IT burden.

Core capabilities:

AI Business Copilot: ask in plain English; get insights, actions, and automations across your stack.
Predictive growth engine: demand forecasting, churn risk, next-best-offer, pricing suggestions.
Marketing and CX automation: hyper-personalized campaigns, AI chat/voice agents, review management.
Back-office automation: invoicing, payables, reconciliations, document extraction, compliance checks.
Knowledge and workflows: secure RAG knowledge bases, SOP copilots, approvals, low-code connectors.
Secure, managed SaaS: multi-tenant architecture, role-based access, audit logs, SOC2-aligned practices.

Rapid time-to-value

30 days to first outcomes with prebuilt templates.
Managed onboarding, training, and optimization.
Scale up as you grow—no heavy IT lift required.

Illustrative outcomes we frequently see

30–50% reduction in manual workload across ops and back-office.
10–20% lift in repeat purchases via personalization.
Faster decisions: insights in minutes, not weeks.
Lower total cost of ownership vs. piecemeal tools and custom builds.

Your move If you’re an SMB leader, ask yourself

What’s the one repetitive task my team does every week that AI could automate?
Which decision would be better with a prediction, not a hunch?

Comment “READY” and I’ll share a tailored 2–3 step AI roadmap for your business. Or DM me to book a free AI readiness check.

Let’s turn operations into outcomes—so your business can scale with confidence.

— EmachineLabs AI-powered. Managed. Built for SMB growth.

AI-Powered Low-Code Platforms: Reimagining App Development for Everyone

Wed, 07 May 2025 00:00:00 GMT

“The secret to digital transformation? It’s not code. It’s the speed and ease at which you solve real world problems.”

AI Democratizing App DevelopmentToday, the speed at which digital ideas turn into tangible solutions can make or break a company’s future. Yet, the journey from a great idea to a real-world application is still fraught with hurdles: technical skills, time constraints, resource bottlenecks, and maintenance challenges.

Traditionally, solving a business problem with software meant months of development, architecture, API design, maintenance cycles, and countless lines of code. Even the rise of low-code and no-code platforms, promising an escape from complex coding, hasn’t solved all pain points—too often, they trade flexibility and scalability for ease of use. Customization gets tricky, integration takes effort, and technical intervention inevitably creeps back in.

But the landscape is changing—dramatically—thanks to the integration of artificial intelligence in low-code development. Here’s why AI-powered low-code platforms aren’t just the next trend, but a paradigm shifts in how we build for the future.

Why Low-Code Tools Still Weren’t Enough

Low Code is the start, rest process followsBefore AI, most low-code and no-code tools revolved around visual drag-and-drop builders, reusable components, and logical flows. This was certainly a leap forward, but not without gaps:

Limited Custom Logic: Complex processes required “code escapes” or arcane formulas.
Steep Learning Curve for Power Features: Integrating external services, intricate automations, or custom UIs still demanded technical skills.
Deployment and Maintenance Overhead: Updating features, scaling up, or maintaining integrations could become unwieldy as the solution matured.

Business users aspiring for true independence found themselves nudged back into developer territory. AI had the potential to close these gaps, but translating human intent to robust, production-ready software remained the holy grail.

From "No-Code" to "No-Limits": The Promise of AI-Infused Development

Speed of app developmentImagine if you could describe your business process in plain English, and an application would assemble itself accordingly: interfaces, business logic, databases, APIs, workflows, and even mobile deployment—all handled automatically. Imagine the power to iterate and experiment at the speed of thought, not at the pace of a development sprint.

That’s what today’s leading AI-powered low-code platforms are striving to making it possible. The outcome is no longer held hostage by your ability to code. The focus shifts back to the fundamental question: “What problem are we solving—and how quickly can we solve it?”

AI turns low code on its head. Instead of simply removing the friction, it automates entire chunks of application creation that previously required human expertise. AI removes the technical “glue” work: the need to wire up forms to databases, to write tedious boilerplate for business logic, to ensure deployment across multiple platforms.

Now, the digital canvas becomes accessible to everyone willing to reframe problems and imagine solutions. The digital divide isn’t between coders and non-coders. It’s between those who have a vision—and those willing to act on it.

Spotlight: Emachinelabs No-Code Platform, AI Brains

Integrated frontend, logic, API, Data and more!Among the trailblazers in this AI-powered low-code revolution is Emachinelabs, a platform that turns idea-to-app into a swift, no-code journey—accessible to anyone, regardless of their software background.

Here’s how Emachinelabs breaks new ground:

AI-Driven App Generation: Talk to Build

Emachinelabs leverages advanced AI to turn simple prompts—typed or spoken—into ready-to-use applications. Want an inventory tracker, a freight management solution, or a healthcare forms manager? Just describe it. The system scaffolds everything: data models, frontends, APIs, and even sample workflows.

Blockly-Powered Visual Logic—Beyond Drag-and-Drop

Taking inspiration from Google’s Blockly, Emachinelabs lets users construct powerful business logic visually. But unlike most platforms, these blocks aren’t just cosmetic—they represent real, scalable functions translated by AI into robust backend logic.

True No-Code Backend: Databases, APIs, and Automation

Users don’t need to look for code! Want to adjust a workflow, add an approval process, or revise notifications? Do it visually and intuitively; AI translates every block into efficient database models, CRUD APIs, and automated processes.

One-Click, Cross-Platform Deployment

With Emachinelabs, you don’t need to worry about hosting, builds, or compatibility. One click, and your application is live—on the web, iOS, and Android. It’s the kind of magic that used to cost organizations thousands in developer hours and infrastructure.

Rapid Iteration and Continuous Improvement

Need changes? Tweak your logic or interface, and the app redeploys—instantly, globally, and seamlessly, ensuring your solution always fits your evolving business needs.

Why This Matters: Unlocking True Digital Empowerment

At its core, Emachinelabs isn’t just a platform. It’s a philosophy: technology should serve the visionaries, the problem-solvers, the domain experts—not the other way around.

What does this mean for organizations and innovators?

Speed to Innovation: Go from idea to deployed software in a fraction of the time.
Lower Total Cost: Slash reliance on expensive, specialized development and maintenance teams.
Agility & Inclusivity: Empower business users—from HR to operations, from marketing to product—to build, iterate, and own their solutions.
Future-Proof Applications: Built-in AI means your apps evolve with your business—not against it.

Conclusion: The Outcome is What Counts

AI-powered low-code isn’t just a productivity hack—it’s a reset. When anyone can build sophisticated, scalable apps with the help of AI, innovation is reborn as a matter of intent and imagination. The barrier isn’t technical know-how; it’s your willingness to act.

With platforms like Emachinelabs, we’re not just making application development easier. We’re making it accessible, delightful, and—most importantly—outcome-focused. Because at the end of the day, it’s not the code that matters, but the impact it creates.

Ready to build the future without code? With AI and Emachinelabs, the only limit is your imagination.

Exploring the frontier where AI, business, and creativity converge. Connect with me for more on no-code, AI, and digital transformation.

Mocking web services for testing and fault injection

Tue, 21 Jul 2015 00:00:00 GMT

WebService Test Strategy

Web services are generally the core pillars of any software development in today's information technology world. More and more companies are modeling their offerings based on service oriented architecture (SOA). The application logic becomes more relevant to presentation only, leaving the heavy lifting of logic to be done via web services. Further there are different types of services including SOA, REST etc. which makes the mix a little more interesting.

While services becoming increasingly important, it's also making the app level testing a little bit more interesting. An app should be tested not only for the functionality but also for being able to handle different types of issues related to consumption of services. Testing app layer for functionality, performance, graceful degradation and disaster recovery are some of the very important aspects and need an intelligent solution around service mocking.

There are many ways the web service mock testing can be done. For example some team may use a request and whatever response is received, it can be saved along with code for further consumption for testing. Or the response can be saved in the form of xml serialized file. Further ways include using aspect based programming where the calls to actual service is routed to mock api which can construct the mock response and send it to the caller.

Here I will discuss a model that can help us achieve the following from test standpoint:

Provide mocking capability when actual service call is either not necessary or not available
Handle the service request calls intelligently for either mocking or rerouting to actual service calls
Inject the time delays in serving service responses based on requests
Inject timeouts, exceptions and error scenarios for service requests (meaning providing error for responses like error code 404/504 etc)
Scale with the usage of the test system across the board
In synch with most of the service layer changes
Be able to work as an abstraction layer for mock as well as actual service calls for more stability

Service test model

Lets assume that a new web service is being constructed. This proposal has three key components:

Mock service clients

Each service should provide a mock service client in addition to the actual service client. The actual service client will have http end point to the real service, say 'S1 Service'. The mock service client, say 'S1 Mock ServiceClient', will have http end point to a component called 'Test Server'. The mock end point will have few query parameters added to the request to denote which web-service it is intended to talk to and if the request should be served from mock/stored response repository or rerouted to original web-service.

Test Server

Test server is single entry point to cater to all service end points for mocking, testing and stabilizing purpose. It will be a test service which will be behind a load balancer to facilitate the scalability as and when needed. The test server serves two purposes. Based on the request type, it can either serve the response from its cache or reroute the call to actual service implementation. Mostly the implementation of test server will be a mix of custom code logic combined with rerouting software. Apache camel is a great example of rerouting part. The job of test server are three folds:

Validate the service request : The test server is designed to test application code while mocking/stability from web services. Hence this should always be used internally for any company and should not become end customer facing. In order to server internal traffic, every request made to this server should be validated. It can be checked for internal IP range, authenticity of the originating host. It can also be done via application level authentication tokens.
Service identification : This part analyzes the service request. This component is responsible to populate the required data model for test server with parameters of the web service request. The information includes the choice of service originator for a mock/cached response or routing to actual service implementation. It can also find if the originator needs any type of time delay in service response to test how efficiently application code handles the latencies and service outages. It can also inject different types of fault conditions while serving responses.
Serve Response : This component is responsible to provide the appropriate response based on the request. Serve response module gathers the information from test server data model for the request and then decides to either reroute the service call to original service or serve the response from its cache/storage.

Points to note about test server is that it can be used to test multiple type of scenarios. That includes mocking responses, introducing time delays in responses etc.

Response delivery

Responses to the web service calls are delivered via this system. Its responsibilities include analyzing the data model sent by test server and provide responses either by fetching cached/stored response for exact request matches or re-routing service requests to respective actual service end points. There are two main components for this system:

Cached Response : This module takes care of providing the response back to 'serve response' module from its cache. Based on the service endpoint and request parameters, it does following steps:
If it finds an exact match for the request in its cache/'service response storage', it fetches that response and send it back to the Serve Response module
If it does not find an exact match for the request, it makes a service call to actual service, stores the request parameters and response in cache/storage and send it back to serve response module
Periodically (configurable time interval like every midnight), it invalidates the cached/stored responses. It makes actual service calls and replaces the cached/stored responses with the latest received responses
If there is any problem while fetching the service response from actual service end point, it logs it and also sends the notifications
Service Response Storage (SRS): SRS is a storage or cache implementation for mocking actual service calls. It can be achieved by creating data model based on per service end points it mocks. Then further, every service endpoint based data model can store the responses based on service requests. All the service request parameters need to be stored in order to ensure that the exact matched request and responses. It needs to be fast as it should become bottleneck in serving responses. It should have very less latency.

Summery

I believe the testing model of mocking the web services should be based on real service calls itself. It should be able to provide most of the behaviors that can be expected (and unexpected one's as well!) from an actual service call. Keeping that in mind, I have tried coming up with this model. It serves the purpose of being able to mock the service calls by replacing them with in memory/cached/stored responses. It can also be used to inject fault conditions in response to the service calls and hence enabling us to test the app logic behavior in such cases. Finally it can also be used to completely replace the actual service calls, if needed and if latency is not an issue in testing domain, to achieve the service stabilities.

Please do let me know your comments and hopefully we can create a better model along the lines. And yes, in the process, will make our lives little bit easy while testing applications in different modes.

Disclaimer : I work for ebay Inc. The information in this post is compilation from my experiences in software industry and has no relation or recommendation from ebay Inc as such. ebay Inc will not be responsible for any information in this post. All the information in this post is only for educational purposes.

Software secure coding standards and analysis

Mon, 29 Jun 2015 00:00:00 GMT

A brief note

Security and secure testing of software components is a vast domain. I will be exploring many aspects of security and its related challenges in many posts. This post is targeted towards the Java based testing tools/processes and automation ideas. Similar tools/processes also exists for other languages including C/C++, Python, Ruby etc. Also, in this post, I am covering only the static analysis tools. I will be covering dynamic analysis tools in next post.

Importance of security testing

A paragraph from US Department of Homeland Security 2006 draft "Security in the Software Lifecycle" :

"Most critical difference between secure and insecure software lies in the nature of the processes and practices used to specify, design, and develop the software"

"Correcting potential vulnerabilities as early as possible in in software development lifecycle, mainly through the adoption of security-enhanced process and practices, is far more cost effective than the currently pervasive approach of developing and releasing frequent patches to operational software"

It has become ever more important to understand the security in context of software code and implications of any security breach. As mentioned above, fixing a security issue reactively can be significantly more costly than taking proactive steps. At times, fixing cost is not even a fraction of the actual business and revenue impact security breach can cause. While financial implications can be overcome over a shorter period of time, the trust and reputation of business are irreversible damage. It can take much longer to actually gain that trust back.

Following secure coding guidelines and using tools to analyze code for security issues can help software and applications be prepared for software security threats. While secure coding guidelines are important but it should be supplemented with code analysis tools as well. After all we are all human beings and do make mistakes. Automated tools, being run as part of software commits, testing or execution environment, are equally important and a must to have.

What to test for security

There has been a lot of discussion on present day hacks. Hackers try to penetrate the system with different ways. Some of the well known hacks are XSS (cross site scripting), DOS (denial of service attack), override wireframe, javascript manipulation etc. While this list can be really long, what is fundamental behind most of these security threats is software code that gives way to such incidents. To be fair, there are other such security problems in networks, app service configurations etc as well. But software code, by far, is most contributing factor in such security exploits.

Hence what-to-test list contains software code, network layers, ports, server configs and libraries used in application. Security testing could be really tricky at times. Fortunately we are not alone in this battle and there are a lot of tools/processes available to go through and use. Some of the resources for java technology based software are:

How to test software code

There are many aspects of testing software code. For example, the software code can be reviewed to meet the security guidelines and/or code can be analyzed with the help of static code analysis tools. The security testing can also be supplemented with run time testing of software code.

The approach should be three folds:

Use existing tools : we should try to use existing open source/licensed tools as much as possible. The list includes the code analysis tools for both static and dynamic nature.
Write tools : There is a good enough gap between what we have in open source tools in automation and what we need. There are a lot of literature and coding patterns, guidelines and rules. It would be great to contribute back to some open source tools (like find-sec-bug) and make them more robust. Once community start realizing their value, it will automatically get more attention and further contributions.
Build eco system : Writing/using tools alone will go some distance. It needs to be coupled with building eco system. For example it should be easy to run tools and get report in command line, IDE (like Eclipse, IntelliJ etc) and integration tools like Jenkins, Go pipeline etc.

Lets take a look at some of the available tools/processes to security test our software code:

Find-Sec-Bug

As the website of this plugin states, Find security bugs is a "Findbugs plugin for security audits of java applications". This plugin scans the code for a set of code patterns that can lead to a security vulnerability in the code. At present its got 63 bug patterns. This is very active project and well placed to succeed in becoming major force in security testing. Its very easy to configure and use. For example, if the builds are based on maven and continuous integration is achieved via Jenkins, here are the steps to configure it:

Add the following snippet of maven plugins under and section of your pom file

org.codehaus.mojo findbugs-maven-plugin ${findbugs.plugin.version} true low false Max false com.h3xstream.findsecbugs findsecbugs-plugin 1.4.0 verify check

Do maven build. As part of that findbugs will also be run
Configure Jenkins to show findbugs report
Findbugs report will have a new section called 'SECURITY'
Happy bug hunting!

Dependency check for libraries flagged for Common security vulnerability

NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics.

OWASP project has got some good plugins to make it easy to integrate dependency check with existing software code. The dependency-check tool helps analyze and identify if the software code depends on any already flagged vulnerable library. For example, if you have maven builds with Jenkins integration, here is how you can configure it:

Add the dependency-maven-check plugin to pom file under section

org.owasp dependency-check-maven 1.2.11 install aggregate

Do the maven build, as part of build, the dependency check will be run agains the project dependencies.
Reports can be generated in XML and HTML format. HTML report is very nice and easy to navigate
Use Jenkins plugin to show the vulnerable libs in dashboard
Make your code free of vulnerable libs!

OWASP ZAP for XSS

There are multiple ways to test cross site scripting. While there are some standard ways for checking if the website is secure from XSS, its never sufficient. There are always newer ways coming up breaching the security of our front end app codes being rendered with HTML, CSS and JavaScript. Best way to test for such security vulnerabilities is to have a good mix of manual testing, better code reviews, unit tests and automated UI tests.

OWASP provides a good tool ZAP (Zed Attach Proxy) for some of the standard XSS related issues like attach vectors, string, sql, script injection, path traversal among others. Its provides an easy to use UI and run some of the automated attach scenarios covering many aspects of XSS. It then further provides analysis and easy to grasp reports on those. The results are easy to under as it points the exact location of source HTML, alert flag associated with this and some description around.

Static Analysis tools

Some commonly used static analysis tools like Findbugs, PMD, checkstyle, Coverity, Klockworks etc readily do some of the code patterns search and flag them. These tools are well known and widely used tools. There are build plugins and integrations with systems like Jenkins. I will try to cover more on these in next blog. On how to configure checkstyle seamlessly, please follow the steps from my blog on checkstyle configuration.

Secure coding guidelines

There are many secure coding guidelines which are readily available on the web. It is very important for a code reviewer to keep in mind the security aspect while conducting code reviews. One should specially look out for the vulnerable library usage, DOS kind of use cases and issues like cross site request forgery and XSS. Some of the available coding guidelines are:

Oracle secure coding rules : 10 categories with 66 rules
SEI secure coding rules : 20 categories with 178 rules
- Also has 27 Android rules
OWASP ModSecurity code rules
OWASP SAMM (Software Assurance Maturity Model) is a great place to learn how to model software security in PDLC
Another good tool from OWASP is OWTF which helps in pentesting scenarios
A very good and comprehensive compilation on the security related categories and their details can be found on OWASP cheatsheet page
Find-Sec-Bug bug patterns

Fortify

While going through the secure coding guidelines, I found that Fortify static code analyzer is also a good tool. Fortify has lot of the security rules covered. It is not an open source tool and is a HP tool. There is a maven plugin available to run Fortify and there is also a Jenkins plugin.

OWASP projects

As it is evident from many references to OWASP projects in this post, OWASP is a great community for security testing of software code. There are many projects that can help bootstrap software code security testing. There is good amount of literature that helps while designing software systems and code review part.

Last words

Software code security is a common problem. There are many tools, docs and processes available today that can help perform this testing. Some of the tools can be used in automation while others are more manual in nature.

At present, there is a bigger need to contribute back to the society and help build open source tools and systems that can help perform such secure testing in automation. More folks get involved in automating rules from references like SEI, Oracle, OWASP cheatsheet etc, it becomes more fruitful for everyone.

Disclaimer : I work for ebay Inc. The information in this post is compilation from my experience from my own experiences in software industry and has no relation or recommendation from ebay Inc as such. All the information in this post is only for educational purposes.

Laxmikant Sharma

Agents Are Speedrunning the History of RPC

What 28 July changed

A2A, same wall, opposite direction

The prior art

gRPC declined on purpose

Deadlines, same story

The part that actually is harder

What I think the specs should do

While you wait

This site is home now

When Agents Hire Agents: PACT, the Missing Layer 4 of the Agentic Web

The stack has an OSI problem

PACT: Propose, Agree, Complete, Trust

Machine speed and recursion

Nothing here is invented, and that's the point

PACT has neighbors, and that's good news

The draft, and three predictions

References

The Agentic Web Is Being Wired Right Now: A Field Guide to MCP, A2A, Skills, and Agent Payments

How we got here in 24 months

Problem 1 — Reaching tools and data: MCP

Problem 2 — Talking to other agents: A2A

Problem 3 — Carrying know-how: Agent Skills

Problem 4 — Paying: AP2, ACP, and x402

The pattern underneath: .well-known is quietly becoming the spec

What this means if you're building

References

Can You Trust an Autonomous Agent? The Identity and Delegation Layer Behind MCP, A2A, and AP2

Layer 1 — Identity: who is this agent?

The Agent Card, up close

Layer 2 — Authorization: which flow gets the token?

Layer 3 — Delegation: on whose behalf, and how far?

Layer 4 — Accountability: can we prove it later?

How it composes

What's unsettled, and what to do

The Hardware-Accelerated Mesh: How DPUs and Ambient Topologies Killed the Data Center Tax

1. The Software Metamorphosis: Istio Ambient Mesh

2. Enter the DPU: The Third Pillar of Compute

3. Offloading the Mesh: Zero Trust at Line Rate

4. The Economic Reality: Power, TCO, and AI Inference

1. Massive Power Reductions:

2. Complete CPU Reclamation:

3. Turbocharging Agentic AI:

The Bottom Line

WebMCP: The HTTP of the Agentic AI Age

1. The Core Shift: The Browser as a Client-Side Server

2. Two Roads to Integration: Declarative vs. Imperative

The Declarative API: "Agent Optimization" (AO)

The Imperative API: Full Programmatic Control

3. Zero Trust Security: Inverting the Perimeter

4. Enterprise Architecture: Kubernetes, Service Mesh & Edge

The "Agent Mesh" (Istio Ambient Mode)

Authorization: Why RBAC Fails & The Need for ABAC

The Policy Check (Open Policy Agent / Cerbos style):

Immutable Auditing: The "PhysicalTask" Protocol

5. Strategic Takeaway: The "Dual-Layer" Web

The Invisible Revolution: How AI is Rewiring the Data Center Network

1. Redefining the "Transaction" at High Scale

2. The Evolution of the "Service Mesh" into Hardware

3. Security in a Direct-Memory-Access World

4. Dynamic Configuration via SONiC

The Bottom Line

The Enterprise AI Gap isn't Model IQ anymore. It’s Execution + Trust

What Frontier Signals (Beyond the Headline)

The Reality Check

The 8-Point "Zero Trust Agent" Blueprint

The Takeaway

AI Agents vs. Agentic AI vs. MCP Server–Based AI vs. A2A AI: Technical Angle

Technical Version

Clear boundaries

Minimal implementation details

Reference deployment topologies

Expanded technical use cases (with brief flows)

Design trade-offs and guardrails

Anti-patterns to avoid

Technical comparison table

How they correlate and stack together

Conceptual stack

Practical lifecycle

The pattern underneath: `.well-known` is quietly becoming the spec