Skip to content

2026

Single-Agent vs Multi-Agent: When to Actually Split

The single agent vs multi-agent decision gets made too early and for the wrong reasons — usually a diagram in a slide deck rather than a signal in your workload. Splitting one agent into several feels like progress, but it buys you a coordination layer, extra token overhead, and a new class of failures before it buys you any capability. This guide gives you the concrete signals that actually justify a split, the cost governance you should put in place first, and runnable code for adding delegation to Promptise Foundry only when the signals fire.

Smolagents CodeAgent vs Promptise: Where Do Tool Calls Run?

The smolagents codeagent vs promptise code-action question is not "who lets the model write one program over your tools" — both frameworks do, and both do it well. It is a narrower, more consequential question: when that program calls issue_refund() or delete_customer(), where does that call execute, and what governs it? This is a precise-delta piece, not a "they have nothing" one. By the end you will know exactly what smolagents' CodeAgent does today, where Promptise's bridge draws a different line, and how a sandboxed program can still trip your approval gate and a hard call cap.

How to Prove What Your AI Agent Did for a SOC 2 Audit

A soc 2 audit trail for ai agents is the artifact you reach for the moment a reviewer stops asking about your policies and asks the pointed question: "for this refund your agent issued, show me who was allowed to call that tool, who actually called it, and prove the record wasn't edited after the fact." Pointing at your LLM provider's SOC 2 badge doesn't answer it — that badge attests to their controls, not to evidence of your agent's actions. This post is the step-by-step setup: capability-based per-tool guards so only the right agent can take a sensitive action, AuditMiddleware(signed=True) with a managed PROMPTISE_AUDIT_SECRET so every attempt becomes an attributable, tamper-evident record, PII kept out by default, and a verify_chain() report an auditor will accept.

How to Deploy a Sovereign AI Agent for EU Data Residency

When a European bank, hospital group, or public-sector team specifies a sovereign AI agent EU data residency deployment, they mean something exact and non-negotiable: every byte the agent touches — prompts, retrieved context, tool arguments, generated code — must stay on infrastructure inside the region, on components you operate, with no packet crossing to a US-hosted API. That is harder than pointing your model string at a European endpoint, because an agent framework has more channels to the internet than the model call. This post walks through a deployment where inference, embeddings, the vector store, the safety guardrails, and code execution are all bound to local, no-egress components — and, critically, where that binding lives in one declarative .superagent file an auditor can read top to bottom instead of trusting five separate integrations.

Give an AI agent a SPIFFE SVID identity in Kubernetes

A SPIFFE SVID identity for AI agents is the cleanest way to authenticate an autonomous agent inside a service mesh you already run: if your platform uses SPIRE, every workload already receives a short-lived, cryptographic SVID from the Workload API, yet no mainstream agent framework consumes one to prove which agent is acting. This how-to closes that gap. You will wire AgentIdentity.from_spiffe into build_agent, let SPIRE mint a per-audience JWT-SVID for each MCP server the agent calls, and verify those tokens server-side with JwksAuth against your trust domain — with automatic SVID rotation and not one static secret in code or env.

SPIFFE vs Entra vs AWS IAM: pick an agent identity provider

Choosing between SPIFFE vs Entra vs AWS IAM for AI agents is not really a question of which identity provider is best in the abstract — it is a question of which one your platform already issues workload identities from, because that is the one you can back an agent with today. If you have already decided your agents deserve their own verifiable identity instead of a shared key (the case the workload-identity hub makes), this is the follow-up decision: pick the provider. This post is a bake-off across the five Promptise supports — SPIFFE/SPIRE, Microsoft Entra, AWS IAM, Google Cloud, and generic OIDC — compared on the three things that actually differ between them: how the token is acquired, how you revoke it, and when each one fits.

How to Stop a Runaway AI Agent (Runtime Kill Switches)

