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

To add an approval queue to an MCP server, gating the tool is only half the job. 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. The question here is not "how do I gate a tool" 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 its limits 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.

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 security reviewer will accept as attribution. Treat attribution as a forensics problem rather than a logging convenience. This post 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.

  • 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 — 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, including 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.

Does Your AI Agent Phone Home? Telemetry & Data Egress

The phrase AI agent no data egress shows up on every sovereign and air-gapped 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.

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.

Air-Gapped Agent Deployment Checklist for Regulated Teams

This air-gapped agent deployment checklist is written for the teams who cannot hand-wave the offline story: banks, hospitals, insurers, and government programs shipping an agent into a network with no route to the public internet. A general production checklist tells you to add auth, rate limits, and health checks — all necessary, none of which prove that nothing leaves the perimeter. The offline dimension is its own discipline: every model staged on-box, every guardrail running on-device, code execution locked to no network, memory kept local and injection-scanned, and every sensitive action captured in a tamper-evident chain your security team can verify. This is the pre-production list that closes the gap a standard checklist skips.

Air-Gapped AI Agent Framework: The On-Prem Guide

Choosing an air-gapped agent framework is not the same as choosing a framework that can talk to a local model — and that distinction is exactly where most on-prem projects stall. Swapping a hosted LLM for Ollama is the easy 20%. The hard 80% is every other layer of a modern agent: the embedding model behind your vector memory, the moderation call that scores toxic output, the injection classifier guarding your input, the code sandbox your agent executes in, and the telemetry exporter shipping traces somewhere for debugging. Each one is a potential outbound connection, and in an isolated network a single one breaks the whole system — or worse, quietly passes a security review it should have failed. This guide covers the whole picture: it maps every layer of an agent to a local implementation, shows the exact configuration that keeps each layer on-box, and is clear about what a truly fully offline agent stack requires versus what "supports local models" actually buys you.

Why AI Agent Frameworks Fail in Air-Gapped Networks

Building an air-gapped AI agent looks deceptively simple: swap the hosted LLM for a local one, unplug the network cable, done. Then the first request fails — not because the model is missing, but because the embedding call, the moderation endpoint, or the tracing exporter tried to reach a host that no longer exists. Teams learn the hard way that "model-agnostic" is not the same as "offline-capable." The model is only one of five layers in a modern agent, and the other four usually assume an internet connection you don't have. This post maps the hidden cloud dependencies that break inside an isolated network, and shows which layers have to be local before you can honestly say you run an AI agent fully offline.

AutoGen vs Promptise Foundry: Multi-Agent, Honestly

If you're weighing AutoGen vs Promptise for a multi-agent system, the honest answer starts with what each tool was actually built for. Microsoft's AutoGen is a research-first library for conversational agents that talk to each other in a loop — brilliant for exploring ideas in a notebook. Promptise Foundry treats each agent as a governed HTTP service with authentication, audit, and tenancy. By the end of this post you'll know which model fits your problem, and you'll have seen real code for wiring agent-to-agent calls in Promptise.

  • in Runtime
  • 7 min read

Governing Autonomous Agents: Budget & Health

Autonomous agent governance is the set of controls that answer the one question every tech lead asks before an agent runs unattended in production: what stops it from looping forever, calling an expensive API 4,000 times, or issuing a refund at 3am with nobody watching? A build_agent() call gives you a capable request-response agent, but the moment you let it run on a trigger with no human in the loop, "capable" is not enough — you need an envelope it cannot exceed. By the end of this post you will know the concrete controls Promptise Foundry ships for that envelope, and how to wrap your own agent in a budget plus a health policy with a real hard stop.

Build Your First AI Agent with Promptise in 10 Minutes

You can build an AI agent with Promptise in about ten minutes, starting from an empty file and ending with a tool-using agent you can chat with from your terminal. No orchestration boilerplate, no schema wiring, no abstractions to learn before you write the first useful line. This Promptise tutorial walks through every step — install, one API key, a first agent, real tools, and launching it from the CLI — and everything here is copy-pasteable. By the end you'll have a running agent and know exactly which parameter to flip when you're ready for production.

