The repository is Foundry, the package is promptise, and v1.1.1 exists because an uncapped mcp broke fresh installs

The repository is Foundry and the distribution is promptise

Three names coexist. The repository is `promptise-com/Foundry`, the distribution on PyPI and the import name is `promptise`, and the marketing site and documentation sit under `promptise.com` and `docs.promptise.com`. The repository description is a single line, the foundation layer for agentic intelligence.

So the install is:

pip install promptise

and everything you import comes from the `promptise` package, not from anything called Foundry. That matters for anyone searching for a library name, for pinning a requirement, and for reading a stack trace.

The header of the page also contains a small copy and paste artifact: three identical PyPI links in a row, all pointing at the same project page, alongside the star link, the test workflow badge, a commits link, the license link and the documentation link. It is cosmetic, but it is the kind of detail that tells you the header was assembled by hand rather than generated from the release metadata.

The rest of the identity is professional in a way worth noting. The project is typed, declares `Typing :: Typed`, is Beta, requires Python 3.10 or newer, and carries Apache 2.0 both as a license classifier and in the license field of the packaging metadata.

Five parts, and the default is the tool loop you get for free

The framework is sold as five parts, each described as replacing a stack of libraries you would otherwise wire together. The agent is part one, and `build_agent()` connects to your tool servers, discovers the tools on its own, and attaches memory that is searched before every reply, a security scanner, response caching, sandboxed code execution and tracing, each of them one parameter.

Part two is the reasoning engine, and its default is worth knowing: most tasks run on the default tool loop, and the graph is for when that is not enough. When you want control you lay reasoning out as a graph you can read and change, thinking, using tools, checking its own answer, then responding. Seven presets are named, covering research, debate, plan act reflect, one shot self verify and write one program, and you build your own when none of them fit.

Parts three, four and five are the MCP server SDK, the agent runtime, and prompt engineering, which covers assembling a system prompt from typed blocks with a token budget, letting it change across the phases of a conversation, and checking it with a sampler. That last sentence is where the visible text on this page stops, mid word, so the tool it names is not something this page tells you.

The overall claim is that the parts you do not pass cost you nothing, which is the difference between a bundle and an upsell.

The agent discovers its own tools, which is why the tool server is a parameter

The quick start is one call, and its shape explains the architecture:

import asyncio
from promptise import build_agent, PromptiseSecurityScanner, SemanticCache
from promptise.config import HTTPServerSpec
from promptise.memory import ChromaProvider

async def main():
    agent = 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"),  # remembers across calls
        guardrails=PromptiseSecurityScanner.default(),          # blocks injection, reda

Four decisions are visible in that snippet. Tools live behind a named server spec, here a dict with one entry called `tools` pointing at an MCP endpoint, so several servers can be attached side by side. Memory is a provider with a persistence directory, which is why the Chroma provider is imported from `promptise.memory` rather than configured by string. Guardrails are an object with a `default()`, and the inline comment claims it blocks injection and redacts personal data. And the model is a string in the `provider:model` form, `openai:gpt-5-mini`, which is the LangChain convention rather than a vendor SDK call.

The page states the agent finds the tools on the MCP server on its own, and that the same code works with OpenAI, Anthropic, Gemini or a local model through Ollama, and with anything built on LangChain.

mcp is capped below 2.0, and that cap is what version 1.1.1 shipped

The most informative thing in the packaging is a comment above one dependency:

  # Capped below 2.0: mcp 2.0 changed the low-level Server() signature and
  # renamed ResourceTemplate.uriTemplate -> uri_template, which breaks the
  # server SDK. Lift the cap once the SDK is ported to the 2.0 API.
  "mcp>=1.9.0,<2.0",

That is a specific and verifiable kind of pin. A major version of the MCP library renamed an attribute and changed a constructor, the server SDK in this project used both directly, and rather than porting it the dependency was capped.

The release history shows what that cost. v1.1.1 is titled cap mcp<2.0 with a parenthetical that it fixes broken fresh installs. So the sequence was: a major release of `mcp` landed, new installs resolved it, and the server SDK broke. A patch release was spent putting a ceiling back.

Two other dependency details are worth a look. `langchain-openai` is a core dependency rather than an extra, so the OpenAI integration arrives even if you run Anthropic or a local model. And `langchain` itself is required at 0.3.27 or newer with no upper bound, which is the opposite policy applied to the same file.

The runtime persists every step, and the fleet layer names Redis and etcd

The runtime is what turns an agent call into a process. The description is specific: an agent becomes long running, waking on a schedule, a webhook or a file change, and it writes down every step so a crash resumes from where it stopped instead of starting over. You can set limits on tool calls and on spend, watch for stuck or looping behavior, and require a human when it hits something risky, running one agent or a fleet across machines.