To reliably stop a runaway AI agent you need a kill switch that acts on the process, not a counter that raises an exception inside one function call. That distinction is the whole game. Almost every framework hands you a per-run cap — max_iterations, recursion_limit, a usage limit — and calls it a safety control. But those caps raise an exception inside a single ainvoke(), and an exception only exists if there is a caller sitting there to catch it. The moment your agent is running unattended on a cron, a webhook, or a file trigger, there is no such caller: each trigger fires a fresh invocation, the counter resets to zero, and nothing halts the thing that is actually misbehaving. This post reframes the runaway agent kill switch as runtime enforcement — budget, behavioral-health, and mission breaches that become out-of-band pause/stop/escalate actions on a supervised AgentProcess — and shows you how to wire one in a few lines.

Where Does tenant_id Come From? JWT Claim vs API Key

Every multi-tenant tutorial hands you a tenant_id and moves on, but the honest question is where that value comes from — and the two answers Promptise Foundry supports are a tenant_id from jwt claim and a tenant bound to each API key. Get that sourcing step right and the rest of your isolation story (tenant-qualified rate limits, per-tenant audit, cache scoping) follows for free. Get it wrong — a claim you forgot to read, a number where you expected a string, a request with no tenant at all — and a claim-less caller slips through as tenant-less, which is the one outcome a multi-customer platform can never afford.

Tenant-Scoped Audit Logs for AI Agent Tool Calls

A tenant-scoped audit log for an AI agent's tool calls exists to answer two questions a compliance auditor puts to you in the same breath: show me every action your system took for Acme, and prove that record wasn't edited after the fact. Both are easy to wave at and hard to actually satisfy. A general trace store can usually show you something about Acme, but "every action" means the tenant has to be a field you can filter on cleanly — not a tag one call site set and another forgot. And "prove it wasn't edited" means the trail needs integrity you can hand to a third party, not your assurance that the database looks fine. This post is about the per-tenant forensics angle specifically: how to produce a slice of the trail that belongs to exactly one customer, and hand it over with a proof it wasn't altered.

  • in MCP
  • 6 min read

How to Test MCP Servers Without a Live Server

Testing MCP servers usually means starting a process, waiting for it to bind a port, and firing HTTP or stdio requests at it from a separate test runner. That works, but it is slow, it is flaky in CI, and it turns a two-line assertion into a fixture that manages subprocesses and sockets. This post shows the alternative: run the complete request pipeline — validation, dependency injection, guards, middleware, and your handler — entirely in-process with Promptise Foundry's TestClient, so your tests stay as fast and deterministic as plain function calls. By the end you will be able to test tools, guards, middleware, and error handling without ever opening a network connection.

  • in Runtime
  • 10 min read

Time-Travel Debug an AI Agent by Rewinding State

To time-travel debug an AI agent, you rewind its recorded history to the exact step before it did something baffling, rebuild the state it was actually looking at, and replay its decisions deterministically — instead of squinting at stdout and guessing. When a request/response function misbehaves you set a breakpoint and re-run it. An autonomous agent gives you neither luxury: it woke itself on a trigger you didn't watch, called an LLM whose output you can't reproduce, mutated its own state across dozens of invocations, and fired a side effect you now have to explain. This post shows how a Promptise journal plus its rewind and replay engines turn "why did it do that?" into a reproducible postmortem, and where that differs — honestly — from LangGraph's graph-state time-travel.

Tool Calling in Python: Connect an LLM to Tools

Tool calling in Python is the mechanism that turns a language model from a text generator into something that can actually do things — look up an order, query a database, call an internal API. The concept is simple, but the standard tutorials bury you in JSON Schema boilerplate: for every function you want to expose, you hand-write a schema describing its name, parameters, and types, and keep that schema in sync with the code forever. By the end of this post you'll understand exactly how tool calling works under the hood, and you'll see the shortcut most guides skip — pointing your agent at an MCP server so tools appear auto-discovered, with schemas derived straight from your Python type hints.

Why trim_messages Drops Facts Your Agent Still Needs

Put trim_messages vs a facts ledger side by side on a deep tool loop and the difference stops being academic: trimming evicts messages by token or message count, so it can throw away the exact record the model still needs three turns later — while a ledger keeps that fact and drops the duplicates instead. When a tool-calling agent balloons in the middle of a long task, the reflex is to reach for one of two stock helpers: trim the message history, or summarize it. Both bound the transcript. Both also have a failure mode that only shows up on the tasks that matter most — the deep ones. This post compares those helpers head-to-head with Promptise Foundry's context_scope="ledger", a last-value-wins facts ledger that deduplicates repeated tool calls and cache-serves a repeat instead of re-running it, with no extra model call.

