PromptisePromptise
Why PromptiseUse casesRoadmapDocs
GitHubGet started
[n.01/02]> why promptise

Why people choose Promptise to build AI applications.

Most AI is still a chatbot. It waits for a message and answers it. Promptise is for AI that does real work. Build the agents. Open your product to other AI. Run it all in production.

The first tab is for the people who decide. The second is for the people who build. Every claim about another framework links to its source.

  1. 01Operations
  2. 02Trusted MCP
  3. 03Customers
  4. 04Control
  5. 05Accountability
  6. 06Learning
  7. 07Ownership
  8. 08One framework
01Operations

Agents that run your operations at 2 a.m.

A chatbot waits for someone to type. A Promptise agent starts on a cron schedule, a webhook, a new file or a message from another agent. It works inside your systems while your team sleeps. Long jobs get a goal and a check. The agent keeps working until the check passes.

For example

At 02:00 the agent reconciles yesterday's invoices. When a payment fails, a Stripe webhook wakes it to email the customer.

Without Promptise

Elsewhere this usually needs a paid platform such as LangSmith Deployment or CrewAI AMP. The other route is a separate workflow engine such as Temporal.

How it worksAgent Runtime →Missions →
anything can start itevery night 02:00stripe webhookgithub webhooknew fileeventanother agentagentalways ondoes the workreconcile invoicesemail the customeropen a ticketupdate the crm
02Trusted MCP

MCP servers you can put in front of customers.

Your customers are starting to work through AI agents. Those agents reach your product through MCP, the standard way AI calls software. Promptise builds MCP servers you can trust with that traffic. Every agent signs in with OAuth, a JWT or an API key. Each tool decides which roles and scopes may call it. Risky calls wait for a person. Every call lands in an audit log that shows any tampering. Already have an API? MCPcast turns your OpenAPI spec into a server like this.

For example

A SaaS company opens its product to its customers' agents. Each agent sees only its own account. Every delete asks a person first. A leaked key is switched off without a restart.

Without Promptise

Every framework here can call MCP servers. None of the six ships an SDK to build production ones. FastMCP is a strong standalone option for that.

How it worksAgent-ready platform →API to MCP →Guide: MCP server authentication →
auditapprovallimitsauthtoolagentaudit log, hash-chained
03Customers

Sell one agent to a thousand customers.

You build the agent once. Every customer gets their own memory, cache, tools and rate limits. Acme's data never reaches Globex. One deployment serves every account.

For example

A SaaS company adds an assistant to every workspace. A heavy customer hits its own rate limit. Everyone else keeps their speed.

Without Promptise

Per-user memory is common elsewhere. A cache separated per customer is not in the docs of the six frameworks we checked. Per-customer rate limits usually need a paid gateway.

How it worksMulti-tenancy →
one agentacmememorycachetokenglobexmemorycachetokeninitechmemorycachetokennothing crosses a wall
04Control

Your rules, enforced in code.

You decide what an agent may do alone. Three refunds per run. A daily spending cap. A delete that always needs a person. At the limit, the agent stops and asks. Each agent signs in with its own identity from Entra ID, AWS, Google Cloud or SPIFFE. You can switch off one agent and leave the others running.

For example

A billing agent issues three refunds in a run. The fourth waits for a person's approval.

Without Promptise

Limits on the number of calls are common. A limit on irreversible actions is not in the docs of the other six. Neither is a built-in loop detector.

How it worksSafety limits →Agent identity →
irreversible actions this runrefund 1refund 2refund 3refund 4limit 3 of 3pause + page on-callalso watched, without model callssame call repeatedno progresserror rate
05Accountability

Replay any decision your agent made.

A customer asks why the agent refunded them. You open that run. Every model call, tool call, token and cost is there. Passwords and keys are removed before anything is stored. The traces flow into the monitoring you already run through OpenTelemetry or Prometheus.

For example

Support answers the customer with the exact steps. Engineering finds the slow tool call in the same trace.

Without Promptise

Tracing elsewhere often runs through a hosted product such as LangSmith, Logfire or OpenAI's dashboard. Promptise keeps it on your servers.

How it worksObservability →
trace of one runrun: refund request1,912 tok · $0.004model: plan612 toktool: get_order120 msmodel: decide704 toktool: refundapprovedmodel: reply596 toksent tolive terminalhtml reportopentelemetryprometheus
06Learning

Agents that learn from their mistakes.

When a tool call fails, the agent records why. After a few failures it writes itself a lesson. It uses that lesson on the next run. A reviewer's reason for rejecting an action becomes a lesson too. Each customer's lessons stay with that customer.

For example

An agent books a room with the city name and fails. It learns that the tool wants a city code. The next booking works.

How it worksAdaptive strategy docs ↗Reasoning Engine →
same caller, later runrun 1book_room(city="zurich") errorlessonbook_room expects a city coderun 2book_room(city="ZRH") booked
07Ownership

Your servers. Your data. Your model.

Promptise is open source under Apache 2.0. It runs on your own infrastructure. There is no Promptise cloud in between. The agent works with OpenAI, Anthropic, Google, Azure, AWS Bedrock or a local model. Switching models is one line.

