Foundry

Website  ·  Docs  ·  Quick start  ·  How it works  ·  Examples  ·  Discussions

The framework for agentic intelligence.

Promptise gives you everything an agentic system needs, in one place and working together from the first line: agents that think, safe ways for them to act in your systems, and a harness that keeps them running and accountable. You decide what your agent should do; Promptise takes care of everything around it.

Start with one agent on your laptop and grow it into a fleet running real work, with the same framework and the same way of building all the way through. No rewrite in between, and nothing to stitch together yourself.

pip install promptise
export OPENAI_API_KEY=sk-...

import asyncio
from promptise import build_agent, tool


@tool
def order_status(order_id: str) -> dict:
    """Look up the status of an order."""
    return {"order_id": order_id, "status": "shipped", "eta": "Friday"}


async def main():
    agent = await build_agent(
        model="openai:gpt-5-mini",
        instructions="You are a helpful support assistant.",
        extra_tools=[order_status],
        observe=True,  # traces every step, token and cost
    )
    result = await agent.ainvoke(
        {"messages": [{"role": "user", "content": "Where is order A-1001?"}]}
    )
    print(result["messages"][-1].content)
    await agent.shutdown()


asyncio.run(main())

Any Python function with @tool becomes a tool; its type hints are the schema. To give the agent the tools of an MCP server, add it to servers; the agent discovers its tools by itself:

from promptise.config import HTTPServerSpec

agent = await build_agent(
    model="openai:gpt-5-mini",
    servers={"tools": HTTPServerSpec(url="http://localhost:8000/mcp")},
)

To start a full project instead, run promptise init --project my-bot.

Any model, one string. openai:gpt-5-mini · anthropic:claude-sonnet-4-5 · azure:chat-prod · gemini:gemini-2.5-pro · bedrock:… · ollama:llama3.1. The same string works in build_agent(), .superagent files and every CLI command, and promptise models check <string> tells you exactly what a provider still needs. → Model setup

promptise.toml is to an agent project what package.json is to a Node project: it names the main file, the scripts and the environment the project needs. promptise run runs your program like python main.py; with dev tools, the terminal UI or the HTTP API it also instruments every agent the program builds, with no code changes.

promptise init --project my-bot   # promptise.toml, agent.py, main.py, .env.example
promptise run                     # run main.py with the project's environment
promptise run --devtools          # live traces, tool calls, tokens and cost
promptise run --tui               # the full terminal UI
promptise run --serve             # an HTTP API for your agent
promptise run --prod              # JSON logs, preflight checks, graceful SIGTERM

[scripts] work like npm scripts (promptise run dev), and --watch restarts on every save. → Projects & promptise run

A customer writes in at three in the morning. The runtime wakes the agent, its identity is established, the input is checked, it gathers context, plans, calls a tool through MCP, a person approves the refund, it checks its own work, answers, and every step lands in the audit trail.

Walk through all fourteen steps, with every module linked →

promptise mcpcast openapi.yaml --profile standard --auth env-token

MCPcast reads an OpenAPI or Swagger document and writes a real, reviewed MCP server: a small set of tools an agent can actually use, chosen and described for agents. Reads by default; writes only when you ask, and every one of them approval-gated on the server, so a person signs off before anything changes, whichever MCP client calls it.

What comes out is a project, not a script: an installable package, a launcher, a generated test suite, pyproject.toml, a Dockerfile and a README, all regenerated from mcpcast.plan.yaml, the one file you edit. --eval grades the result A to F with a real agent before you ship, and plain promptise mcpcast opens a guided setup in the terminal. Above: the real output for the Swagger Petstore spec. → MCPcast, end to end

For people and teams who need their agentic systems to be accountable: who did what, on whose behalf, within which limits. These are part of the framework, not something you add later.

• Multi-tenant, by construction. Tag a request with a tenant, and every place data lives — memory, cache, conversations, rate limits, audit — stays separated per tenant. Two tenants who both have a user named alice can never see each other's data. It's a structural rule, not a filter you have to remember on every query. → Multi-Tenant Platform guide

• Human approval, enforced on the server. Mark a tool as needing sign-off and the approval is required no matter which app calls it — including one you didn't write. Denies on timeout, rejects self-approval, records who approved what. → Approval Gates

• A real identity for each agent. Agents authenticate as themselves to the APIs they call, backed by Microsoft Entra ID, AWS, Google Cloud, SPIFFE, or plain OIDC — so you can retire the shared API key, and every action traces to the person it acted for, even across agents calling agents. → Agent Identity

• Audit you can hand to a reviewer. Every action is written to a tamper-evident chain, tied to the tenant and the user. Delete one user's cached answers, memories and recorded events with purge_user() when they ask. → Auth & Security

• Runs offline. The security models, embeddings, and vector store can all run locally — so the whole stack works air-gapped, for on-premises and regulated environments where data can't leave. → Guardrails · Model Setup