# Concepts This page defines the core concepts used throughout the tagIt documentation. The goal is not to cover every implementation detail. The goal is to give product, engineering, operations, and AI strategy teams a shared vocabulary for designing AI experiences inside real applications. ## AI journey An **AI journey** is the full experience around how AI engages with a person over time. It includes: * the moment the interaction begins * the goal of that interaction * the experience the user sees * the tools and policies behind the runtime * the signals the system learns from the conversation An AI journey is broader than a single chat response. It is the flow of orchestration, experience, and insight working together. ## Account An **account** is the top-level customer container in tagIt. It groups together: * contexts * users and access * dashboards * settings * the overall product space for a customer Most teams start by working inside an account. ## Context A **context** is the workspace under an account where a team defines the operating environment for a set of AI experiences. A context can represent a product surface, website, application, service, campaign, brand, agent, or operational workflow. It is the governance boundary for the agentic use cases and data collection tags that belong to that environment. For implementation teams, a context is where shared runtime rules are established before individual agentic use cases are built. Admins can define the AI governance parameters for the context, including: * context-level instructions * default AI providers and models * allowed model bindings * allowed MCP servers and tools * runtime policies and limits * tag and data capture settings * user access and permissions Managers or builders can then create agentic use cases inside those boundaries. This keeps individual use cases flexible while preventing every use case from redefining the same governance, provider, tool, and identity assumptions from scratch. Users can set AI instructions at the context level. These context instructions apply broadly to the child agentic use cases in that context, giving every use case a shared foundation before its own more specific instructions are added. Context instructions are useful for stable guidance that should remain consistent across the experience, such as the product role of the AI, the audience it serves, the business rules it must respect, or the tone and operating constraints it should follow. Examples: | Context type | What context instructions usually define | | ------------------- | ---------------------------------------------------------------------------------------------------------------- | | Product app | The role of the AI inside the application, the user types it serves, and the product boundaries it must respect. | | Website | The brand voice, visitor journey, qualifying behavior, and escalation rules for an embedded AI assistant. | | Agent workspace | The agent's durable persona, operating principles, shared tools, and rules that apply across multiple workflows. | | Campaign or program | The campaign objective, audience segment, compliance guardrails, and approved data or content sources. | | Internal service | The operational process, system boundaries, allowed actions, and handoff rules for teams using the service. | You can think of context as the persistent layer around an AI journey: it defines where the AI is operating, what rules it inherits, which tools it may use, and how governance is applied before a specific agentic use case runs. ## Agentic Use Case An **agentic use case** is a specific executable AI capability inside a context. You can think of an agentic use case as an agent, or a focused fragment of an agent, that knows what it should do in a particular moment of the journey. It packages the instructions, model path, tools, policies, and runtime behavior needed to complete that job. In the platform and API, this may still appear as a **use case** or `use_case_id`, but conceptually it represents the unit of agentic behavior the orchestrator can execute. Examples: * homepage discovery * product detail comparison * checkout guidance * onboarding assistance * post-purchase support An agentic use case can be simple or complex: * an **agentic turn** * an **agentic workflow** An **agentic turn** is one execution of the same instructions and runtime configuration within a conversation. The client sends the user's current message, the AI Orchestrator applies the configured context, use case instructions, model path, tools, policies, and relevant conversation history, and the client receives the final model response. Agentic turns are useful when the same use case should power a simple repeated interaction, such as: * answering a product question * guiding a user through a decision * retrieving information with a tool * generating a recommendation * responding inside an embedded assistant An **agentic workflow** is a multi-step execution managed by the AI Orchestrator. The workflow can run through multiple configured steps, where each step can have its own instructions, tool access, model settings, artifact handling, checkpoint behavior, and handoff from the previous step. Agentic workflows are useful when the job benefits from staged execution, such as: * collecting facts before drafting an answer * querying tools before creating an artifact * generating content and then revising it * pausing for user approval before continuing * producing structured outputs through multiple model/tool passes The difference is where the step coordination lives. You could string together multiple agentic turns from a client, but then the client would need to manage the intermediate responses, decide what prompt to send next, preserve the right context, and pass output from one turn into the next. With an agentic workflow, the client still receives the final response, but the AI Orchestrator manages the intermediate steps, prompt context, previous-step handoff, artifacts, checkpoints, and runtime trace. An agentic use case is not just a prompt. It is the executable runtime configuration for that stage of the journey. Over time, multiple agentic use cases can work together inside the same broader journey. For example, one use case may create a campaign, another may review performance, and another may recommend optimizations. Each use case remains focused, while the shared context and conversation can connect them into a larger agentic experience. ## Conversation A **conversation** is the durable thread that connects user messages, assistant responses, workflow runs, and memory context over time. Clients provide a conversation ID so the AI Orchestrator can store and rehydrate relevant history when a future turn or workflow needs context. AI Presence can use the same identity and conversation signals to analyze engagement across the broader relationship. This lets a product experience move beyond isolated prompts. The client can send the current user message, while the platform preserves the conversation history needed to make future responses more context-aware. ## AI Orchestrator **AI Orchestrator** is the API service that executes an agentic use case. It can be called by any authorized client, including an application, website, backend service, automation job, or another AI-enabled system. The client only needs an API key and the agentic use case it wants to run. AI Orchestrator sits at the center of the runtime path between the client, the selected AI model, and the tools available to that model. It is responsible for: * resolving the agentic use case * selecting the runtime path * using the configured model * attaching tools and MCP servers * applying policies and runtime controls * storing and rehydrating conversation history when context is needed for future runs * storing workflow artifacts so later steps or later runs can continue from the current state * coordinating workflow steps when the use case is an agentic workflow * returning the final response to the client This is the layer that conducts the AI journey. The client asks for an outcome; AI Orchestrator handles the configured model, tools, instructions, policies, workflow behavior, conversation context, and artifact state needed to produce it. See the [Orchestrator API reference](/tagit/reference/reference/api/orchestrator.md) for request and response details. ## Artifact An **artifact** is structured output that an agentic workflow creates, updates, and persists across steps or runs. Artifacts are useful when the AI is building something durable, such as a plan, recommendation, report, brief, configuration, or working document. Instead of treating every model response as disposable chat text, the workflow can maintain a current artifact that later steps can refine. This is especially important for workflows where the final value is not just an answer, but a reusable output that should survive beyond a single model call. ## Run and execution trace A **run** is one execution of an agentic use case. For an agentic turn, a run usually contains one model response. For an agentic workflow, a run can include multiple steps, tool calls, artifacts, checkpoints, and handoffs between steps. An **execution trace** records what happened during the run. It can include setup timing, prompt assembly, model calls, tool calls, artifact updates, persistence steps, errors, and the final response. Execution traces are important for implementation teams because they make AI behavior inspectable. Product, operations, and AI teams can use traces to understand what the system did, debug failures, verify tool usage, and tune workflows over time. ## AI Presence **AI Presence** is an optional data collection and intelligence service for AI engagement. It is designed to capture conversations that happen through the AI Orchestrator, as well as AI or non-AI engagement signals that happen outside the orchestrator. AI Presence uses the tagIt data collection backbone to capture deterministic identity, events, and journey activity across digital surfaces. This allows teams to build a unified view of AI and non-AI engagement, instead of treating the embedded AI surface as an isolated channel. AI Presence can enrich captured signals with additional context, such as geography and device information. For AI conversations, it can also route conversation signals through the Presence engine to infer user intent and identify patterns that should shape future engagement policy. Those policies can become new or updated instructions that guide how the model should respond in later interactions. AI Presence is not required to call the AI Orchestrator. It is an add-on for teams that want richer conversation analytics, journey intelligence, and a feedback loop between what users do and how future AI experiences should behave. See the [Collector API reference](/tagit/reference/reference/api/collector.md) for event and identity collection details. ## AI Canvas **AI Canvas** is a web client compatible with AI Orchestrator and AI Presence. It gives teams a ready-to-use client experience for embedding a chat client into a website or application, while also serving as a reference implementation for teams that want to build their own client against the AI Orchestrator API or AI Presence API. AI Canvas handles the user-facing interaction pattern, such as an embedded assistant, overlay, docked panel, or guided AI surface. It connects the front-end experience to the AI Orchestrator, sends the selected agentic use case request, and renders the response for the user. When AI Presence is enabled, AI Canvas can also emit identity and engagement events to the Collector API so AI conversations and non-AI interactions can be analyzed together. Teams can use AI Canvas to get started quickly, or use the [AI client reference](/tagit/reference/reference/ai-client.md) as the implementation guide for building a custom client. ## AI client The **AI client** is the embeddable front-end integration used to bring tagIt experiences into a product. It can power: * inline assistants * overlays * docked sidebars * guided AI surfaces The AI client connects the front-end experience to the orchestrator runtime. ## MCP server An **MCP server** is a tool source the orchestrator can connect to. It gives a use case access to external capabilities such as: * product catalog lookup * pricing retrieval * comparison tools * policy or FAQ retrieval * workflow actions Not every use case needs the same MCP tools. One of the strengths of tagIt is that different stages of the journey can use different toolsets. ## Model path A **model path** is the provider/model combination selected for a use case. In practice, this is the specific AI model route the orchestrator will use when executing that use case. Each use case has one model path, while MCP tools remain optional. ## Intent An **intent** is a structured interpretation of what a user is signaling in a conversation. Examples include: * wanting more context * asking for examples * being concerned about cost * being ready for the next step Intent helps teams understand where a user may be in a journey and what kind of engagement might help move them forward. ## Memory candidate A **memory candidate** is a conversation signal that should be considered for longer-lived memory. Not every conversational turn needs to become memory. Memory candidates are the turns the system believes may matter later for personalization, policy, or relationship understanding. ## Relationship intelligence **Relationship intelligence** is the evolving understanding tagIt builds about a user or relationship over time. It is formed from conversation signals, classified intent, and memory aggregation. This is what allows the system to move from isolated interactions to more informed future engagement. ## Engagement policy An **engagement policy** is guidance derived from observed behavior, inferred intent, or relationship intelligence that can shape future orchestration. It can shape how the AI behaves in future interactions, for example by encouraging it to: * be more direct * provide more detail * avoid certain tones * offer clearer next steps This is one of the key bridges between Presence and Orchestration. ## Snapshot A **snapshot** is a saved orchestration version for a use case. It captures a specific runtime configuration that can be tested, saved, and published. This lets teams move from draft configuration to a stable production version. ## Published use case A **published use case** is the production-ready version of a use case that the orchestrator should resolve by default. This is the version that typically powers the live embedded experience. ## In one mental model If you only remember one thing, use this: * **Context** = the workspace that defines where the AI operates, what rules it inherits, and what governance applies * **Conversation** = the durable thread that connects messages, history, and future context * **Agentic use case** = what the AI is doing right now * **Artifact** = the durable output an agentic workflow can build and refine * **AI Orchestrator** = how the journey runs * **AI Canvas** = how the journey is experienced * **AI Presence** = how the journey learns and improves over time --- # 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/concepts.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.