# Orchestration architecture tagIt is built around a simple orchestration pattern: ``` AI client -> AI Orchestrator -> AI model -> Connectors -> Conversation history -> Artifacts ``` The [AI Orchestrator](/tagit/getting-started/concepts.md#ai-orchestrator) sits in the middle. It receives a request from an [AI client](/tagit/getting-started/concepts.md#ai-client), resolves the configured [agentic use case](/tagit/getting-started/concepts.md#agentic-use-case), assembles the right context, calls the selected AI model, exposes allowed connectors, manages workflow state, and returns the final response. This keeps client applications simpler. The client does not need to understand model-specific APIs, tool wiring, prompt assembly, workflow handoffs, artifact persistence, or conversation memory. It only needs to call an authorized agentic use case. For term definitions, see [Concepts](/tagit/getting-started/concepts.md). For request and response details, see the [Orchestrator API reference](/tagit/reference/reference/api/orchestrator.md). This page focuses on how those concepts work together at runtime. ## Runtime roles ### AI client An AI client is the caller in the architecture. It may be: * AI Canvas embedded in a website or application * a custom React, mobile, or backend client * an automation job * another service that needs to run an agentic use case The client owns the user-facing or service-facing interaction. It sends the current request, along with the identifiers required by the orchestrator, such as the account, context, use case, user, and conversation. [AI Canvas](/tagit/getting-started/concepts.md#ai-canvas) is one implementation of an AI client. Teams can use it directly or treat it as a reference for building their own client. See the [AI client reference](/tagit/reference/reference/ai-client.md) for the web client implementation contract. ### AI Orchestrator The AI Orchestrator is the runtime boundary between the host application and the AI system. In the architecture, the client calls the Orchestrator instead of calling models, connectors, memory stores, or workflow steps directly. The Orchestrator resolves the configured runtime behind the agentic use case and returns the final response through one consistent API surface. This allows the runtime configuration behind a use case to evolve without requiring every client implementation to change. See the [Orchestrator API reference](/tagit/reference/reference/api/orchestrator.md) for endpoint details. ### AI model The client does not call the AI model directly. The AI Orchestrator resolves the configured model for the agentic use case or workflow step, applies the required instructions and policies, and sends the model the assembled payload. This allows teams to change model choices without requiring every client implementation to change. ### Connector Connectors provide controlled external capabilities to the model through the AI Orchestrator. For example, the tagIt MCP Server is a connector. A customer availability API, product catalog, pricing service, CRM lookup, or policy retrieval endpoint could also be a connector. MCP is one supported connector pattern, but the architecture does not require every connector to use MCP. ## Agentic turns and workflows The orchestration pattern supports two execution shapes: agentic turns and agentic workflows. Both are defined under [Agentic Use Case](/tagit/getting-started/concepts.md#agentic-use-case). In an agentic turn, the Orchestrator applies the same configured instructions and runtime settings to the current message, along with relevant conversation history. In an agentic workflow, the Orchestrator manages intermediate model calls, connector access, step handoffs, artifacts, checkpoints, and traceability before returning the final response to the client. This distinction matters because workflows keep orchestration logic out of the client. A client can present the experience, while the orchestrator manages the process. ## Conversation and artifact state The AI Orchestrator can persist state that needs to survive beyond a single request. [Conversation](/tagit/getting-started/concepts.md#conversation) history lets future turns or workflow runs include relevant prior context without requiring the client to resend the entire chat transcript every time. [Artifacts](/tagit/getting-started/concepts.md#artifact) let workflows build and refine durable outputs such as recommendations, plans, briefs, reports, or working documents. A later workflow step can receive the current artifact state instead of relying only on raw chat text. Together, conversation history and artifacts let tagIt support AI journeys that evolve over time instead of treating every request as a fresh prompt. ## Relationship to AI Presence [AI Presence](/tagit/getting-started/concepts.md#ai-presence) is adjacent to the orchestration path, not inside the direct model execution path. When AI Presence is enabled, the AI client can send conversation and engagement events to the Collector API separately from the request it sends to the AI Orchestrator. AI Presence can then analyze those signals and produce engagement policy that may shape future orchestration. For that flow, see [Presence architecture](/tagit/getting-started/presence-architecture.md). ## Example flow 1. A user opens an AI Canvas assistant inside a website. 2. AI Canvas sends the current message to the AI Orchestrator with the configured agentic use case and conversation identifiers. 3. The AI Orchestrator resolves the use case snapshot, context instructions, AI model, policies, and allowed connectors. 4. If needed, the orchestrator rehydrates recent conversation history or current artifact state. 5. The orchestrator sends the assembled payload to the AI model. 6. The model may call allowed connectors through the orchestrator. 7. The orchestrator records trace details, stores conversation or artifact updates, and returns the final response. ## Why this architecture matters This architecture separates responsibilities: * clients own the user or service experience * the orchestrator owns runtime execution * AI models own generation and reasoning * connectors provide controlled external capabilities * conversation history and artifacts preserve durable context That separation lets teams build AI experiences that are easier to operate, inspect, and evolve. A client can stay simple while the orchestration layer handles the complexity of models, tools, workflows, memory, artifacts, and policies. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://tagit.gitbook.io/tagit/getting-started/orchestration-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.