For example

A bank runs its agents on a local model inside its own network. No prompt leaves the building.

Without Promptise

In other frameworks, deployment and identity often sit in a paid platform. Examples are LangSmith and CrewAI AMP.

How it worksModels docs ↗License ↗
your serversagentsdatalogsaudit trailno promptise cloudany modelopenaianthropicgoogleazureaws bedrocklocal modelswitch with one line
08One framework

One framework instead of five.

Most teams glue together an agent framework, an MCP server SDK, a workflow engine, an identity layer and a tracing service. In Promptise they are one framework. Agents, MCP servers and clients, the runtime, identity and observability share one config. You upgrade one version.

For example

A new developer clones the project. One command starts the agent with its MCP servers and live traces.

How it worksProjects and CLI →
five tools to glueagent framework+mcp server sdk+workflow engine+identity broker+tracing serviceone promptise projectagentsmcp servers and clientsruntime and triggersagent identityobservability
  1. 01Agent Runtime
  2. 02API to MCP
  3. 03Agent-ready platform
  4. 04Multi-tenancy
  5. 05Missions
  6. 06Reasoning Engine
  7. 07Safety limits
  8. 08Agent identity
  9. 09Observability
  10. 10Prompts as code
  11. 11Projects and CLI
01Agent Runtime

Agents that start on their own.

Most agents wait for a chat message. A Promptise agent starts when something happens. That can be a schedule, a webhook from Stripe or GitHub, a new file, an event or another agent. It works inside your operations day and night.

In practice

Every night the agent reconciles yesterday's invoices. When a payment fails, Stripe wakes it to email the customer. When a contract arrives, it flags the risky clauses.

Elsewhere · In other frameworks, agents that start on their own usually need a paid platform. Examples are LangSmith Deployment and CrewAI AMP. The other option is a separate workflow engine such as Temporal. Sources

Agent Runtime docs ↗Guide: event-driven agents →Guide: scheduled agent with alerts →Guide: webhook triggers →
anything can start itevery night 02:00stripe webhookgithub webhooknew fileeventanother agentagentalways ondoes the workreconcile invoicesemail the customeropen a ticketupdate the crm
02API to MCP

Turn your API into an MCP server.

Point MCPcast at your OpenAPI spec. It builds a small set of tools that an agent can use well. Risky calls need a person's approval. Tests come with it.

In practice

A company's internal API has 300 endpoints. Its agents get a handful of clear tools instead. Every delete asks a person first.

Elsewhere · Google ADK and LangChain can also turn a spec into tools. FastMCP can generate servers from OpenAPI. The review step, the tests and the readiness score are what MCPcast adds. Sources

MCPcast →Guide: OpenAPI to MCP →Guide: agent-ready SaaS →
openapi spec300 endpointsreviewtoolstested · deletes behind approval
03Agent-ready platform

Make your platform ready for AI agents.

AI agents need a way into your product. Promptise builds it as an MCP server. MCP is the standard interface AI agents use. Sign-in, permissions per tool, approvals and an audit trail come with it. The audit log is HMAC-chained, so any edit shows. A test client checks every tool before you ship. Your own agents and your customers' agents can then use your platform safely.

In practice

A SaaS company opens its product to its customers' AI agents. Each agent signs in and sees only its own account. Every action is recorded.

Elsewhere · Every framework here can call MCP servers. None of the six ships an SDK to build production ones. FastMCP is a strong standalone option for that. Sources

MCP server docs ↗Guide: make your SaaS agent-ready →Guide: production MCP server →Guide: MCP server authentication →
auditapprovallimitsauthtoolagentaudit log, hash-chained
04Multi-tenancy

Serve every customer with one agent.

Each customer gets their own memory, data, permissions and limits. One customer never sees another's data. You can sell one agent to hundreds of companies.

In practice

A SaaS company adds an assistant to every customer workspace. Acme's files and answers never reach Globex.

Elsewhere · Per-user memory is common in other frameworks. A cache separated per customer is not documented in them. Neither are per-customer rate limits outside paid gateways. Sources

Multi-tenancy docs ↗Guide: multi-tenant agent →Guide: memory isolation →
one agentacmememorycachetokenglobexmemorycachetokeninitechmemorycachetokennothing crosses a wall
05Missions

Give your agent a goal.

Some work takes days. You give the agent the result you want and a way to check it. It keeps working until the check passes.

In practice

A migration of 200 tables runs for several days. It finishes when every table passes validation.

Elsewhere · The other frameworks have parts of this. They work within a single run. Sources

Mission docs ↗Guide: goal-driven missions →
goal: all 200 tables pass validationday 138 / 200day 281 / 200day 3127 / 200day 4176 / 200day 5200 / 200runjudge check
06Reasoning Engine

Design how your agent thinks.

Most agents think in one fixed loop. Promptise lets you design the thinking itself. Your agent can plan before it acts. It can check its own work. It can justify every answer.

In practice

A claims agent plans each case. It checks every figure against the policy. A person signs off on the decision.

