Promptise Foundry: a full-stack agent framework where security, memory and tenancy are build_agent() parameters

The assembly work Promptise is trying to absorb

A working agent in production needs more than a model call. It needs a tool layer, a place to keep memory, a guardrail that inspects input before the model sees it, request caching, tracing, and some notion of which tenant is asking. The README describes the usual arrangement plainly: a model SDK, a tool layer, a vector database, auth, guardrails, a job runner and logging, glued together and kept alive by the developer. Promptise's claim is that it pulls all of that into one framework, so that memory, security, multi-tenancy, human approvals, a runtime and observability are already inside and switched on with a parameter.

The audience is therefore not someone experimenting with a single prompt. It is a Python team that has already built one agent and is now facing the second half of the job: putting it in front of paying customers. The README frames the same install as running one agent on a laptop or a fleet serving real users. That is the specific gap the project targets, and it is a real one. The question is whether a single framework absorbs the work or just relocates it.

What build_agent() actually wires together

The mechanism visible in the README is a single async constructor. build_agent() takes a model string, a servers mapping, instructions, and then optional keyword arguments for memory, guardrails, cache and observability. The example passes model="openai:gpt-5-mini", a tools entry pointing at an HTTP MCP endpoint, a ChromaProvider with persist_directory="./memory", PromptiseSecurityScanner.default(), SemanticCache(), and observe=True.

Two details matter more than the parameter list. First, tool discovery is delegated to the MCP server. The README states that the agent finds its tools on the MCP server on its own, which means the tool inventory lives outside the Python process and the framework queries it rather than requiring a decorator per function. Second, the optional arguments are described as costing nothing when omitted, so the runtime is assembled from what you pass rather than from a fixed pipeline.

Memory is the one component with a named implementation in the material: ChromaProvider, constructed with a persist directory, described as remembering across calls. The README says memory is searched before every reply, which places a retrieval step in front of the model call rather than leaving memory as something the agent chooses to consult. That ordering is a design decision with consequences for latency and for what the model sees, and the README does not quantify either.

Guardrails, caching and tracing as three lines of configuration

PromptiseSecurityScanner.default() is described as blocking prompt injection and redacting PII. The README does not enumerate the detection patterns, the redaction targets, or the failure behaviour when the scanner is uncertain. That gap matters, because a security control whose default policy is undocumented is hard to reason about in a regulated setting. Treat the scanner as a first layer to be inspected, not as a compliance boundary.

SemanticCache() is described as serving similar queries instantly. The word similar is doing a lot of work. A semantic cache answers a new query from a stored response when the two are close enough under some similarity measure, and the README does not state the threshold, the embedding model, or how invalidation works. For an agent answering questions about pipeline status, a cache that treats two similar-sounding questions as identical can return a stale answer with full confidence. The parameter is one line; the tuning is not.

observe=True is said to trace every step. No backend, exporter or retention policy is named in the material, so the practical question of where traces land is unanswered here. The three parameters together are the clearest expression of the framework's thesis: production concerns as constructor arguments.

Reasoning as a graph, and the seven presets

The second component is a reasoning engine. The README's position is that most tasks run fine on the default tool loop, and that you reach for the graph when you need more control. The described shape is think, use tools, check the answer, respond, laid out as something readable and changeable. Seven presets are listed: research, debate, plan-act-reflect, one-shot self-verify, write-one-program, and two others the truncated README does not name. You can build your own when none fit.

This is the part of the framework with the most honest framing in the material. It does not claim the graph is always better. It claims the default loop covers most tasks and the graph is for the rest. A self-verify step or a plan-act-reflect loop multiplies model calls, and the README gives no cost guidance for that, so the decision to leave the default loop is a decision to spend more per request.

The claim that there is no black box is a claim about readability, not about determinism. A graph you can read is still a graph whose nodes call models.

Multi-tenancy, identity and approval gates arrived in v1.1.0

The release history is the most informative part of the material for anyone judging production readiness. v1.0.0 landed on 2026-04-24. v1.1.0, on 2026-07-17, added three things named in the release title: Agent Identity, multi-tenancy and server-side approval gates. Those are precisely the features that separate a demo from a customer-facing deployment, and they arrived roughly three months after the first stable release.

Server-side approval gates are the notable one. An agent that can act has to pause somewhere before a consequential action, and putting the gate on the server rather than in the client means the pause is enforced by the runtime the agent runs on. The README mentions human approvals among the built-in concerns but does not document the gate API in the supplied material, so the exact mechanism is not verifiable here.

