Parlant Conversation Control
A Python control harness for governed, traceable customer-facing AI conversations.
- Source repo
- emcie-co/parlant
- Stars
- ★ 18k
- Last updated
- 1d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 53/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An airline-support team needs to give technical answers to customers using specialized terms while giving beginners concrete explanations.
- Not a fit if
- Users wanting a ready-made chatbot out of the box; you must author guidelines and journeys yourself
- Teams needing workflow orchestration or knowledge retrieval; Parlant does not replace LangGraph or LlamaIndex
- Source review
- 53/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
Parlant is a Python interaction-control framework for customer-facing AI agents; it is not presented as a replacement for business workflow or knowledge-retrieval systems. Its SDK configures Guidelines, Observations, Journeys, a Glossary, Variables, Retrievers, and tools, while the engine selects turn-relevant context before producing a response or choosing a canned response. Tools are invoked only when their associated Observation matches, and their results can contribute data and dynamic guidelines. OpenTelemetry logs, metrics, and traces record guideline matches and decisions. Distribution is through pip install parlant; the supplied material names Emcie, OpenAI, Anthropic, and additional providers through LiteLLM.
Application code imports parlant.sdk as p, creates a p.Server and agent, then configures behavior with agent.create_guideline, agent.create_observation, agent.create_journey, agent.create_canned_response, and agent.create_term. For each user turn, the Contextual Matching Engine matches guidelines, resolves journey states, and assembles a focused context from relevant instructions, terms, memories, knowledge, and callable tools. When an Observation matches, it can run an async Python function declared with @p.tool; that function returns p.ToolResult with data and optionally dynamic guidelines. The system then produces a fluid generated message or, in strict mode, selects from canned responses, with matching and decisions traceable through OpenTelemetry.
- An airline-support team needs to give technical answers to customers using specialized terms while giving beginners concrete explanations.
- A bank, insurer, or healthcare organization needs traceable behavioral rules and approved wording for regulated customer interactions.
- A team with an existing LangGraph refund workflow wants it invoked as a Parlant tool only when a customer asks to process a refund.
- A support product team needs to model a multi-turn SOP such as flight booking as a Journey with conditional branches and adaptable progression.
- A knowledge-base team wants
query_docscalled when a customer asks about service features rather than keeping retrieval tools in every model context.
How do you install or deploy this agent?
Run: pip install parlant. The documented runtime requirement is Python 3.10+. The supplied material does not specify model-provider credential names, environment variables, configuration files, or a server deployment command; authentication and configuration for the selected Emcie, OpenAI, Anthropic, or LiteLLM provider must be supplied outside the documented excerpt.
How do you use this agent?
The documented SDK entry point is import parlant.sdk as p, followed by agent creation within an async p.Server lifecycle, for example await server.create_agent(name="Customer Support", description="Handles customer inquiries for an airline"). Add behavior with await agent.create_guideline(condition=..., action=...), or associate an async @p.tool function with a condition using await agent.create_observation(condition=..., tools=[...]). The supplied example writes async with p.Server(): but subsequently references an unbound server variable, so it is not itself a complete copyable first invocation. Provider authentication is also absent, so the source does not establish a verifiable end-to-end runnable command.
What are this agent's strengths and limitations?
- It filters guidelines, journey state, tools, and knowledge per turn instead of placing every rule in one system prompt.
- Guideline dependencies and exclusions provide explicit controls for prerequisite rules and conflicting context.
- Strict composition mode can select approved canned responses for critical moments.
- OpenTelemetry logging, metrics, and traces cover guideline matches and decisions.
- The supplied material does not document provider credentials, environment variables, configuration format, or a complete server deployment procedure.
- Adoption requires teams to model and maintain policies as conditions, actions, dependencies, exclusions, and journeys.
- Tools must be async Python functions returning
p.ToolResult, so synchronous or non-Python integrations need adaptation. - The material cautions that smaller off-the-shelf models can produce inconsistent results, leaving model quality as an operational dependency.
How does this agent compare with similar options?
Parlant positions itself as the conversational-governance and behavioral-control layer: LangGraph is described as better suited to workflow automation, while DSPy is described as better suited to low-level prompt optimization. It can sit alongside LangGraph, Agno, or LlamaIndex, with external workflows or query engines wrapped as conditionally invoked Parlant tools.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Parlant Conversation Control This agent | 53 · Major gaps | Library / SDKFree + model costs | ★ 18k | 1d ago | Python | OpenAI API · Claude API |
| Acontext | 44 · Major gaps | Library / SDKFreemium | ★ 3.7k | 13d ago | JavaScript | OpenAI API · Claude API |
| ACE Context Learning Engine | 51 · Major gaps | Library / SDKFree + model costs | ★ 2.6k | 1mo ago | Python | Claude Code · OpenAI API · Claude API |
| Microsoft Agent Framework | 49 · Major gaps | Library / SDKFree + model costs | ★ 15k | today | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: Apache-2.0 license, dependency security constraints (e.g., CVE fixes) are listed, but no explicit mechanisms for least privilege, user confirmation, data flow transparency, sensitive data handling, external effects, rollback, or source attribution. Deductions: lack of concrete implementations or documentation for these security features.
Evidence shows: CI test workflow exists, test files cover database adapters, but failure messages are not detailed. Deductions: insufficient clarity on failure messages, dependency availability not fully verified.
Evidence shows: README describes multiple use cases (customer support, finance, etc.), provides rich examples, but capability boundaries and trigger precision are not explicitly documented. Deductions: insufficient documentation on capability boundaries and trigger precision.
Evidence shows: README, LICENSE, pyproject.toml present, install notes clear, naming stable, examples provided, but known limitations and changelog missing. Deductions: missing known limitations and changelog.
Evidence shows: README demonstrates practical value, but no cost-benefit analysis. Deductions: cost-benefit not quantified.
Evidence shows: Claims in README lack traceable evidence, test files exist but not directly linked to claims. Deductions: claims lack traceability, facts and inferences not clearly separated.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Unverified publisher identity, supply chain risk should be carefully assessed.
- Dependencies include many third-party packages, their security and maintenance status should be monitored.
- Production deployment claims (e.g., banks) in README lack verifiable evidence.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
[4.0.2] - 2026-11-05 Added - The chat widget lets the AI agent in a visitor's browser talk to your agent over WebMCP (document.modelContext; in Chrome behind a flag today). On every page it's on, the widget registers an ask_agent tool described with the agent's name. A call starts the widget's conversation if there is none yet, as one an agent holds for the customer (customer_represented_by_an_agent), sends the question through the chat, so it shows there with the reply, opens the chat, and answers the browser agent once the turn has ended. Follow-up …View on GitHub ↗ -
Release notes excerpt
[3.3.2] - 2026-04-28 Added - Add PARLANT_TOOL_CALL_TIMEOUT environment variable to control the plugin tool-call timeout Changed - Include guideline description (in addition to the condition) in matcher prompts - Render active journeys' descriptions in the canned response draft prompt - Improve error messages surfaced by EmcieService to be more diagnostic - Relax the aiopenapi3 pin to >=0.8.1,<0.9.0 Fixed - Fix redundant batch creation in ToolCaller across guideline matches, which in some agents caused a lot of latency unnecessarily …View on GitHub ↗ -
Release notes excerpt
[3.3.1] - 2026-04-14 Added - Allow passing ToolId when attaching tools throughout the SDK - Add AnyOf(tag) and AllOf(tag) modifiers for explicit control over tag dependency semantics in depend_on() — AnyOf requires at least one tagged member to be active, AllOf requires all of them (bare Tag defaults to AllOf) - Add depend_on_any() to Guideline, Tag, and Journey for OR dependency relationships — at least one target must be active. Multiple depend_on_any() calls create independent OR groups that are AND'd together …View on GitHub ↗