Algenta SDK
Python and TypeScript client libraries and the official MCP server for Algenta β self-hosted building blocks for AI applications.
π Full documentation: GitHub Wiki
Docs Β· Python SDK Β· TypeScript SDK Β· MCP server Β· Integrations Β· Examples Β· Contributing
Custom Mojo kernels give Algenta its speed. Your team never writes a line of Mojo β the blocks speak Python and TypeScript. On your infrastructure, not ours. These SDKs are how Python and TypeScript call the engine: typed access to governed data queries, Monte Carlo simulations and recommendations, decision memory with execution receipts that pin the policy and schema snapshots each execution ran under, agent runs with human-in-the-loop approvals, managed connectors, and a full audit trail β enforced by the engine, never by client-side convention.
MCP server
MCP server (algenta-mcp) β the official MCP server for Algenta lives in
THIS repository at packages/mcp/ (implementation:
packages/mcp/algenta_mcp; stdio transport by default, Streamable HTTP
optional). Install it with pip install algenta-mcp and run it as the
algenta-mcp command; it is also on the official MCP Registry as
io.github.thyn-ai/algenta. The framework integrations (LangChain, LlamaIndex,
Vercel AI SDK, β¦) are what live in the companion repository
thyn-ai/algenta-integrations
β not the MCP server.
Introspection (initialize/tools/list) needs no credentials. Executing tools
requires a free community login β device registration at algenta.ai (free): run
algenta login, or create a key at
https://app.algenta.ai/dashboard/api-keys, then set ALGENTA_API_KEY.
Installation
pip install algenta-sdk # Python 3.12+
npm install algenta-sdk # TypeScript / JavaScript, Node.js 18+
Quickstart
Both clients read ALGENTA_API_KEY from the environment and default to
Algenta's hosted API at https://api.algenta.ai.
Python β note the import name is decision_engine (see
Legacy names):
from decision_engine import AlgentaClient
client = AlgentaClient() # reads ALGENTA_API_KEY; defaults to https://api.algenta.ai
datasets = client.list_datasets(search="orders", compact=True)
summary = client.get_dataset_summary(datasets.datasets[0].dataset_id)
result = client.query_with_metadata(
{
"dataset_id": summary.dataset_id,
"metric": {"hint": "gross_revenue"},
"aggregation": "sum",
}
)
print(result.data.result)
TypeScript:
import { AlgentaClient } from "algenta-sdk";
const client = new AlgentaClient(); // reads ALGENTA_API_KEY; defaults to https://api.algenta.ai
const datasets = await client.listDatasets({ search: "orders", compact: true });
const summary = await client.getDatasetSummary(datasets.datasets[0].dataset_id);
const result = await client.queryWithMetadata({
dataset_id: summary.dataset_id,
metric: { hint: "gross_revenue" },
aggregation: "sum",
});
console.log(result.data.result);
Self-hosted engine? Point the client at your own deployment β
AlgentaClient(base_url="http://localhost:8000") in Python,
new AlgentaClient({ baseUrl: "http://localhost:8000" }) in TypeScript β and
use the API key provisioned by your operator. The self_hosted and
air_gapped deployment profiles fail closed: they never silently fall back to
Algenta's cloud. Framework integrations in
thyn-ai/algenta-integrations
take the opposite default on purpose: they are self-hosted-first, resolve their
endpoint from ALGENTA_BASE_URL or an explicit base_url, and never default or
fall back to the hosted API.
The full API surface β governed queries, connectors, simulations, jobs,
triggers, agent runs, decisions, repository intelligence, and the TypeScript
local Runtime facade β is documented in
packages/python-sdk/README.md and
packages/ts-sdk/README.md, with runnable
projects in examples/. The MCP server lives in this repository
(see MCP server above); framework integrations (LangChain,
LlamaIndex, Vercel AI SDK, and more) live in the companion repository
thyn-ai/algenta-integrations.
Errors, retries, and timeouts
Both SDKs raise the same exception taxonomy. Every error carries the HTTP
status, the engine's machine-readable error_code, and β in Python β the
engine-assigned request_id; validation failures additionally expose
per-field details via field_errors (Python) / fieldErrors (TypeScript).
| Exception | HTTP status | Raised when | Retried by default |
|---|---|---|---|
AuthenticationError | 401 | Missing or invalid API key | No |
NotFoundError | 404 | Resource does not exist | No |
ValidationError | 422 | Request failed schema validation | No |
RateLimitError | 429 | Quota or rate limit exceeded | Yes β honors the engine's Retry-After (retry_after / retryAfter, default 60s) |
ServerError | 5xx | Engine-side failure | Yes β exponential backoff |
DecisionEngineError | any | Base class for all of the above | β |
Transient network errors are retried on the same policy as 5xx responses. The
Python SDK additionally never retries one rate-limit code,
inline_preview_rate_limited.
| Setting | Python | TypeScript | Default |
|---|---|---|---|
| Request timeout | timeout (seconds) | timeout (milliseconds) | 120 |
| Retries per request | max_retries | maxRetries | 3 |
Legacy names
The SDK was renamed to Algenta partway through its history. For backward compatibility, the legacy names below still work β existing code and deployment configurations do not need to change:
- Python import name β the PyPI package is
algenta-sdk, but the importable module remainsdecision_engine:from decision_engine import AlgentaClient. - Client aliases β
CodnaClient(andAsyncCodnaClientin Python) remain exported as aliases ofAlgentaClientin both SDKs. - Environment variables β
DE_API_KEY,DE_BASE_URL, andALGENTA_API_URLare still accepted alongside the canonicalALGENTA_API_KEYandALGENTA_BASE_URL.
The published API contract guarantees a 90-day deprecation window
(DEPRECATION_WINDOW_DAYS) before any legacy name is removed.
Powered by Mojo
The engine's compute kernels β simulation, scoring, and local query
execution β are written in Mojo and are
proprietary. They are distributed as signed algenta-runtime-native wheels
and are not part of this repository.
What is open, here and under Apache-2.0: both SDKs, the published API contract
they are generated from, the client/runtime wire protocol they speak, and
runnable examples β including examples/mojo-quickstart/,
a minimal end-to-end walkthrough of calling the native runtime through the SDK.

