FAQ

FAQ

Why is there no hosted Algenta cloud default? Because "self-hosted" with a hosted fallback quietly stops being self-hosted. Every package resolves its endpoint from base_url= → ALGENTA_BASE_URL → a localhost fallback, full stop (see Self-Hosted). The sibling algenta-sdk makes a different choice — its AlgentaClient defaults to https://api.algenta.ai for a zero-config quickstart — and these integrations deliberately never use that default, to the point of re-declaring their own localhost constant rather than importing the SDK's hosted one.

Where is the engine? Can I see its source? The Algenta engine is closed source and lives in a separate, private repository. Nothing here vendors, imports, or depends on it — a boundary checked mechanically on every PR by scripts/check-no-engine-dependency.py (with its own proof-of-catch test). Everything in this repository is ordinary Python/TypeScript under Apache-2.0, talking to the engine's public HTTP/MCP APIs. The engine's compute kernels are proprietary Mojo, shipped as signed wheels with the engine; see also thyn-ai/mojo-kernels for clean-room open-source Mojo kernels.

Do I need an Algenta API key? For the MCP-based packages: only if your engine deployment enforces authentication — local engines often run with auth disabled. For vllm-algenta (the engine's OpenAI-compatible HTTP API): yes — every route there requires an authenticated caller, and the package raises immediately if ALGENTA_API_KEY is unset rather than letting you 401 later. Separately, most quickstarts need a model provider key (e.g. OPENAI_API_KEY) — that's your LLM provider's, not Algenta's.

Is there an approval-pending state on execute_decision? No. A call either returns a typed ExecutionReceipt or is denied in the same call by one of three named gates (idempotency, confidence, risk_floor). A genuine plan_hash+nonce human-approval system exists in the engine, but it is intentionally not exposed as an MCP tool, so no package here can reach it — and none models a fictional "pending" state. (Several packages did once, and their READMEs document removing that as fictional code.)

Can the model set force or override_safety to bypass a gate? Never. Those fields are operator/break-glass-only: stripped from every advertised tool schema and scrubbed from forwarded arguments, in every profile including full (gateway-side allowed_params for LiteLLM). A human operator applies them outside the model-facing tool call entirely. See Tool Contract.

Why does llamaindex-algenta pin mcp<2.0.0 — and why must I add llama-index-workflows<2.24 myself? Two real, currently-live upstream bugs, both verified against installed packages: llama-index-tools-mcp 0.5.0 + mcp 2.x breaks every HTTP call (ValueError: not enough values to unpack), so the package pins mcp<2.0.0 (pulling the working 0.4.8). Separately, llama-index-workflows 2.24.0 breaks every FunctionAgent.run(); the package deliberately does not pin that one because it never imports workflows — a ceiling on someone else's dependency would propagate to every consumer. Install the working pair yourself until upstream fixes it; the package README has the full evidence.

Is litellm-algenta a library I call from Python? Not in the usual sense. LiteLLM's MCP Gateway is a proxy server process configured by YAML, so the package is a config generator (build_mcp_server_entry), a linter (lint_mcp_server_entry / assert_safe), and per-profile YAML templates. Enforcement is the gateway's own real allowed_tools / allowed_params — verified against a live litellm proxy. See LiteLLM.

Why do some packages depend on algenta-sdk and others don't? Every package may depend on at most one Algenta-owned thing — the published SDK — and only when it genuinely imports it. pydantic-ai-algenta and langchain-algenta declare it; llamaindex-algenta, maf-algenta, haystack-algenta, litellm-algenta, ray-serve-algenta, vllm-algenta, and algenta-tools don't, because nothing in them calls it (and the SDK's hosted-default constants are actively the wrong default here). Declaring it unused is a bug shape this repository has already caught and fixed once.

Which packages are "validated integrations"? None yet, honestly. Each package has its own passing test suite against a real local stub server, and the conformance suite currently proves the engine-side lifecycle (9 exercisable, 3 blocked) directly over HTTP. Per-framework adapters driving those same scenarios through each package are the next milestone — until they pass, no package claims the label.

What's the status of the vLLM package's /v1/responses support? The engine's /v1/responses surface has grown (tools, previous_response_id, typed input arrays) beyond what vllm-algenta's stub and tests currently model. It's a known, tracked gap, documented in the package README's capability table — re-verify against your own engine version.

Can I use the n8n node on n8n Cloud / find it in n8n's community registry? No to both, deliberately: the node needs @modelcontextprotocol/sdk as a runtime dependency (banned by n8n Cloud's verification program), and it keeps Apache-2.0 in package.json where the registry lint demands MIT. It installs and runs fine on self-hosted n8n — its actual target audience. See N8N.

How do I run everything without an engine? Every package README has a "Try it locally" section: a real stub MCP/HTTP server on a real local socket, often with a scripted model double — no engine, no API key, no network beyond 127.0.0.1. Getting Started walks through one.