# Presence architecture

AI Presence is the observation and intelligence plane for tagIt.

It is separate from the direct AI Orchestrator execution path. The AI Orchestrator runs agentic use cases. AI Presence captures engagement signals, enriches them, interprets them, and helps teams understand how future AI experiences should adapt.

```
AI client -> Collector API -> AI Presence
                         -> identity
                         -> AI conversation events
                         -> non-AI engagement events
                         -> intent
                         -> relationship intelligence
                         -> engagement policy
                         -> future orchestration
```

For term definitions, see [Concepts](/tagit/getting-started/concepts.md). For setup steps, see [Set up AI Presence](/tagit/guides/guides/set-up-ai-presence.md). For event and identity collection details, see the [Collector API reference](/tagit/reference/reference/api/collector.md). This page focuses on how AI Presence fits into the runtime architecture.

## Runtime relationship

AI Presence is not called by the AI model, and it is not required for the AI Orchestrator to generate a response.

Instead, the AI client can send collection events independently of the Orchestrator request. For example, a web client may:

* send a user message to the AI Orchestrator
* render the assistant response
* send conversation and engagement events to the Collector API
* also send non-AI events, such as page views, clicks, product views, form starts, or conversions

This lets AI Presence observe the broader journey, not just the model response.

## Client and collector flow

The AI client is the main integration point between the application and AI Presence.

When Presence is enabled, the client can emit events to the Collector API with deterministic identity and context. These events can include:

* user identifiers
* conversation identifiers
* account and context identifiers
* AI message events
* journey events outside the AI surface
* device and browser context
* page and referrer context

The Collector API receives those events and routes them into the tagIt data collection backbone for enrichment, storage, and downstream Presence processing.

See the [Collector API reference](/tagit/reference/reference/api/collector.md) for event payloads, identity fields, and collection endpoint details.

## Unified identity

AI Presence depends on consistent identity.

The same user and conversation identifiers should be used across the AI client, Collector API, and AI Orchestrator when possible. This allows tagIt to connect:

* what the user did outside the AI surface
* what the user asked inside the AI surface
* how the assistant responded
* whether the user continued, converted, abandoned, or returned

That unified view is what allows teams to analyze AI and non-AI engagement as one journey instead of separate channels.

See [Entities and Identifiers](/tagit/reference/reference/api/collector/entities.md) for identity concepts used by the Collector API.

## Signal enrichment

Collector events can be enriched with additional context, such as:

* geography
* device information
* browser information
* traffic source
* page context
* session context

This helps teams understand not only what users say, but also where, when, and how they engage.

## Presence intelligence

AI Presence can route AI conversation signals through the Presence engine to infer higher-level meaning.

That can include:

* user intent
* journey stage
* recurring objections
* product interest
* support needs
* buying signals
* relationship-level patterns

The goal is not just to store transcripts. The goal is to turn AI and non-AI engagement into insight that product, operations, and AI teams can act on.

## Engagement policy

The main connection point back to the AI Orchestrator is [engagement policy](/tagit/getting-started/concepts.md#engagement-policy).

Engagement policy is guidance derived from observed behavior, inferred intent, or relationship intelligence. It can shape how future AI experiences should behave.

For example, Presence might reveal that a user consistently asks for technical implementation detail, compares pricing, or abandons when responses become too generic. Those patterns can inform future instructions, guardrails, or routing decisions for agentic use cases.

AI Presence does not need to sit inside the model call to be useful. Its value is in the feedback loop:

1. observe engagement
2. infer intent and relationship patterns
3. produce policy or instruction guidance
4. improve future orchestration

## Example flow

1. A user opens an AI Canvas assistant inside a website.
2. AI Canvas sends the current message to the AI Orchestrator.
3. AI Canvas also sends conversation and identity events to the Collector API.
4. The user clicks, navigates, views content, or converts outside the AI surface.
5. The client sends those non-AI engagement events to the Collector API.
6. AI Presence connects the AI and non-AI signals through unified identity.
7. Presence infers intent and relationship intelligence.
8. Those insights can inform engagement policy for future agentic use cases.

## Why this architecture matters

This architecture separates observation from execution:

* AI Orchestrator executes the configured agentic use case
* AI client presents the experience and emits engagement signals
* Collector API captures deterministic identity and events
* AI Presence interprets the journey
* engagement policy feeds future orchestration

That separation keeps the AI runtime focused while still giving teams a way to learn from real user behavior across the full digital journey.


---

# 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/presence-architecture.md?ask=<question>
```

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.