Skip to content

Blog

Tutorials, comparisons, and deep dives on building production AI agents, MCP servers, and autonomous agent runtimes in Python with Promptise Foundry.

New here? Start with the Quick Start or read Why Promptise Foundry.

Add a Four-Eyes Approval Queue to Your MCP Server

Search add approval queue to MCP server and you'll find plenty on gating a tool, but almost nothing on the reviewer side — and the reviewer side is four separate chores: a pending store that holds a blocked call, admin endpoints a human can drive to release it, role-based access so only reviewers can touch those endpoints, and a separation-of-duties check so the person who made the call can't rubber-stamp their own request. This is the reviewer-side build — not "how do I gate a tool" (a gate that runs a policy or a webhook is covered elsewhere), but "how do I stand up an independent human queue that a different person drains." In Promptise Foundry it is one object: PendingApprover. This post shows the whole flow end to end, then covers the honest edges so you deploy it knowing exactly what it does and doesn't survive.

Which Agent Frameworks Actually Enforce Tool Approval?

Any useful agent framework tool approval comparison has to start with the question the feature checklists quietly skip: not does the framework support human-in-the-loop, but where does the approval check physically execute — and what happens the day a second client calls the same tool. Every major framework ticks the "supports HITL" box, and every one of them ships a real mechanism. They differ on one property that decides your architecture: the location of the enforcement point. This post maps that property precisely, framework by framework, and shows the row that sits somewhere structurally different — on the tool itself.

Can an AI agent have an identity without an IdP?

You can give an AI agent a real, traceable agent identity without an identity provider — no IdP, no new secrets, no infrastructure at all — and still answer "which agent did this?" within your own systems from the very first run. Most identity advice skips straight to the hard part: register the agent in Entra, mint short-lived JWTs, verify them with JWKS. That's the right destination for a fleet calling protected APIs, but it's a non-starter on an air-gapped network or in an early-stage prototype where there is no directory to register anything in yet. Promptise Foundry's AgentIdentity is deliberately two-tier: it starts as a local identity that costs nothing to stand up, already stamps attribution onto everything the agent does, and upgrades in place to a verifiable, IdP-backed credential the day you actually need one.

Agent Reasoning Patterns: The Complete Guide

Agent reasoning patterns are the different control flows an LLM follows to solve a task — a single tool-calling loop, a plan-then-act cycle, an adversarial debate, or a hand-built graph. Most guides quietly imply the opposite of what's true: they suggest that stacking more reasoning stages makes an agent smarter. On today's capable models it usually just adds latency and tokens. By the end of this guide you'll know what each of the built-in patterns actually does, when the extra stages earn their cost, and how to switch between them with a single argument.

When Agent Tool Loops Fail: Fixing Context Bloat

If your agent is stuck in a tool loop — calling the same lookup over and over, its answer never arriving, its token bill climbing every turn — you are hitting the single most common production failure on deep tool tasks. It is not a prompt-wording problem and it is not a model problem. It is context bloat: a naive tool-calling loop feeds the model its entire transcript on every turn, and once that transcript grows large enough, the model loses the thread and re-fetches facts it already has. By the end of this post you will know exactly why the loop degrades, how the context_scope lever bounds it, and how to flatten token growth with a one-argument switch.

Where Are Your Agent's Tokens Actually Going?

Agent token usage observability is the difference between guessing at your token bill and knowing, turn by turn, exactly where it goes. Most teams reach for a fix — a semantic cache, a facts ledger, tool selection — before they have a single number telling them which part of the agent is actually expensive. That's backwards. You can't cut what you can't see, and the tokens are almost never spread evenly: a couple of fat tool schemas and one or two long reasoning turns usually dominate, while your cache quietly misses more often than you think. This post shows how to attribute token usage across every LLM turn and every tool call with Promptise Foundry's built-in observability — no external tracing service, no code beyond one flag.

Which AI agent did this? Attribution for agent fleets

AI agent action attribution is the forensic question every autonomous fleet eventually has to answer: when a refund was issued, a record was deleted, or a customer's data was exported, which agent did it? If your fleet shares one API key and one model credential, the honest answer is "the model" — and "the model did it" is not a sentence a SOC 2 or ISO reviewer will accept as attribution. This post frames attribution as a forensics problem rather than a logging convenience, and shows the two properties a record needs to actually survive an incident: the acting agent stamped on every action, and a verified principal landing in a tamper-evident log.

