FAQ

Context is a platform for building and running agents on business workflows. Workspace is where people define and review work. Engine runs agents with tools, identity, and isolated compute. Unify stores the procedures and context those agents use. Evals measures completed work against criteria set by your team.

The products can be deployed separately or together. When they are used together, the same run trace can support review, evaluation, and later improvements without moving the workflow between systems.

A chatbot mainly returns an answer. Context runs a defined sequence of steps across the systems involved in a workflow. The runbook specifies the task, permissions, review points, and definition of done. Each run retains its sources, tool calls, outputs, and approvals so the result can be inspected and evaluated.

A vertical tool usually packages one workflow and a fixed set of systems. Context provides reusable runtime, context, evaluation, and governance components for many workflows. Teams can start from a prebuilt agent and adapt its runbook, connected systems, approvals, and quality criteria to their process.

A runbook is the operating specification for an agent. It records the steps to follow, systems it may use, inputs and expected outputs, approval points, and evaluation criteria. Business and technical owners can review the same specification before the agent runs.

Context supports a managed deployment, deployment in a customer VPC, on-premises deployment, and environments designed for disconnected operation. The available model endpoints, connectors, update process, and support model are configured for the selected architecture. Data-flow boundaries are documented during implementation.

Engine runs each agent in an isolated environment and gives it only the tools configured for the runbook. Connectors use the authentication method supported by the target system, such as OAuth or a scoped service credential. Read access, write access, and human approval can be configured separately.

Credentials are brokered to the connector at runtime rather than written into the runbook or prompt. Depending on the target system and deployment, the connector can use delegated user identity or a scoped service identity. Credential storage, rotation, and revocation are reviewed as part of the deployment design.

Context does not use one customer's traces, corrections, or institutional context to train models for other customers. Model-provider retention and training settings depend on the endpoints a customer chooses, so those controls are documented and verified during deployment.

A run records the task, model and tool calls, source references, actions, approvals, and result. Reviewers can inspect the sequence and compare the output with its rubric. Export and retention requirements are configured for the customer's deployment.

Unify organizes source material, procedures, accepted examples, and corrections in a filesystem agents can navigate. Context can propose updates from completed work between runs. Teams choose the review and publication policy for those updates rather than treating every generated note as trusted knowledge.

Teams write task-specific rubrics and assemble accepted examples. Evals can score runs against those criteria, surface failures for review, and compare changes to a runbook, model, or retrieval configuration. Human review remains part of the process for subjective or high-consequence decisions.

Context can use commercial or open-weight models available in the selected deployment. A runbook may use one fixed model or route between models based on cost, latency, and eval performance. Because runbooks, context, and evals are stored outside the model, teams can compare or replace model providers without rebuilding the workflow.

Timing depends on deployment requirements, connector access, and the workflow's risk. A focused first workflow typically covers the runbook, required systems, a small evaluation set, and reviewer sign-off. Context scopes those dependencies before committing to an implementation schedule.

Context is a good fit when a workflow has repeatable steps but still depends on documents, multiple systems, or expert judgment. Common examples include diligence, case processing, research, reporting, support, compliance, and engineering operations.

Pricing depends on the deployment model, usage, support requirements, and implementation scope. Talk to our team for a quote shaped to your deployment model.

Request a guided demo and bring one representative workflow. We'll map its inputs, systems, permissions, review points, and definition of done, then show how it would run in Context.