> ## Documentation Index > Fetch the complete documentation index at: https://docs.vh3.ai/llms.txt > Use this file to discover all available pages before exploring further. # Connie > VH3 AI's flagship operations agent with long-running context, evidenced answers, and efficient use of your intelligence layer # Connie Connie is VH3 AI's flagship conversational agent: a field service operations specialist wired into your full intelligence layer. She reads the same enriched operational model as search, sentinels, reports, and automations, and she is built for real work: multi-turn reviews, account prep, diagnostics, and follow-through that depends on what was said five minutes ago. How operators brief Connie: three principles, role playbooks, and session habits. Start here if you have not used Connie before. Fast precedent search and entity resolution (no LLM). Connie calls these when she needs facts; she synthesises when you need narrative. How to verify Connie's answers: tool outputs, citations, usage, and structured evidence. Connie handles ambiguous questions and short prompts well. For operator habits that get the most out of her on harder asks, see [Working with your operation](/guides/working-with-your-operation). ## Connie on the harness VH3 AI separates **discovery** from **synthesis**. Discovery handles fast lookup: search, autocomplete, feeds, and customer knowledge sections. Connie handles synthesis: explaining, comparing, investigating, briefing, and recommending with citations. Connie is disciplined about when to spend tokens. Simple greetings and meta questions can be answered without a full tool loop. Analytical questions trigger the right operational tools. Heavy diagnostic work routes to investigation flows that return structured evidence, not guesswork. That split is what makes the agent practical at scale: the expensive interpretation runs on **prepared** data (enriched once at ingest), not on re-reading raw field system exports every turn. ## Sessions: focused, managed, and recoverable A Connie session is a conversation about one thing. Keep them concise and to the point. When the topic changes, start a new session. Shorter, focused sessions perform better in three measurable ways: * **Economics.** Token cost grows with the context you carry into each turn. A 40-turn thread that has wandered across three customers spends tokens re-reading its own history. A focused session does not. * **Recall and answer quality.** A focused session keeps the model on the question. Long, drifting threads encourage the model to mix unrelated context into the answer. * **Auditability.** Sessions are managed: stored, recoverable, searchable, and citable. A session per topic gives you a clean record of what was asked, what was answered, and what evidence was used. **Session IDs are issued by the platform.** Do not invent them. Omit `session_id` on the first turn; the response returns a UUID to use on every subsequent turn in that thread. Between topics, drop the ID and let the platform issue a new one. **Between sessions, start fresh.** A new topic, a new account, a new day's standup: omit the ID. Connie loads the right opening context (see below) automatically; you do not carry over yesterday's context or its token cost. ### How to start and continue a session First turn, no `session_id`: ```json theme={null} { "company_id": "your-company-id", "api_key": "your-api-key", "message": "What recurring issues have we seen here in the last 90 days?", "contact_id": "12345", "user_name": "Sarah" } ``` The response includes a `session_id` UUID. Pass it on every follow-up: ```json theme={null} { "company_id": "your-company-id", "api_key": "your-api-key", "message": "Which engineer has the best completion rate on those jobs?", "session_id": "a1b2c3d4-e5f6-...", "contact_id": "12345" } ``` When the topic changes, omit `session_id` again. The platform issues a new one. ### Opening context on new sessions When you start a session with a customer in scope, the server can inject: * **Company operating context** (terminology, rules, and preferences your organisation configured). * **Customer Summary** plus **recent completed jobs** since that summary was generated, so turn one is not stale. You can still pass a `summary` from your app; the server enriches it when possible and reports how that block was built (see [Agent observability](/guides/agent-observability)). ### Recovery and search Sessions are durable. Past sessions can be retrieved, listed, and searched via the [Connie API](/api-reference/connie). Start new threads freely; the platform preserves previous sessions as evidence. ### Contact-scoped by default From a customer or job view, Connie defaults queries to that contact unless you ask a company-wide question. That matches how account managers and coordinators actually work, and it is another reason starting a new session per topic stays cheap: each one starts with the right scope already set. ## Memory that compounds Connie benefits from the same **operational memory** as the rest of the platform: * Jobs are **enriched once** (fault patterns, outcomes, links to customer, site, engineer, equipment). * **Customer Summary** knowledge is stored in modular sections and refreshed on schedule or when job drift thresholds are met. * **Tool outputs** from substantive calls in a session can be retained and recalled within that session so she does not repeat expensive lookups on follow-up turns. * **Background compaction** runs on longer sessions: the platform periodically summarises earlier turns into a compact form so recall stays sharp without carrying the full raw history forward on every message. This is **your organisation's intelligence layer getting richer continuously** and Connie reading that layer on every turn, including what happened earlier in the session. ## Efficient token use Connie is built for production economics (especially with [BYOK](/pricing)): * **Intent routing** classifies messages so lightweight turns can skip the full agent and tool suite. * **Company-level prompt caching.** Shared company context (instruction blocks, tool definitions, organisation operating context) is cached across all users in your organisation. Every person on the team benefits from cache hits that earlier sessions already warmed. `cacheReadTokens` in the usage response shows how much of each turn was served from cache. * **Compact tool results for efficient chat.** Feeds, search, and aggregates return trimmed shapes so the model is not fed empty fields and nested noise. Semantic search hits include `contactName`, `jobRef`, and visit dates so answers can name sites and cite references without extra lookups. * **Discovery-first tools** (`search_outcomes`, `jobs_aggregate`, `job_feed`, autocomplete, customer summary sections) handle lookups without running narrative investigation unless the question requires it. Every chat response includes **usage** (`inputTokens`, `outputTokens`, `cacheReadTokens`, `cacheCreationTokens`) so you can see what a turn cost on your provider account. ## Fully evidenced answers Connie is instructed to **cite job references and names**, never internal database IDs in user-facing text. Behind the narrative: * **Investigation** returns headline findings, ranked recommendations, confidence, and **evidence** tied to real job references. * **Search and feed tools** return graph-linked records, not orphaned text snippets. * **`toolCallOutputs`** on the API response exposes the structured JSON from each tool invocation in that turn, so your UI can render tables, charts, and drill-downs from evidence. If a tool fails, she is instructed to say so and offer another angle, not invent numbers. Treat the assistant message as the summary. Use `toolCallOutputs`, job references in the text, and your own drill-down into discovery endpoints as the source of truth for anything that affects commercial or safety decisions. ## What Connie can do Connie can answer any question the underlying data supports. Examples by shape of work: ### Performance and trends * "Which engineers had the best first-time-fix rate this quarter?" * "How is Mike performing compared to last month?" * "Show me the top five engineers by SLA punctuality." * "How many jobs did we complete yesterday versus the same day last week?" ### Sites and customers * "What happened at the Manchester site last week?" * "Which customers have the most repeat visits?" * "Give me the job history for this account." * "How does this customer's failure rate compare to the company average?" ### Diagnostic and precedent * "Has anyone seen this fault before?" (with a description) * "What usually fixes a boiler intermittent lockout?" * "Find similar jobs to this one." * "Why are roofing jobs running late?" (investigation-style synthesis) ### Operational actions (where enabled) Depending on your setup and integrations, Connie can also drive **email drafts**, **notifications**, **briefings**, **account reports**, **presentations**, and lookups into connected systems (CRM, mail) through the same connected platform capabilities. See the [Connie API](/api-reference/connie) for endpoints and fields. ## Working on your behalf (without a prompt) Most of Connie's value lands without anyone typing. Connie reads the same signals the platform watches continuously, so she can pick up work before the operator asks. * **Sentinels** detect patterns 24/7 with near-zero AI cost at detection: repeat visits, SLA drift, dormant customers, performance slips. See [Sentinels](/guides/sentinels). * **Cases** turn signals into owned work with status, participants, and linked jobs. Connie can open a case for a sentinel trigger, attach the relevant evidence, and draft the brief the assignee will read. * **Teams** route cases to the right people: regional, portfolio, or functional groups own customers and sites so nothing sits in a generic queue. A typical autonomous loop: 1. Sentinel flags repeat HVAC callouts at an account. 2. Automation opens a case, runs discovery for similar precedents, and asks Connie for a draft brief. 3. The regional team finds the case ready, with citations, when they next look at the queue. The operator's job is to steer and verify, not to push the platform into motion. Autonomous loops depend on your tier, enabled integrations, and configured case/team rules. During onboarding, decide which sentinel findings should create cases automatically and which should stay as digest items for human review. ## Specialist capabilities Connie orchestrates **focused sub-tasks handled automatically** for specialist work (for example structured email generation and deeper analytical passes). You interact with one assistant; the platform routes complex sub-tasks without you managing multiple agents. ## Tips for effective questions "Last 30 days" beats "recently." Connie infers ranges when she can, but explicit dates reduce ambiguity. Use engineer names, site addresses, or customer names when you know them. Autocomplete resolves fuzzy input; exact names are faster. Same `session_id` for the same topic. "Tell me more about the third one" or "What caused that?" When the topic changes, start a new session. Ask for tables, comparisons, or bullet recommendations. "Compare Mike and Sarah this quarter" works well. ## Field service playbook | You want | Example prompt | What Connie typically does | | ------------ | -------------------------------------------------------- | ------------------------------------------ | | Quick count | "How many completed jobs last week?" | Aggregation with sensible time axis | | Account prep | "Summarise risk for this customer" | Customer summary + recent jobs + synthesis | | Precedent | "Similar callouts for intermittent lockout" | Semantic search on outcomes or intake | | Root cause | "Why is SLA slipping in the North?" | Investigation with cited evidence | | Briefing | "What should the engineer know before tomorrow's visit?" | Job detail, weather, history, narrative | ## Building with Connie | Surface | Best for | | --------------- | -------------------------------------------------------------------------- | | **VH3 Connect** | Embedded ops UI with generative components from `toolCallOutputs` | | **API** | Custom portals, mobile, partner apps | | **MCP** | Claude Desktop, Cursor, coding agents ([MCP setup](/agent-kits/mcp-setup)) | | **n8n** | Slack or Teams assistants ([n8n Agent Prompts](/agent-kits/n8n-agents)) | Use [Agent observability](/guides/agent-observability) when you build UIs or compliance workflows that must show **why** an answer was given. ## Related Request fields, sessions, voice, and history search. Why relational, semantic, structured, and temporal memory matter. Discovery vs synthesis for builders and integrators. Tenant keys, JWT for interactive apps, BYOK.