Promptise Foundry
A Python framework that unifies agents, MCP tools, and governed runtime operations.
Per-dimension scores and reasoning
Evidence shows the framework claims to provide security features (guardrails, approvals, audit logs, multi-tenancy), but static review cannot verify implementation. Deductions: no actual code or config examples to prove these features work; dependency security only mentions using pip audit, no vulnerability scan results; external effects (tool calls) lack clear permission control details; rollback mechanism only mentioned in docs, no implementation details; source attribution only via license and author info, publisher identity not verified.
Descriptions in README and pyproject.toml are mostly consistent, but some inconsistencies (e.g., README claims 100% async, but no evidence). Deductions: dependency availability not verified, no lock file or dependency resolution strategy; failure messages only mention error handling, no concrete examples.
README clearly identifies target users (developers) and scenarios (building production agents), and offers multiple model and deployment options. Deductions: capability boundaries vague, not clear which features are experimental; trigger precision (cron, webhook) only mentioned in docs, no config examples; environment fit (offline) mentioned but no detailed config.
Information architecture clear, README has detailed TOC and doc links; install notes simple (pip install); naming stable (promptise); examples and FAQ links provided; known limitations not explicitly listed; license Apache-2.0; versioning and changelog not provided in repo; maintenance responsibility not clear.
Output usability high, README provides quickstart example; marginal value high, framework integrates many features; cost-benefit not assessed, no performance or resource consumption data.
Claims in README (security features, multi-tenancy) lack code or test evidence; cross-source corroboration insufficient, only README and pyproject.toml; facts and inferences not clearly separated.
- Static review cannot verify actual implementation of security features (guardrails, approvals); dynamic testing required.
- Dependency security only mentions using pip audit, no actual vulnerability scan results; check dependency versions.
- Publisher identity not verified; assess supply chain risks carefully.
- Performance claims in README (e.g., 100% async) lack supporting evidence.
What does this agent do, and when should you use it?
Promptise Foundry is a Python-oriented full-stack framework for agent construction, reasoning graphs, MCP servers, long-running runtime operations, identity, and prompt engineering. Its asynchronous build_agent() entry point can connect to tool servers and optionally enable memory, guardrails, semantic caching, and observability. Agents receive messages through ainvoke() and return results, while the MCP Server SDK exposes type-annotated Python functions as tools. The runtime is presented for schedule, webhook, and file-change triggers, with journaling, recovery, budget controls, and human approvals. The README also states support for OpenAI, Anthropic, Gemini, Ollama, and LangChain BaseChatModel, including local models, embeddings, and vector storage.
A developer installs the package with pip install promptise, then creates an agent with await build_agent(...). In the supplied example, model="openai:gpt-5-mini" selects the model; servers={"tools": HTTPServerSpec(url="http://localhost:8000/mcp")} targets an HTTP MCP server; ChromaProvider(persist_directory="./memory") supplies persistent memory; and PromptiseSecurityScanner.default(), SemanticCache(), and observe=True configure security scanning, caching, and tracing. The agent runs through await agent.ainvoke({"messages": [{"role": "user", "content": "..."}]}), its output is read from the final item in result["messages"], and it is closed with await agent.shutdown(). For the tool side, the README describes using @server.tool() to expose a Python function and its type hints as an MCP tool.
- An internal operations team building a status assistant that calls existing HTTP MCP tools and keeps persistent conversation memory in a local directory.
- A multi-tenant SaaS team building customer-isolated agent services, with tenant separation for memory, cache, conversations, rate limits, and audit data.
- An enterprise tools team placing approval gates on sensitive MCP operations so a human must sign off before execution.
- A team implementing agent workflows for data analysis, code review, customer support, or pipeline observation and selecting research, debate, or plan-act-reflect reasoning patterns.
- An automation team running long-lived agent processes from schedules, webhooks, or file changes and using runtime journaling, recovery, and budget governance.
What are this agent's strengths and limitations?
- A single asynchronous build_agent() entry point combines model access, MCP tool discovery, memory, security scanning, caching, and observability instead of requiring callers to assemble separate interfaces.
- It covers both agent-side and MCP-server-side work: @server.tool() derives a tool schema from Python type hints, and the README says those tools can be used by MCP clients such as Claude Desktop and Cursor.
- The README explicitly lists runtime governance for schedules, webhooks, and file watches, plus journaling and recovery, tool-call and spend limits, and human approvals.
- It declares support for multiple model providers and LangChain BaseChatModel, along with local or offline paths for security models, embeddings, and vector storage.
- The example depends on a running HTTP MCP endpoint at http://localhost:8000/mcp; the supplied material does not provide its startup or authentication configuration.
- Memory, guardrails, caching, and observability are optional parameters, so adopting those capabilities requires selecting and configuring additional components.
- The material provides no production deployment commands, infrastructure manifest, identity-provider setup, or runtime-cluster example, leaving implementation details for those production features unspecified.
- The public example uses an OpenAI model; although the README declares support for Anthropic, Gemini, Ollama, and LangChain, it does not provide copyable configurations for them.
How do you install or deploy this agent?
Run: pip install promptise. The README indicates Python 3.10+. To use the supplied OpenAI-model and HTTP-MCP example, you also need usable model-access credentials and an MCP server running at http://localhost:8000/mcp; the supplied material does not specify credential environment-variable names or an MCP server start command.
How do you use this agent?
The documented working flow imports asyncio; build_agent, PromptiseSecurityScanner, and SemanticCache from promptise; HTTPServerSpec from promptise.config; and ChromaProvider from promptise.memory. In async main(), call await build_agent(model="openai:gpt-5-mini", servers={"tools": HTTPServerSpec(url="http://localhost:8000/mcp")}, instructions="You are a helpful assistant.", memory=ChromaProvider(persist_directory="./memory"), guardrails=PromptiseSecurityScanner.default(), cache=SemanticCache(), observe=True). Then call await agent.ainvoke({"messages": [{"role": "user", "content": "What's the status of our pipeline?"}]}), read result["messages"][-1].content, call await agent.shutdown(), and start it with asyncio.run(main()).
How does this agent compare with similar options?
The README positions Foundry as a unified alternative to assembling many libraries and states that it can accept any LangChain BaseChatModel; it provides no feature-by-feature comparison with LangChain or migration procedure.