Elsewhere · Graph engines and ready-made patterns are common. LangGraph is built around one. Microsoft Agent Framework, Pydantic AI, Google ADK and CrewAI have them too. Promptise gives you reasoning steps as building blocks. The agent can choose its own path through them. Sources

Reasoning Engine docs ↗Guide: agent reasoning patterns →Guide: the ReAct pattern →
planthinkactreflectvalidatecritiqueanswerpath the agent choseallowed, not needed this time
07Safety limits

Set limits your agent can't cross.

You decide what the agent may do alone. For example, three refunds per run or a daily spending cap. At the limit, it stops and asks a person.

In practice

A billing agent issues up to three refunds per run. The fourth refund waits for a person.

Elsewhere · Limits on the number of calls are common. A limit on irreversible actions is not documented in the other six. Neither is a built-in loop detector. Sources

Budget docs ↗Guide: irreversible actions →Guide: kill switch →
irreversible actions this runrefund 1refund 2refund 3refund 4limit 3 of 3pause + page on-callalso watched, without model callssame call repeatedno progresserror rate
08Agent identity

Give every agent its own identity.

Each agent signs in through your existing identity provider. It gets only the access it needs. You can switch off one agent without touching the others.

In practice

A bank switches off one misbehaving agent in its directory. The other agents keep working.

Elsewhere · Google ADK uses Google service accounts and OAuth. Identity features in CrewAI AMP and LangSmith are paid. SPIFFE is not documented in the other six. Sources

Identity docs ↗Guide: SPIFFE agent identity →Guide: agent identity →
your identity providerentra · aws · gcp · oidc · spiffesupportown identitybillingrevokedreportsown identityopsown identityrevoke one agent, not a shared key
09Observability

See everything your agent did.

Turn it on with one setting. Every run, model call, tool call, token and cost is recorded. You can watch it live in the terminal or open a report. You can also send it to your own monitoring through OpenTelemetry or Prometheus. Passwords and keys are removed before anything is stored.

In practice

A customer asks why the agent refunded them. Support opens that run. They see each step, each tool call and what it cost.

Elsewhere · Other frameworks offer tracing too, often through a hosted product such as LangSmith, Logfire or OpenAI's tracing dashboard. Promptise records it on your own servers and sends it to the tools you already use.

Observability docs ↗Guide: trace tool calls →Guide: observability tools compared →
trace of one runrun: refund request1,912 tok · $0.004model: plan612 toktool: get_order120 msmodel: decide704 toktool: refundapprovedmodel: reply596 toksent tolive terminalhtml reportopentelemetryprometheus
10Prompts as code

Write prompts like code.

Your prompts decide how the agent behaves. In Promptise you build them from shared parts. You test them before they ship. You can roll back a bad change in seconds.

In practice

Fifty support prompts share one refund rule. Legal changes the rule once. The tests show that every prompt still works.

Elsewhere · Prompt templates exist in other frameworks. LangChain's are the closest. Most others offer instruction templates, not a full prompt module. Sources

Prompt Engineering docs ↗Guide: prompts as interfaces →Guide: system vs user prompts →
blocksrolecontextrulesoutput schema@promptsupport_replyguardstestsregistryv1v2v3
11Projects and CLI

Run your agent as a real project.

An agent is software. In Promptise it lives in one project folder with its prompts and tools. You watch every step and its cost while you build. The same project runs in production.

In practice

A new developer clones the repo. One command starts the agent. They see every tool call and what it costs.

Elsewhere · LangGraph, CrewAI and Google ADK have project CLIs too. ADK and LangGraph Studio also have browser dev UIs. The OpenAI Agents SDK has none. Promptise covers the agent, its MCP servers, dev tools and production in one CLI. Sources

Projects docs ↗CLI reference ↗Guide: run, debug and deploy →
my-agent/promptise.tomlagents/prompts/servers/.envpromptise$ init --projectscaffold$ run --devtoolstraces, tokens, cost$ run --tuiterminal UI$ run --prodjson logs, preflight$ servemcp server over http
[n.02/02]> how the frameworks compare

Checked against each framework's own docs.

Each mark links to its source. We read every source on 2026-10-23. "Not in the docs" means we searched the docs and the code and found nothing. It does not mean it can't be built.