What is open source?
This repository contains Algenta's Python and TypeScript client SDKs and the
official MCP server (packages/mcp/), licensed
under Apache-2.0 (see LICENSE and NOTICE).
The Algenta engine itself is closed source and is not contained in this repository. Engine licensing, device entitlements, worker limits, concurrency limits, and Server Compute Units are enforced independently by the engine, subject to the separate Algenta Engine license.
The SDK is a plain HTTP client. It holds no license-signing keys, no entitlement-enforcement logic, and no secret shared with the engine β every entitlement claim is independently verified and enforced by the closed engine, never by this SDK. Fork it, delete every check in it, or replace it with your own HTTP client entirely β modifying or replacing this SDK does not change the execution capacity licensed to an Algenta engine. See SECURITY.md for what that means for vulnerability reports.
Algenta does not require hosted inference or telemetry for execution. Paid licenses expand local execution and governance capacity rather than charging per SDK call.
Verify a release
Every release built by release.yml is
tied to:
- a protected
sdk-vX.Y.Zsource tag in this repository; - the exact commit that tag points to;
- a release-authorization record, signed by the internal release pipeline
after the engine's test suite has validated the commit, binding that
commit and a contract-file digest to the version being released (see
releases/).
release.yml refuses to build or publish anything unless all of the above
independently agree β see
scripts/verify_release_authorization.py.
Each GitHub Release cut
since signing was added (September 2026) carries, next to the wheel, the sdist
and release-manifest.json:
- a keyless Sigstore signature bundle per asset
(
<asset>.sigstore.json), signed by therelease.ymlrun itself; - SLSA build provenance covering all three assets (
multiple.intoto.jsonl), from the SLSA generic generator.
To check an asset against both, with VERSION set to the release version
(VERSION=1.0.15 for tag sdk-v1.0.15):
pipx run sigstore verify identity "algenta_sdk-${VERSION}-py3-none-any.whl" \
--bundle "algenta_sdk-${VERSION}-py3-none-any.whl.sigstore.json" \
--cert-oidc-issuer https://token.actions.githubusercontent.com \
--cert-identity "https://github.com/thyn-ai/algenta-sdk/.github/workflows/release.yml@refs/tags/sdk-v${VERSION}"
slsa-verifier verify-artifact "algenta_sdk-${VERSION}-py3-none-any.whl" \
--provenance-path multiple.intoto.jsonl \
--source-uri github.com/thyn-ai/algenta-sdk \
--source-tag "sdk-v${VERSION}"
A release published through release.yml's workflow_dispatch path was
signed from the dispatched branch, so its certificate identity ends in
@refs/heads/main instead of the tag; the bundle records which.
Versioning
Both packages share one version number, since they wrap one API contract, and follow Semantic Versioning:
- Patch β bug fixes and documentation; no API surface change.
- Minor β backward-compatible additions (new methods, new optional fields).
- Major β breaking changes to exported symbols, required fields, or behavior, announced in advance through the deprecation window above.
Release history lives in CHANGELOG.md.
Contributing
Bug fixes, framework integrations, docs, and tests are welcome β see CONTRIBUTING.md. There is no CLA: contributions are licensed inbound=outbound under Apache-2.0, per GitHub's Terms of Service. Requests for new API capabilities usually require a change on Algenta's private API first; open an issue describing the capability rather than a PR against the generated contract files (also covered in CONTRIBUTING.md).
Please also read CODE_OF_CONDUCT.md.
- Security reports β SECURITY.md (never a public issue)
- Project direction and maintainership β GOVERNANCE.md
- Getting help β SUPPORT.md
Contributors
Thanks to everyone who contributes to this project β we follow the all-contributors specification and recognize contributions of every kind, not just code.
Community
Related repositories
Open-source tooling around Algenta, from the Algenta team. The Algenta engine itself is proprietary; everything listed here is Apache-2.0. Issues and discussions are welcome in whichever repository owns the code.
- thyn-ai/algenta-sdk (this repository) β Python and TypeScript SDKs for Algenta plus the official MCP server (
packages/mcp/): governed data queries, simulations, decision memory with execution receipts, agent runs with approvals. - thyn-ai/algenta-integrations β Framework integrations for Algenta: LangChain, LlamaIndex, pydantic-ai, MAF, Haystack, LiteLLM, Ray Serve, vLLM, Vercel AI SDK and n8n.
- thyn-ai/mojo-kernels β Clean-room Mojo kernels as drop-in accelerators for popular Python/TypeScript libraries, with bit-exact parity and pure-language fallbacks.
- thyn-ai/security-toolchain β The pinned, checksum-verified security toolchain (Gitleaks, Opengrep, OSV-Scanner, Trivy config, actionlint) that every thyn-ai repository runs locally and in CI.
- thyn-ai/feedback β Public issue intake for the open-source tooling around Algenta and for the Codna GitHub App.
- thyn-ai/codna-action β GitHub Action for Codna: fix, review or secure a repository in CI through the same packaged local runtime the CLI uses.