deepset gives AI teams control over Haystack agents and retrieval

deepset is the company behind Haystack, a Python framework for building AI pipelines, and Haystack Enterprise Platform, the operational layer for developing and running those applications. Its appeal is explicit control over retrieval, tools, models and execution. The buyer can use an open framework directly or purchase a platform that adds shared development, evaluation, deployment and governance around it.

01 / ProductHaystack separates application composition from platform operations

The Haystack overview identifies deepset as its developer and describes modular pipelines built from retrievers, routers, tools, evaluators and generators. A pipeline makes the movement of information explicit: which component finds documents, which transforms them and which calls a model. That is useful when debugging an answer requires more detail than a final chat transcript.

The Enterprise Platform adds a visual builder, testing environments, deployment controls and run history around that foundation. The current platform name replaces deepset AI Platform. Haystack Enterprise Starter adds a separate support and engineering-assistance route around the open-source framework. This blueprint treats the framework and commercial platform as the same company’s related offers, with different operating responsibilities.

The visual builder is not a substitute for understanding the application. A team still decides which information the model should see, how tools are scoped and what ends a run. The benefit of a shared platform is making those choices inspectable and repeatable across a team, especially when several people develop and maintain the same application.

02 / AudienceUseful when engineering teams need a controllable context pipeline

A team building an internal helpdesk assistant is a plausible audience. Its questions may need different document collections, a live status lookup and a clear escalation path. A fixed retrieval pipeline may handle ordinary knowledge questions, while an agent can decide when to invoke a more specialized tool. The choice should follow the task rather than a preference for more autonomous behavior.

Teams wanting an immediately finished employee assistant should compare the implementation work carefully. Haystack supplies building blocks and an operating environment; the company still needs to design the application and validate its data. It may be unnecessary for a tiny workflow that one simple retrieval call already handles reliably and that has little need for shared operations.

The LangChain blueprint is relevant when comparing application orchestration and observability approaches. The LlamaIndex blueprint adds a useful data-and-retrieval perspective. Evaluate how each route expresses your workflow, how developers inspect failed runs and what remains your responsibility after the first demonstration.

03 / WorkflowProposed workflow: build a helpdesk agent with a narrow tool boundary

This proposed evaluation uses a small internal IT knowledge collection and a read-only service-status source. The assistant should answer questions, identify relevant documentation and escalate when it cannot establish a solution. It should not reset accounts or change infrastructure during the first pilot. That bounded job makes both retrieval quality and tool selection observable.

1. 01

   Build a reference set of support situations

   Include simple documentation questions, ambiguous service names, outdated procedures and issues that require escalation. Have support staff record the expected source and the reason an action is permitted or withheld. Keep sensitive user records outside the first evaluation.

2. 02

   Separate retrieval from live status

   Create a document-search pipeline and a distinct read-only status tool. Give each a clear input and response shape. This makes it possible to determine whether an incorrect answer came from missing documents, stale operational information or the model’s interpretation.

3. 03

   Configure the agent’s stopping behavior

   Provide only the tools needed for the job and set a maximum run length. Define when the assistant should return a supported answer and when it should hand the issue to a person. A repeated unsuccessful lookup should become an explicit failure rather than an indefinite loop.

4. 04

   Inspect complete conversations

   Review source selection, model calls, tool calls and final replies across several turns. An answer may be individually plausible but inconsistent with a constraint the user gave earlier. Preserve these multi-turn failures instead of evaluating only isolated prompts.

5. 05

   Change one component and compare

   Try a different retriever or model on the same situations. Use a stable evaluation definition and retain the run records so the team can determine whether the change improved evidence quality, response time or operating cost.

The agent documentation describes an Agent component that can use pipelines, custom functions and MCP servers as tools. It also documents maximum steps, exit conditions, access roles and traces. Those controls are directly relevant to the proposed pilot: a tool list defines capability, while the run trace lets the reviewer see how that capability was used.

The evaluation guide distinguishes code-based checks from model judges and supports evaluating whole sessions, individual turns or components. For this helpdesk example, code could check whether the required status lookup occurred; a human-reviewed model judge could assess whether the reply is grounded. The judge’s rationale needs inspection because another model can also make an error.

A particularly useful case is a user asking for a workaround after the documented procedure fails. The assistant should retain what has already been tried and avoid returning the same instruction as if it were new. This tests the application’s context management and escalation behavior, not just whether the retrieval system can find a matching paragraph.

04 / PricingChoose between owning the stack and buying its operational layer

The demo route establishes how to discuss an enterprise deployment, not a fixed price for every team. Clarify whether the agreement includes data storage, indexing, model usage, evaluation runs and non-production environments. These are distinct activities, and a modest chat volume can still involve substantial document refreshes or repeated development experiments.

The deployment documentation is especially clear about an air-gapped environment: external hosted model APIs are unavailable, and the customer must host the language, embedding and ranking models inside the network. A connection definition is not a model deployment. That distinction changes both the technical plan and the budget.

05 / DistinctionsExplicit components make change easier to reason about

A modular pipeline gives the team a concrete place to investigate failure. If the correct source was never retrieved, changing the final prompt may not help. If the source was present but misread, a retriever change may be equally misplaced. Separating these stages can make evaluation more informative and keep iteration focused on the actual weakness.

Deployment choice is another meaningful distinction. The same documentation describes managed cloud, customer infrastructure and disconnected environments. That creates a range of operating models, but portability still requires planning. Custom tools, model endpoints and observability integrations must all exist in the destination environment before the application can work there.

06 / QuestionsGovernance depends on configured boundaries and provider choices

The security and governance guide documents roles, SSO, scoped secrets and operational records. Test these against real team responsibilities: the person evaluating a pipeline may not need permission to change a production secret. The presence of a role system does not establish that a particular workspace has been configured correctly.

Trace data deserves the same attention as the original documents. A useful trace can contain prompts, retrieved passages and tool output. Decide who can read it, how long it is retained and whether it is exported to another observability service. A self-hosted platform can still call an external model if the application is configured to do so.

Finally, distinguish a documented agent feature from permission to use it on a production system. A custom function can be technically callable while still lacking an appropriate approval process. Begin with read-only tools, use evidence from the pilot to define the next capability and preserve a clear owner for changes to prompts, tools and evaluation criteria.

07 / DecisionSelect the operating model before expanding the application