Zero-trust: verify the calling agent, not its name

In a zero-trust agent mesh you must verify the calling agent server-side — cryptographically, on the resource that receives the call — because a self-asserted agent name in a request body is trivial to forge. Agent A tells your billing server "I am billing-bot"; your server believes it; a compromised or misconfigured Agent B says exactly the same thing. If the only thing standing between a caller and issue_refund is a string it chose for itself, you have no security boundary at all — you have a naming convention.

  • in Runtime
  • 9 min read

Verify Webhook Signatures Before Waking Your Agent

The code that runs when a webhook hits your service has one deceptively small job: verify webhook signature ai agent triggers before you let them wake anything, because an unauthenticated POST is an open door straight into an autonomous process. This post is not the tour of reactive triggers — that lives in the triggers overview. It is about the one mechanism that decides whether the request is real: HMAC-SHA256 over the raw body, read from X-Webhook-Signature, compared in constant time, and rejected before the agent is ever invoked. Get that check right and the rest of your pipeline inherits a trustworthy entry point. Get it wrong and everything downstream is running on forged input.

  • in MCP
  • 8 min read

Why a Small MCP Tool Change Broke Every Connected Agent

To version MCP tools without breaking clients, you have to treat a tool's schema as a published API contract — because that is exactly what every connected agent already assumes it is. An agent does not read your source code. It reads the input_schema your server advertises, builds a function call to match, and trusts that the shape it saw at discovery time is the shape you will accept at call time. Rename one field from customer to customer_id, tighten filters from optional to required, or drop a property some prompt still references, and every agent already in flight starts emitting arguments your handler rejects. Nothing crashed on your side. You just changed the contract out from under callers who never agreed to the new terms.

  • in Runtime
  • 9 min read

Build a Crash-Safe Watched-Folder Ingestion Agent

A watched folder ingestion agent watches a drop folder, wakes the instant a file lands, and runs an LLM over it — extract, classify, route, emit. This is not a tour of the runtime's trigger types; that overview lives in the Triggers guide. It is one end-to-end build. We wire a FileWatchTrigger to a supervised AgentProcess, and then solve the three things a naive watcher gets wrong the moment it meets production: reprocessing after a crash, an unbounded bill when a thousand files land at once, and losing everything the agent learned between drops. The watch itself is the easy part. The durable, restart-safe pipeline around it is the point.

  • in MCP
  • 6 min read

What Is MCP? Model Context Protocol Explained

If you have ever asked what is MCP and come away with a spec diagram but no running code, this post is the fix. The Model Context Protocol (MCP) is an open standard for connecting language models to tools, data, and prompts in one uniform way — so a tool you build once can be called by any MCP-compatible agent. By the end of this article you will understand the protocol's moving parts and see an agent auto-discover and call a real tool in under ten lines of Python, with zero manual wiring.

Who Approved That AI Refund? Reviewer Attribution

When compliance asks who approved this ai agent action — the $5,000 refund your agent issued to order A-1 at 3 a.m. — the honest answer is often a shrug, a Slack screenshot, and a log line that says the call succeeded. That is not reviewer attribution; that is a story. This post is scoped narrowly to one thing: the provenance of an approval decision. Not whether the audit log is tamper-evident (that question is settled elsewhere), but what actually lands on it when a human signs off, and whether that record can survive an auditor who does not trust your good intentions.

What Is Workload Identity for AI Agents?

Workload identity for AI agents is the practice of giving every agent a stable, verifiable identity of its own — minted by the identity provider you already run — instead of handing the whole fleet one shared API key. If you deploy more than one agent, you have probably already felt the gap: your logs say "the model" did something, your audit trail can't name which agent hit which tool, and every agent holds the same credential so every agent has the same blast radius. By the end of this post you will know exactly what workload identity means for agents, why it is the same problem enterprises solved for services years ago, and how to give your first agent a real identity with no new secrets to manage.