Engineeringstepstone

Transaction Boundary Failures — and the infrastructure we need before agents are trusted with real-world actions A customer asks an AI agent to upgrade an account. The workflow looks harmless. First, charge the card. Then update the subscription ledger. Then provision the new entitlement. The agent calls the payment API. The payment provider charges $500. And then the connection times out. What happened? That sounds like a simple question. It isn't. The agent knows that it did not receive a successful response. It does not know that the charge failed. Those are two very different things. The payment may have failed before reaching the provider. The payment may still be processing. Or the payment may have completed perfectly and only the response was lost somewhere between the provider and the agent. Now imagine what happens when we put an LLM in the middle of this uncertainty. “The payment request timed out. I still need to complete the upgrade. Let me try again.” That sentence so...

Most wellness apps begin with a category: meditation, exercise, sleep, journaling, or habit tracking. We started from a different question: What are the small actions that help someone support their day as a whole? That question gradually became Vital by ShareCapsule , a mobile-first, installable wellness PWA built around breathing, movement, learning, recovery, connection, and reflection. The goal is not to build another app that asks people to achieve perfect scores or maintain endless streaks. The goal is much simpler: Make small positive actions easy to start, repeat, and understand. Vital is currently built as a local-first Progressive Web App. It does not require an account for the core experience, and the current product stores activity history, routines, settings, wellness check-ins, gratitude metadata, learning reflections, and sleep check-ins in the browser rather than sending them to a central cloud database. Why we built it this way Modern wellness products often become com...

AI agents can now be built surprisingly quickly. Connect an LLM to a few APIs, expose some tools through MCP, add a workflow, and within hours an agent can create tickets, modify cloud resources, update databases, send messages, provision infrastructure, or trigger business processes. That is exciting. But once agents start performing real-world actions, a much harder engineering problem appears: What happens when an agent completes steps 1 and 2, but step 3 fails? What if the network times out and we do not know whether an external API actually completed the operation? What if two instances of an agent attempt to recover the same workflow? What if an AI agent is authorized to inspect an environment but should not be allowed to modify production? What if a low-risk operation can run automatically, while a high-risk operation needs human approval? At that point, the problem is no longer primarily about prompting or LLMs. It becomes a problem involving: distributed systems transaction ma...

I built mcp-gate , a small Go reverse proxy for a problem I keep coming back to with LLM agents: How much authority should we actually give a model when it calls a tool? Repo: https://github.com/ananthaprakashb/mcp-gate A typical agent integration eventually ends up holding something powerful: an API key, service credential, OAuth token, or access to an MCP/tool server that can perform multiple operations. Even when the model is supposed to perform one very specific action, the credential it indirectly controls may authorize far more. I wanted the authorization boundary to look more like this: The model never receives the upstream API credential. Instead, the trusted orchestrator exchanges its gate credential for an ephemeral capability token authorizing one specific operation. For example: {   "route": "tickets",   "method": "POST",   "path": "/v1/tickets",   "ttl_seconds": 15 } The returned bearer token is HMAC-s...

Multi cloud architecture to enjoy benefit of different services and improve the availability is the trend. Especially financial institutions and global enterprises deploy workloads across public clouds (AWS, Azure, GCP) alongside legacy on-premises mainframes and private datacenters to balance scalability, vendor independence, and strict regulatory compliance. However, operating financial transactions across these disparate environments introduces critical architectural fragmentation and operational security gaps . Pretty hard to manage. The Core Problem: Architectural & Operational Friction When a financial transaction or data flow spans multiple cloud boundaries and on-prem systems, traditional perimeter-based security and monolithic orchestration engines break down.  Fragmented Identity & Authorization (IAM Silos): Each cloud provider and on-prem system maintains its own Identity and Access Management (IAM) framework, role definitions, and token formats (e.g., AWS IAM r...