AI Agent Audit Logging: Tamper-Evident by Design

AI agent audit logging is the difference between telling an auditor "trust us, the log says so" and handing them a record they can independently verify wasn't edited after the fact. When an autonomous agent calls a refund tool, a delete_user tool, or anything that moves money or data, you need a durable answer to "who called which tool, when, and with what outcome" — and you need that answer to survive an insider with write access to the log file. By the end of this post you'll know why plain JSON logs fail that test, what an HMAC-chained audit trail buys you, and how to turn one on in a single line with Promptise Foundry's AuditMiddleware.

  • in Runtime
  • 10 min read

Catch a Runaway AI Agent: Behavioral Anomaly Detection

AI agent behavioral anomaly detection is what tells you which way your agent has gone wrong — a poller frozen on get_status(id=42), a search → read cycle that never converges, an agent answering with empty strings, or one whose tool calls are half-failing — by watching the pattern of its calls instead of merely counting them. A runaway agent is not always expensive per call. The quiet failures cost you a whole night of the same cheap request, or a slow drip of trivial replies, while every infrastructure dashboard stays green because CPU and memory look fine. This post shows how the Promptise Foundry runtime catches those failures with four pure-pattern-matching detectors — no extra LLM calls — how to tell a behavioral stall apart from a context-bloat loop so you apply the right fix, and how the runtime pauses or escalates a live process the moment a detector trips.

One Audit Trail for SOC 2, HIPAA and the EU AI Act

An ai agent compliance audit trail is the one artifact three very different regulators end up asking for in the same shape: show us who did what, prove the record wasn't edited, and prove nothing went missing. A SOC 2 reviewer, a HIPAA auditor, and an EU AI Act conformity assessor read different rulebooks, but when your autonomous agents call tools that move money, touch patient data, or take consequential actions, all three converge on the same primitive — a record of every action, attributed to a verified principal, that survives an adversary with write access. This post shows how one HMAC-chained AuditMiddleware trail in Promptise Foundry produces evidence for all three, maps each regime's ask to concrete fields, and is honest about where the log ends and a governance program begins.

  • in Runtime
  • 7 min read

AI Agent Crash Recovery with Journals & Replay

AI agent crash recovery is the difference between a long-running agent that shrugs off an OOM kill and one that silently loses hours of accumulated state. A stateless LLM call is easy to retry; an autonomous process that has run 40 invocations, mutated its context, and fired triggers along the way is not. If that process dies and restarts from zero, it re-does completed work, double-fires side effects, and forgets what it learned. This post shows how Promptise Foundry solves that with an append-only journal plus a replay engine — and, just as importantly, where replay honestly cannot help.

  • in Runtime
  • 9 min read

Why AI Agents Double-Fire Actions After a Restart

If you have ever debugged ai agent duplicate actions after restart, you know the failure is never the crash itself — it is what the agent does when it comes back. A stateless retry loop restarts the process from zero, and the agent cheerfully re-runs work it already finished: re-charging a card it already charged, re-sending an email it already sent. The crash was survivable. The re-execution is the incident. This post is specifically about the exactly-once / idempotency failure mode — not general crash recovery — and how Promptise Foundry attacks it with two independent guards: a replay engine that reconstructs state from recorded results instead of re-running completed work, and an irreversible-action budget that caps destructive calls even if the first guard has a bug.

  • in Runtime
  • 7 min read

Fail an AI Agent Over to Another Node After a Crash

AI agent failover to another node is what you actually need when the machine running a long-lived agent dies mid-run — not a fresh agent that boots with an empty head, but the specific crashed process rebuilt where it left off, on a surviving box. Spinning up a replacement is easy. Reconstructing the process that had already scored 128 fraud alerts, advanced a queue cursor, and set its own pipeline_status = "degraded" — on a different machine, from durable evidence — is the hard part. This post shows how Promptise Foundry does that with a RuntimeCoordinator, static or registry discovery, and a shared journal, with no etcd or Consul in the picture. It also draws an honest line against the distributed runtimes other frameworks ship.