An MCP Approval Gate That Refuses to Ship Ungated

A build-time enforced approval gate MCP servers can't quietly skip is the difference between an approval you declared and an approval that actually fires — and that gap is where most human-in-the-loop wiring silently fails. The usual argument for server-side approval is that client-side prompts are bypassable; that case is already made, and it is not this post. The sharper question is the one that bites teams six months into production: you marked a tool as needing sign-off, so why did it run unattended anyway? Almost always because the approval lived somewhere that could be forgotten — a branch in the driver code, a flag on a task, a node you meant to add — and nothing failed when it wasn't there. This is about the three enforcement invariants that make a declared approval mechanically un-skippable.

Give a Code-Interpreter Agent Your Tools, Keep Approval Gates

Building a code interpreter agent with approval gates means letting the model write and run one program over your tools while every mutating call it makes still stops at a human — and gets counted against a hard per-run budget. That combination is the whole point of this guide. The code-interpreter (codeact) pattern itself is easy; the interesting engineering is the governance you refuse to give up when you hand a model an execution surface. This post covers exactly that: enable agent_pattern="code-action", wrap the tools that change state with an approval gate, keep a hard max_tool_calls cap on the generated program, and pick the gVisor backend when the input is untrusted.

  • in MCP
  • 9 min read

How to Compose Multiple MCP Servers Into One Gateway

To compose multiple MCP servers into one gateway, you mount each team's server behind a namespace prefix so an agent connects to a single endpoint and discovers one clean toolbelt — pay_charge, usr_get_user, rpt_revenue — instead of juggling three URLs, three auth handshakes, and three tool lists it has to deduplicate itself. That much is table stakes; several frameworks can prefix-and-merge. The part that actually decides whether a gateway survives contact with production is what happens at the seam: can you filter what each client sees across the composed surface based on who is asking, and can two mounted servers ship different versions of the same tool without a name collision?

Add Budget + Health Kill-Switches to a Runtime Agent

To configure AI agent budget and health kill-switches you should not need a monitoring side-project, a supervisor loop, or a scatter of try/except blocks around every tool call — you need one config block on the process. This is the copy-paste recipe, not the why-you-need-it explainer: paste one ProcessConfig (or one .agent YAML manifest), fill in your per-run and daily limits, your irreversible-action cap, the four behavioral-health detectors, pick pause / stop / escalate, point a webhook at Slack, and ship a governed, self-limiting agent in a single file. The runtime enforces the whole declaration for you, around every invocation, out-of-band. Below is the exact block.

How to Build a Customer Support AI Agent, Step by Step

A production customer support ai agent is not a single-turn question-and-answer bot with a vector store bolted on. Real support is a conversation that changes shape as it goes — you greet, you figure out what's actually wrong, you look up the order, and only then do you resolve or escalate. Most tutorials ship the easy 20% (retrieve an article, paste it into a prompt) and skip the parts that break in production: behavior that shifts across turns, a reply that gets validated before it sends, escalation rules, and history that survives a restart. By the end of this guide you'll have built all of those with Promptise Foundry, and you'll be able to run the whole thing with your own OPENAI_API_KEY.

How to Cut Token Cost for a Multi-Tenant AI Agent

To cut token cost, multi-tenant AI agent deployments have to fight three inefficiencies at once — a leaky shared cache, unbounded tool-loop transcripts, and the full set of tool schemas resent on every call — because one agent serving many customers multiplies each of them per tenant. A waste that is annoying for a single-user demo becomes the dominant line on your bill when a thousand tenants hit the same code path. This post connects the three cost levers Promptise Foundry ships as first-class, composable primitives on one build_agent() call — a per-tenant semantic cache, a context_scope="ledger" transcript, and optimize_tools — and then shows you how to prove the savings with built-in observability rather than trust a marketing number.