The dependency list corroborates the triggers. `croniter` is there for schedules, `watchdog` for file changes, and `croniter` and `watchdog` are grouped under a Runtime comment rather than under orchestration. Conversation persistence is also in the core set, with `aiosqlite` present and commented as backing the `SQLiteConversationStore` core feature, so a resumed conversation is a local database rather than memory reconstructed from a log.

The environment template is where the multi machine story appears. It documents a Redis URL for distributed features, named as RedLock and a message broker, etcd URLs for a distributed registry, and a discovery protocol setting with options registry, mdns, gossip and multicast. None of Redis or etcd appears in the visible core dependency list, so those arrive with an optional extra, which is consistent with the Makefile installing an `orchestration` extra for development.

Sandboxing is also parameterized in that file, with a mode of docker or e2b and an E2B API key, so code execution can be local containers or a hosted sandbox.

The MCP server SDK ships a network free test client

The server side is sold on reuse. You write a Python function, add `@server.tool()`, and it becomes an MCP tool with a schema taken straight from your type hints. The same tool then works with Promptise agents and with Claude Desktop, Cursor and any other MCP client.

Around that decorator sits a list that reads like a list of things you would otherwise add. Authentication, per tool permissions, rate limits, circuit breakers, tamper evident audit logs, and a background job queue.

Two of those deserve a second look. Per tool permissions is the interesting one for multi tenant use, because it is the difference between a tool being callable by an agent and a tool being callable by a specific tenant's agent. And the test client is the detail most people would not expect: a client that runs the whole request path without a network, which means the server, the schema and the handler can be exercised in a unit test rather than only over HTTP.

The tamper evident audit log claim is worth verifying against the implementation if you need it for compliance, because the page does not say what it hashes or what protects the log from a writer with access to it.

The Makefile defines a dozen targets that are not declared PHONY

The development Makefile is a readable artifact and it contains a small inconsistency. The `.PHONY` line declares eleven targets:

.PHONY: help install install-dev test lint format clean build publish docker-build docker-run docs serve-docs

The file then defines more than that. The Testing section has `test-cov`, which runs pytest with coverage against `src/promptise` and both HTML and terminal reports, and `test-integration`, which runs pytest with the `integration` marker. The Linting section adds `type-check` for mypy, and there are also `pre-commit`, `publish-test` for TestPyPI, `docker-compose`, `run-example` and `run-orchestration`.

None of those are in the `.PHONY` list, and the `help` output advertises all of them. The practical effect of a missing `.PHONY` entry is that make compares the target name against a file of the same name and skips the recipe if that file exists, so a stray `type-check` file in the working tree silently disables the type checking step.

The rest of the file is conventional and worth using as a reference: `install` is an editable install, `install-dev` adds the dev, orchestration and sandbox extras and then runs `pre-commit install`, and there are build, publish, docker and documentation targets.

The documentation lives in three directories, and there are two readmes

A repository this size with three documentation locations is worth mapping before you contribute. There is a `docs/` directory, a `content/` directory, and an `overrides/` directory, with `mkdocs.yml` at the root driving the site. The overrides directory is the MkDocs mechanism for replacing a theme's templates, so it is a rendering concern rather than a content one, but from the tree alone the three look interchangeable.

There are also two readme files. `README.md` is the one you have read, and `.org-profile-README.md` is a second file whose only plausible purpose is the GitHub organization profile page, which is rendered from a different path than a repository readme. That is a useful thing to know if you are looking for contribution instructions and land in the wrong file.

The machine facing side of the documentation is two files at the root, `llms.txt` and `llms-full.txt`, which is the convention for giving a language model a map of a site and the full text behind it. The examples directory is organized the same way as the framework itself, with thirteen directories named by capability: adaptive, approval, hooks, identity, mcp, memory, production, prompts, rag, reasoning, runtime, sandbox and security.

So the feature list on the page has a matching example directory for each item, which is the fastest way to judge whether a claim is real.

Editorial conclusion

Promptise is worth evaluating if you are assembling an agent stack from a model SDK, a tool layer, a vector store, guardrails and a job runner, and you would rather have one dependency than six, because the pitch is that memory, security, approvals, runtime and observability are already inside and cost nothing when you do not pass them. Two things to check before committing. Read the dependency floor, since `mcp>=1.9.0,<2.0` is capped with a comment saying 2.0 changed the low-level `Server()` signature and renamed `ResourceTemplate.uriTemplate` to `uri_template`, and v1.1.1 was released specifically to add that cap because fresh installs were broken. And pick your execution path deliberately, because the runtime is built around a persisted conversation store, and the fleet features named in the environment template, Redis for RedLock and a message broker, etcd for a distributed registry and a discovery protocol, are not in the visible core dependency list. The newest release is v1.1.1 from 2026-08-18, the branch was last pushed on 2026-09-24, and the project is classified Beta with a Python 3.10 floor.

Frequently asked questions

Official sources

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