Multi-tenancy and identity landing together is coherent: tenant isolation needs an identity to isolate by. But it also means any deployment predating v1.1.0 was built without them. If you are evaluating Promptise on the strength of its tenancy story, that story is one minor release old.

The mcp<2.0 pin and what it says about the dependency surface

v1.1.1, released 2026-08-18, is titled cap mcp<2.0 (fixes broken fresh installs). That single line is the most concrete limitation in the material. A fresh install of the framework broke, and the fix was an upper bound on the MCP dependency rather than an adaptation to the new major version. MCP is not incidental to Promptise; tool discovery runs through it, and the README's own example points at an HTTP MCP endpoint. So the framework's core tool path depends on a specification that is still moving fast enough to break installs between minor releases.

The pin is the right immediate response, and it is also a warning about upgrade cost. Every future MCP major version becomes a Promptise compatibility project, and until the cap is lifted you are held on the older MCP line. Anyone with a policy against unbounded or capped transitive dependencies should check the resolved mcp version before adopting, because the pin is the kind of thing that quietly conflicts with another package's floor.

Licensing is Apache-2.0, which permits commercial use, modification and redistribution with the usual conditions around notices and patent grant. The repository material does not address trademark use of the Promptise name, and nothing here is legal advice; if you plan to redistribute a modified framework, read the LICENSE file rather than this summary.

Where Promptise is the wrong choice, and what it competes with

The framework's own framing is instructive: it says it works with anything built on LangChain. That is a compatibility statement, not a replacement claim, and it points at the real comparison. LangGraph gives you a graph of nodes and edges over model calls and leaves memory, caching, guardrails and tenancy to you or to other packages. Promptise gives you build_agent() with those concerns as arguments and a reasoning graph as an optional second layer. The difference in approach is where the default lives. LangGraph assumes you will compose the production layer; Promptise assumes the framework should supply it and you should opt out by not passing a parameter.

Pydantic AI sits closer to Promptise on ergonomics, with typed agents and dependency injection, but the material here does not describe its tool-discovery or tenancy model, so a direct comparison is not possible from this repository alone.

The case against Promptise is concrete. If your team has already standardised on LangGraph or Pydantic AI, adding Promptise means two abstractions over the same model calls and a second set of opinions about retries, tracing and tool schemas. If you need a dependency surface that does not move, the mcp<2.0 cap is evidence that this one does. If you need a documented security policy before you can ship, the README describes what PromptiseSecurityScanner does in one clause and does not describe how. And if your agent is a single script with one tool and no tenants, the framework is solving problems you do not have yet, at the cost of a runtime you now have to learn.

Who should adopt it, and what to check first

The README gives a runnable starting point: pip install promptise, then an async main() that calls build_agent(), invokes agent.ainvoke() with a messages list, prints the last message content, and calls agent.shutdown(). The model string accepts OpenAI, Anthropic, Gemini or a local model via Ollama, and tool servers are declared as HTTPServerSpec entries under the servers mapping. That is enough to run a smoke test against your own MCP server without writing framework-specific glue.

Do that smoke test in a clean virtualenv and check the resolved mcp version, because v1.1.1 exists to hold it below 2.0. Then exercise the two controls whose defaults are undocumented: send a prompt containing an obvious injection attempt through PromptiseSecurityScanner.default() and see what comes back, and issue two semantically close but factually different questions through SemanticCache() to see whether the second is served from cache. Those two experiments tell you more about production readiness than the parameter list does.

Adopt Promptise if you are building a multi-tenant agent product in Python and the v1.1.0 identity, tenancy and approval-gate features map onto requirements you already have. Do not adopt it if you have a settled agent stack, a strict dependency policy, or a single-agent prototype with no tenants. The framework is roughly four months past v1.0.0 at the time of the latest release, and its tenancy and approval layer is one minor version old; that timeline, not the feature list, is the thing to weigh.

Editorial conclusion

Adopt Promptise if you are building a multi-tenant agent product in Python and want tool discovery, guardrails, memory and tracing configured through build_agent() arguments rather than assembled from separate packages. Do not adopt it if you need a stable dependency surface in a long-lived codebase, since v1.1.1 exists only to pin mcp<2.0 after a fresh install broke, or if you have already standardised on LangGraph or Pydantic AI and do not want a second abstraction over the same model calls. Before committing, install promptise in a clean virtualenv and confirm the resolved mcp version, then run the README example against your own MCP server at an HTTPServerSpec URL to check that tool discovery and the SecurityScanner behave as the docs describe.

Official sources

1. License: Apache-2.0
2. Project website
3. promptise-com/Foundry on GitHub
4. README
5. Releases