Built in, open sourcePartly$Paid platform onlyThrough another product–Not in the docs we searched
CapabilityPromptiseLangGraphCrewAIOpenAI Agents SDKMicrosoft Agent FrameworkPydantic AIGoogle ADK
Supervised agent processes, restart policies, graceful stopbuilt in: AgentRuntime/AgentProcess with lifecycle states, restart_policy (on_failure/always), max_consecutive_failures, drain_timeout graceful stop; distributed coordinator/nodes.$platform paid: LangSmith Deployment Agent Server runs graphs as background runs on queue workers (N_JOBS_PER_WORKER), with Redis heartbeats, a sweeper that requeues runs from crashed workers every 2 min, and SIGINT graceful shutdown…$platform paid: CrewAI AMP 'Automations' hosts deployed crews/flows as always-on endpoints (deploy from GitHub/ZIP, Online/Failed status, redeploy, auto-deploy on push, `crewai deploy create/push/status/logs`). The OSS package runs…via integration: The SDK has no supervised process runtime of its own: Runner.run/run_streamed are in-process calls. Long-running, auto-recovering agents are documented through the Temporal (temporalio.contrib.openai_agents), Dapr…partial: No built-in agent supervisor with start/stop/restart policies or graceful drain. Long-running work is covered by: the first-party Durable Extension (Microsoft.Agents.AI.DurableTask / agent-framework-durabletask; durable…via integration: The docs say 'there is no Pydantic-hosted agent runtime': an agent is a Python object you deploy as your own web service, worker or function. Long-running, supervised execution comes from durable engines' workers, all…partial: No built-in agent supervisor with restart policies or graceful drain. 'adk api_server' / 'adk web' run a ready-made FastAPI server (get_fast_api_app), and ambient agents can run as background services behind trigger…
Built-in triggers: cron, signed webhooks, file watch, eventsbuilt in: Cron, webhook (HMAC-SHA256 signature schemes generic, GitHub, Stripe; Telegram secret token; IP allow-list), file watch, EventBus event and MessageBroker message triggers.$platform paid: Cron jobs: Agent Server crons API (client.crons.create / create_for_thread, UTC schedules); Managed Deep Agents define_schedule (cron + timezone, beta). Inbound webhook: Managed Deep Agents HTTP channels (channels.http…$platform paid: CrewAI AMP triggers: Gmail, Google Calendar, Google Drive, Outlook, OneDrive, Microsoft Teams, Slack, HubSpot, Salesforce, Zapier; schedule-started executions (`schedule` source); kickoff via deployment API/webhooks;…–not documented: The SDK has no cron, webhook, file-watch or inbox triggers. The only webhook in its docs is the Realtime SIP flow: OpenAI sends realtime.call.incoming to your own service, which then attaches a RealtimeRunner. The…via integration: The Durable Extension docs list Azure Functions triggers (queues, webhooks, timers) for event-driven durable agents. In the OSS framework itself: the alpha agent-framework-hosting-telegram package receives Telegram…via integration: No built-in trigger subsystem. Documented routes: GitHub Agentic Workflows (gh-aw) with the pydantic-ai engine in Harness, triggered by issues, PRs or a schedule; DBOS cron and queues; Prefect deployments and…partial: Built-in trigger endpoints (Python 1.29+): 'adk api_server --trigger_sources pubsub,eventarc' exposes /apps/{app}/trigger/pubsub and /trigger/eventarc, with automatic session per event, a concurrency semaphore…
Turn an OpenAPI spec into an MCP server, with review and testsbuilt in: MCPcast: OpenAPI spec -> classified, curated, reviewed plan -> generated MCP server with tests; `--eval` produces an Agent Readiness Score from golden tasks (the eval itself calls a model).partial: OpenAPIToolkit / create_openapi_agent in langchain-community (and OpenApiToolkit in @langchain/classic for JS) turns an OpenAPI spec into generic HTTP requester tools plus a JSON spec explorer. These are agent tools,…–not documented: No OpenAPI-to-MCP or OpenAPI-to-toolset generator found in OSS docs, crewai-tools list or AMP docs.–not documented: No OpenAPI-to-MCP or OpenAPI-to-toolset generator.$platform paid: OpenAPI tools run on the service side through Microsoft Foundry Agent Service (.NET FoundryAITool.CreateOpenApiTool / OpenApiTool, sample Agent_Step17_OpenAPITools). The OSS framework has no OpenAPI-to-toolset or…–not documented: No OpenAPI-to-MCP or OpenAPI-to-toolset generator.built in: OpenAPIToolset turns an OpenAPI 3.x spec (JSON or YAML) into RestApiTool tools with auth support. It produces an ADK toolset, not an MCP server, and has no spec review, testing or readiness scoring. Related:…
SDK for production MCP servers (auth, approvals, audit, jobs)built in: MCP server SDK: JWT/OAuth/API-key auth + token endpoint, routers/middleware, approval gates (elicitation), HMAC-chained audit log + verifier, rate limits, caching (memory/Redis), circuit breaker, background job queue,…partial: There is no first-party SDK for building MCP servers. Agent Server (LangSmith Deployment, platform) exposes each deployed agent as an MCP tool at /mcp (Streamable HTTP), with custom auth middleware for user-scoped…$platform paid: No OSS SDK for building MCP servers. CrewAI AMP can 'Export as MCP' a deployed automation (exposes the crew as an MCP server); no documented server-side auth/middleware/approval/audit SDK.–not documented: The SDK only consumes MCP servers. Its docs do not cover building, authenticating or hosting MCP servers; you would use the separate MCP Python SDK.partial: An agent can be exposed as an MCP server (agent.as_mcp_server(), sample agent_as_mcp_server.py), and the alpha agent-framework-hosting-mcp offers AgentMCPTool, mcp_to_run and mcp_from_run to put agents or workflows on…via integration: Pydantic AI does not ship its own MCP server SDK. Its docs show using agents inside tools of a server built with the MCP Python SDK or FastMCP (separate projects), and MCP sampling to route a server's LLM calls back…partial: to_mcp_server(agent) wraps a whole agent as an MCP server in one line (stdio app.run()). Single ADK tools can be exposed by hand-building a server on the MCP SDK with adk_to_mcp_tool_type. No MCP-server SDK with auth,…
Semantic cache isolated per user and tenantbuilt in: SemanticCache with per-scope partitions (scope_key e.g. user:<id>, tenant-aware), local or OpenAI embeddings, in-memory/Redis backends.via integration: Semantic LLM response caches come as integration packages set through langchain_core set_llm_cache, e.g. AzureCosmosDBNoSqlSemanticCache (langchain-azure) and Redis/Mongo-style caches. Per-user or per-tenant…partial: Only an exact-match tool-result cache (Agent/Crew `cache=True`, custom `cache_function` per tool). No semantic/embedding response cache and nothing per-user/tenant; provider prompt-token caching is reported in usage…–not documented: No semantic or embedding response cache. The caching it does have is provider prompt caching (prompt_cache_key, prompt_cache_retention/options in ModelSettings) and MCP cache_tools_list.–not documented: No semantic or embedding response cache was found in core or in the integration packages.–not documented: No semantic or embedding response cache. The Caching capability turns on provider prompt caching, and MCPToolset.cache_tools caches tool lists.via integration: Semantic LLM-response caching comes through the third-party adk-redis package (RedisVLCacheProvider self-hosted, or LangCacheProvider on managed Redis LangCache), wired as before and after model callbacks with…
Per-user and per-tenant rate limitsbuilt in: Server side: MCP server RateLimitMiddleware token buckets per client and per tenant (custom key_func). Agent side, per-process budgets (C1d).$platform paid: LangSmith LLM Gateway (beta) has rate-limit policies (requests or tokens per rolling window, scoped to user/workspace/API key, 429 + Retry-After) and spend policies (402). OSS has only InMemoryRateLimiter on chat…partial: `max_rpm` on Agent and Crew throttles requests per minute (crew value overrides agents), but it is global per agent/crew, not per user/tenant. Docs show per-tool rate limiting with a tool hook. Per-tenant quotas only…–not documented: No per-user or per-tenant rate limits. The only rate-limit handling is retrying provider 429 responses through ModelRetrySettings policies.partial: No built-in per-user or per-tenant rate limiter. The docs show rate limiting as custom agent, chat or function middleware that raises MiddlewareTermination, and a retry sample uses tenacity. The MCP client applies a…partial: Harness SpendLimits sets windowed USD and token budgets per tenant (scope=lambda ctx: ctx.deps.tenant_id). Agent max_concurrency and ConcurrencyLimitedModel cap concurrency within one process; the docs note this is…partial: No per-user or per-tenant rate limiter. Trigger endpoints have a global concurrency semaphore and retry with backoff. The docs point to Apigee (Google Cloud) for traffic and token limiting, and to DBOS or Temporal…
Missions with success criteria across runsbuilt in: MissionTracker: objective + success_criteria evaluated across runs with evidence; open mode (ExecutionMode.OPEN) meta-tools let an agent edit instructions, create tools, connect MCP servers, manage triggers and…partial: What exists: deepagents RubricMiddleware (beta), which judges output against a rubric and loops until satisfied or max_iterations. It works within one run, not across runs. Async subagents (deepagents>=0.7.26 beta) let…–not documented: Agents have a `goal` and tasks an `expected_output` + guardrails, but no mission object with success criteria evaluated across runs. Hierarchical manager delegates only to pre-defined agents; Flows can construct crews…partial: Experimental 'Hosted multi-agent' beta: a GPT-5.6 root model creates and coordinates server-hosted subagents at runtime over the Responses WebSocket transport, while your function tools run locally. Agent.as_tool and…partial: AgentLoopMiddleware.with_judge re-runs an agent until a judge chat client decides the request is answered (a success criterion within one run, with a progress or feedback log and max_iterations). The experimental…partial: Agents can spawn and manage other agents at runtime: Harness SubAgents (named child agents), DynamicWorkflow (the model writes one script that fans out, chains or votes across sub-agents, capped by max_agent_calls) and…partial: LoopAgent repeats sub-agents until one escalates (exit_loop tool) or max_iterations is reached. ADK 2.0 dynamic workflows schedule nodes at runtime (loops, branching, recursion), collaborative workflows use a…
Ready-made reasoning patterns and stepsbuilt in: Prebuilt react, peoatr, research, autonomous, deliberate, debate, pipeline, verify, managed, code-action graphs.built in: create_agent (ReAct tool loop). create_deep_agent (planning to-do list, filesystem, subagents, summarization), with deep-research and data-analysis examples. RubricMiddleware does reflection/verify loops.…built in: Sequential and hierarchical processes (auto manager agent or custom `manager_agent`), crew `planning=True` (AgentPlanner), agent `reasoning=True` (reflect-and-plan, `max_reasoning_attempts`), plan-execute pattern…partial: Patterns ship as runnable example scripts, not library classes: examples/agent_patterns (deterministic chain, routing, parallelization, llm_as_a_judge, agents_as_tools, guardrails, human_in_the_loop) plus research_bot…built in: Prebuilt orchestrations in agent-framework-orchestrations / .NET: Sequential, Concurrent, Handoff, Group Chat and Magentic (Magentic-One planner and manager). The harness adds plan and execute agent modes, todo…built in: Prebuilt patterns ship as Harness capabilities: Planning (model-owned task plan), Researcher (search, fetch, sub-researcher), Coder, Advisor (consult a stronger model mid-run), DynamicWorkflow (fan-out/chain/vote),…built in: SequentialAgent, ParallelAgent and LoopAgent. Documented patterns: coordinator/dispatcher, sequential pipeline, parallel fan-out/gather, hierarchical decomposition, generator-critic and iterative refinement. Planners:…
Run budgets incl. irreversible actions, with pause or stopbuilt in: Budget per run and per day: max_tool_calls_per_run, max_cost_per_day (cost units), max_irreversible_per_run (tools annotated irreversible), inject_remaining, on_exceeded pause/stop/escalate; counters survive restarts.built in: ModelCallLimitMiddleware (thread_limit/run_limit, exit_behavior end|error) and ToolCallLimitMiddleware (global or per tool_name, thread/run limits, exit_behavior continue|error|end), plus graph recursion_limit and…partial: OSS enforces per-agent `max_iter` (default 20, then forces final answer), `max_execution_time` (seconds), `max_rpm` throttling and `max_retry_limit`; usage_metrics track tokens. No built-in max-tool-call, token or cost…partial: Built in: max_turns (MaxTurnsExceeded, catchable through error_handlers={'max_turns': ...}), ModelSettings.max_tokens per call, per-tool timeouts, and Usage tracking (tokens, per request, in RunState and hooks) that you…partial: Function-invocation limits are enforced: FunctionInvocationConfiguration max_iterations (default 40 model round-trips), max_function_calls (cumulative tool executions per request, best-effort), max_duration_seconds…built in: UsageLimits enforces per-run cost_limit (USD), request_limit (default 50), tool_calls_limit, input/output/total_tokens_limit and per_request_input_tokens_limit. Harness SpendLimits adds day/month/per-tenant USD and…partial: RunConfig.max_llm_calls caps model calls per run (default 500), LoopAgent has max_iterations, ReflectAndRetryToolPlugin has max_retries, and the Model Consult tool has per-turn and per-session max_uses budgets. No token…
Loop and stuck-agent detection at runtimebuilt in: HealthMonitor detects stuck (same call repeated), loops (repeating sequences), empty responses and high error rates without model calls; cooldown; escalation.$platform paid: LangSmith Alerts (error rate, latency, feedback, cost spikes), Insights (automatic clustering of failure modes; Plus/Enterprise), and LangSmith Engine (detects recurring issues from production traces, diagnoses them,…partial: OSS: detects an agent repeating a tool call with the same input (`task_repeated_usage` prompt) and caps loops via `max_iter`; event bus + tracing. AMP Agent Control Plane (Beta) adds fleet health with…–not documented: No detector for loops, stuck agents or repeated errors. The nearest feature is Agent.reset_tool_choice (on by default), which resets tool_choice after a tool call to avoid infinite tool loops. Tracing records runs but…partial: max_consecutive_errors_per_request stops the tool loop after repeated errors, and the iteration and duration caps stop runaway loops. OpenTelemetry tracing and metrics ship built in. No loop, stuck-agent or anomaly…partial: Harness TrajectoryJudge has a second model review the live trajectory every N requests and steer it (drift and instruction fade). WarnOnCacheBusts detects prompt-cache prefix collapses, and Logfire shows prompt-cache…partial: ReflectAndRetryToolPlugin tracks repeated tool failures (per invocation or global) and retries with reflection up to a limit. The Reflect and Retry Model plugin re-asks after malformed responses. ADK 2.0 adds…
Per-user tokens to tools; agent identity from your IdPbuilt in: CallerContext.bearer_token forwarded per caller on an isolated MCP session (forward_caller_token opt-out); AgentIdentity with providers for Entra, AWS, GCP, OIDC and SPIFFE.$platform paid: LangSmith Agent Auth (beta, langchain-auth) manages OAuth 2.0 credentials per user/principal. Managed Deep Agents identity + connections, and Fleet agent identity (fixed vs per-user credentials), are also platform.…$platform paid: CrewAI AMP: `user_bearer_token` scopes integration OAuth to the end user; Secrets Manager with AWS/GCP/Azure Workload Identity Federation (OIDC, short-lived tokens); Vertex AI via workload identity; Custom MCP Servers…partial: Local MCP servers take static headers or an httpx Auth. tool_meta_resolver injects per-call MCP _meta from run context (for example tenant_id). HostedMCPTool connectors take an access token ('authorization'). No…built in: Local MCP tools take a header_provider that receives the per-run function_invocation_kwargs and adds credentials only to same-origin requests, so user tokens can be forwarded per run (.NET sample…built in: MCPToolset per-user authentication: pass a function as auth (or headers) that reads the caller's token from RunContext deps at each run start. Each run gets its own MCP session, so users never share one. auth='oauth'…built in: Tool auth framework: AuthScheme and AuthCredential (API key, HTTP bearer, OAuth2 with interactive user-consent flow, OpenID Connect, service account / ADC, ID token), with credential requests surfaced to the client and…
Prompts as code: templates, composition, guards, observersbuilt in: promptise.prompts: blocks, builder, templates/loader, chains, ConversationFlow phases, guards (content filter, schema strict, length, validators), PromptObserver, inspector, suite/registry.built in: langchain_core prompts: ChatPromptTemplate, MessagesPlaceholder, partials and composition. @dynamic_prompt middleware builds system prompts from state/context at runtime. Deep Agents harness profiles override prompts…partial: Agent `system_template`/`prompt_template`/`response_template`, custom `prompt_file` overriding built-in prompt slices (i18n), `{placeholder}` interpolation, Agent Skills (SKILL.md, progressive disclosure), LLM call…partial: Agent.prompt references OpenAI-platform stored prompt templates by id, version and variables (Responses API only). Instructions can be dynamic callables. agents.extensions.handoff_prompt provides a recommended handoff…partial: Agent Skills (SKILL.md progressive disclosure with resources and scripts; file-based and code-defined skills; customizable instruction_template), context providers that inject instructions per run, MCP prompts as…partial: Core: static and dynamic instructions (functions taking RunContext), append-on-change instructions, ReinjectSystemPrompt, and agent-spec template strings compiled and validated against deps. Harness: SystemReminders…partial: Instruction templating with {state_key}, {artifact.name} and optional {var?}, InstructionProvider callables, static_instruction (cacheable), GlobalInstructionPlugin, McpInstructionProvider, Skills, and prompt…
Project file and runner CLI (dev tools, terminal UI, serve)built in: `promptise run` package.json-like projects ([scripts], [env], [dev], [prod], [serve], [pricing]) with --devtools, --tui, --watch, --serve, --prod; scaffold_project.built in: langgraph.json manifest (graphs, dependencies, env, auth, store/checkpointer TTL, webhooks, http middleware) plus the langgraph CLI (MIT): `langgraph new` (templates), `dev` (hot-reload local server with Studio),…built in: `crewai create crew|flow|tool|skill|template`, `crewai install`, `crewai run` (detects crew.jsonc; run TUI incl. declarative/conversational flows), `crewai chat`, `crewai test/train/eval`, template management. No local…–not documented: No project manifest, runner CLI, serve command, dev UI or init templates. The only interactive helper is the run_demo_loop REPL, and the examples ship a run_examples.py script.partial: The 'devui <dir>' CLI discovers agents and workflows in a directory and serves them with a web UI, hot reload, tracing and auth flags. No project manifest, run/serve runner or init/scaffolding command in the OSS…partial: Exists: the clai runner CLI (clai -a module:agent, --mcp-config), the CLAI 2.0 TUI (git worktrees, settings), and the clai web / to_web() dev chat UI. Also UI adapters (AG-UI, Vercel AI) to serve from any ASGI app, and…built in: The adk CLI: 'adk create' (scaffolding), 'adk run' (terminal), 'adk web' (Dev UI and Visual Builder), 'adk api_server', 'adk eval', 'adk test', 'adk conformance', 'adk optimize', and 'adk deploy…
Checkpoints with crash recovery and replaybuilt in: Journal backends (memory, file) with redaction; ReplayEngine crash recovery; rewind with plan + journaled rewind (CLI `promptise runtime rewind`).built in: A core LangGraph strength. Checkpointers (InMemorySaver, SqliteSaver, PostgresSaver; checkpoint-postgres 3.2.0) save every superstep plus per-task pending writes, so a crashed run resumes from the last checkpoint…built in: CheckpointConfig on Crew/Flow/Agent: event-driven checkpoints (JsonProvider or SqliteProvider), resume via `kickoff(from_checkpoint=...)`, `Crew.fork()` branches with lineage tracking, `crewai checkpoint` TUI to…via integration: Journaled crash recovery and replay come through the Temporal, DBOS, Restate and Dapr integrations. Built in: RunState (result.to_state(), to_json/from_json) is a serializable resume checkpoint used for approvals, and…built in: Workflow checkpointing: WorkflowCheckpoint, CheckpointStorage, InMemoryCheckpointStorage and FileCheckpointStorage (Python), checkpoint stores in .NET. Runs resume from any saved checkpoint (RestoreCheckpointAsync /…built in: Durable execution journals model requests and tool calls and replays them after a crash, on 8 engines. Core ships TemporalDurability, DBOSDurability and PrefectDurability. Harness ships AWSLambdaDurability,…built in: Sessions persist an append-only event log (DatabaseSessionService, SqliteSessionService; VertexAiSessionService is platform). ResumabilityConfig(is_resumable=True) on App resumes interrupted workflows from logged events…
Human approval of tool callsbuilt in: ApprovalPolicy with callback/webhook handlers (signed webhooks), AutoApprovalClassifier, plus server-side approval gates.built in: A core strength. LangGraph interrupt() / Command(resume=...) pauses any node durably via the checkpointer. HumanInTheLoopMiddleware(interrupt_on={tool: {allowed_decisions: [approve, edit, reject, respond]}}) gates tool…built in: Tool-call hooks expose `ctx.request_human_input()` for approval gates and block via `HookAborted`/`return False`; Task `human_input=True`; Flow `@human_feedback` decorator (pause, route on approve/reject, async…built in: needs_approval (bool or async callable) works on function_tool, Agent.as_tool, ShellTool and ApplyPatchTool. Local MCP servers use require_approval, HostedMCPTool uses require_approval plus on_approval_request. Pending…built in: Tool approval with @tool(approval_mode='always_require') (Python) or ApprovalRequiredAIFunction (.NET) emits approval requests that the caller answers. MCP tools take approval_mode. The harness adds standing approvals…built in: Deferred tools: requires_approval=True or raise ApprovalRequired ends the run with DeferredToolRequests. Resume later with deferred_tool_results built from approvals, with nothing held in memory while waiting.…built in: Tool Confirmation (experimental): FunctionTool(require_confirmation=True or a callable) or tool_context.request_confirmation() for structured answers. The run pauses and resumes on the user's reply. ADK 2.0 graph…
Built-in evaluation frameworkpartial: No general agent-eval framework found. Exists: MCPcast --eval (golden tasks -> Agent Readiness Score), MissionTracker evaluations, PromptTestCase for prompts.built in: OSS AgentEvals (trajectory match, LLM-as-judge trajectory evaluators) and OpenEvals (MIT, langchain-ai). LangSmith (platform) adds datasets, experiments, online evaluators, annotation queues, pytest/vitest integrations,…built in: `crewai test -n N -m model` scores tasks 1-10 with an evaluator LLM; `crewai eval` (1.15.x, gate/exit code, `--models` comparison with per-run cost/time; evaluates the last traced run through AMP, so login needed);…$platform paid: The SDK has no eval framework; its docs point to OpenAI Evals. Agent evals run on the OpenAI platform: trace grading over SDK traces, datasets, graders, eval runs and the prompt optimizer. Separately, openai-guardrails…built in: Evaluation APIs (experimental) in agent-framework-core: LocalEvaluator with check functions, evaluate_agent and evaluate_workflow. Foundry evaluators (FoundryEvals, evaluate_traces) are a platform_paid add-on through…built in: pydantic-evals offers Dataset/Case and evaluators: built-in, LLMJudge, custom, span-based, agentic/trajectory, report evaluators and standard quality metrics. Datasets serialize to YAML/JSON. Also supports concurrency,…built in: 'adk eval', pytest AgentEvaluator and Dev UI eval: test files and evalsets with criteria (tool_trajectory_avg_score, response_match_score, final_response_match_v2, rubric-based quality, hallucination and safety), custom…
Handoffs and the A2A protocolpartial: Cross-agent delegation (cross_agent) and distributed runtime; no A2A protocol support found in source (grep a2a).built in: Subagents-as-tools (SubAgentMiddleware, create_deep_agent subagents, CompiledSubAgent), handoffs via Command, router and supervisor patterns, langgraph-swarm, async remote subagents over Agent Protocol, AG-UI and ACP…built in: `allow_delegation` (Delegate work / Ask question tools), hierarchical manager agent, Flows orchestrating multiple crews, and A2A: `A2AClientConfig` to delegate to remote agents and `A2AServerConfig` to expose agents as…built in: Supports handoffs (handoff(), input_filter, nest_handoff_history beta), Agent.as_tool (structured input, streaming, needs_approval, conditional is_enabled) and the experimental hosted multi-agent beta. A2A protocol is…built in: Agent-as-tool (agent.as_tool()), handoff, group chat and Magentic orchestrations, workflows exposed as agents, and the A2A protocol both ways: A2AAgent client (agent-framework-a2a) and A2A hosting (hosting-a2a, .NET…built in: Agent delegation (an agent called from a tool, with shared usage and deps), programmatic hand-off, Harness SubAgents and DynamicWorkflow, and pydantic-graph. The A2A protocol is via the separate fasta2a package…built in: sub_agents with LLM-driven transfer_to_agent, AgentTool (agent-as-tool), ADK 2.0 collaborative workflows, and A2A: RemoteA2aAgent to consume and to_a2a() / 'adk api_server --a2a' to expose, plus an A2A extension and…

Hover a mark for the note, click it for the source. Versions checked: LangGraph 1.2, CrewAI 1.15, OpenAI Agents SDK 0.24, Microsoft Agent Framework 1.23, Pydantic AI 2.60, Google ADK 2.12.

Build your first agent that does real work.

Get startedSee it work end to end
Promptise - AI Framework LogoPromptise

The foundation layer for agentic intelligence. Build, secure and operate autonomous AI systems with Promptise Foundry.

pip install promptise

[01] Foundry

  • MCPcast
  • The Promptise Agent
  • Reasoning Engine
  • MCP
  • Agent Runtime
  • Prompt Engineering
  • Execution Engine
  • Agent Identity

[02] Resources

  • Documentation
  • GitHub
  • Guides
  • Learning Paths
  • Questions

[03] Company

  • About
  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Subprocessors

© 2026 Promptise by Manser Ventures. All rights reserved.

Open source · Python