Which AI Agent Framework Has Built-In Governance?

If you are shopping for an AI agent framework with built-in governance — one where you can cap an agent at a cost ceiling, bound the number of irreversible actions it may take, and hold it to a mission it must actually make progress on — the honest state of the market is that most frameworks answer "write it yourself." They ship a limiter, and a limiter is a real, useful thing. But a single step counter is not a governance envelope, and the gap between the two is exactly where unattended agents get expensive or dangerous. This post maps what governance each popular framework really ships, credits the single-dimension caps some of them provide, and shows the four first-class subsystems Promptise Foundry puts in the box — budget, health, mission, and secrets — each with the same log/pause/stop/escalate enforcement path.

AI Agent Identity & Authentication: The Complete Guide

AI agent identity is the answer to a deceptively simple question: which agent did this? If you searched for "AI agent authentication" and landed on a page about storing your OpenAI key safely, you found the wrong thing — that secures the model call, not the actor. This guide separates the two clearly, explains why an autonomous agent is a new kind of non-human actor that needs its own identity, and shows you how to give one a traceable identity in a few lines of Python. By the end you'll know when a name-only identity is enough and when you need a signed, verifiable one your identity provider mints.

AI Agent Memory: The Complete Guide for Python Devs

AI agent memory is not one feature — it is a stack of four distinct layers, and most guides only ever cover one of them. They pick a vector database, wire up a search() call, and declare the problem solved. That leaves you with an agent that recalls old facts but re-reads your entire conversation on every turn, recomputes identical answers, and blows past the context window the moment history gets long. This guide maps the whole stack: short-term conversation history, long-term vector memory, the semantic cache, and context budgeting. For each layer you'll see exactly which problem it solves and the runnable Python that turns it on in Promptise Foundry.

Does Your AI Agent Phone Home? Telemetry & Data Egress

The phrase AI agent no data egress shows up on every sovereign and regulated procurement checklist, and it means something precise: the agent — and the framework wrapped around it — must not send data outside your network without your explicit say-so. Most teams read that as a statement about the model endpoint. It isn't only that. Long before you invoke an LLM, the framework you chose may already open outbound connections for "anonymous telemetry" or route your execution traces through a hosted service. To a security reviewer, both are egress you have to justify, whether the payload is anonymous or not. This post audits what agent frameworks send outbound by default, and shows how to keep full observability — every LLM turn, tool call, latency, and cache hit — on transporters that never leave your network.

Why AI Agent Traces Aren't an Audit Trail (or SOC 2 Proof)

The question of ai agent observability vs audit trail usually starts with a comforting assumption: the traces your stack already emits — LangSmith runs, Logfire spans, OpenTelemetry exports — will double as compliance evidence when an auditor asks what your agent did. They won't. Those traces are mutable debugging telemetry, and a vendor's SOC 2 badge attests to that vendor's controls, not to the integrity of the log your own agent produces. This post draws the exact line between the two, names precisely what today's observability tools do and don't guarantee, and shows the one primitive a span export can't give you: a record whose integrity you can verify on demand.

Catch an AI Agent Stuck Repeating the Same Tool Call

An AI agent stuck repeating tool call after identical tool call — say, get_status(id=42) on every single turn — burns its entire iteration budget without making a shred of progress, and most frameworks will not tell you it is happening until the budget is spent. This is one of the cheapest, most insidious ways an autonomous agent fails: it is not crashing, it is not erroring, it is confidently doing the exact same nothing over and over. By the end of this post you will know precisely why an iteration counter catches this late (or never), how a purpose-built stuck detector trips after N identical consecutive calls with zero extra LLM calls, and how to wire pause / stop / escalate around it in a few lines.

Build an AI Code Review Agent That Cuts False Positives

An ai code review agent is easy to stand up and hard to trust: point a model at a diff, ask for problems, and you get a wall of "consider using parameterized queries" that flags string concatenation in a comment as a SQL injection. The complaint every team has about LLM code review is noise. By the end of this post you'll have built a reviewer that challenges its own findings with an adversarial critique pass, forces a specific line reference behind every claim, and routes cheap triage and deep analysis to different models so the whole thing stays affordable.