Technical overview / VibeAI

Document: VT-AI-01Revision: 1.0 Implemented architecture

VibeAI AI Integration Architecture

An OS-level assistant architecture that turns user intent into governed model responses, validated action proposals, and scoped delegation across VibeOS applications.

01

AI Integration Architecture

Assistant, model, validation, application, and access boundaries

VibeAI integration architecture Implemented architecture

VibeOS Interface

OS-level assistant entry point available from the desktop, dock, glass window, and focused AI input event

Dock triggerAssistant panelPrompt hand-offConversation UI

Access & Usage Controls

Plan-aware AI access and usage checks sit between the VibeOS interface and the orchestration layer, blocking or allowing assistant requests before model or app work proceeds

AI access eventsUsage interceptUpsell stateServer checks

Orchestration & Translation Layer

Transforms user intent into governed assistant responses, validated actions, and delegated app-specific prompts

System promptAction parserSchema validationDelegation

AI Model

Gemini, OpenAI, or another approved model produces assistant text and structured action proposals

Chat endpointModel selectionToken budgetStreaming-ready boundary

VibeOS Applications

Built-in apps receive only validated action requests or delegated prompts scoped to their own capability surface

WriteDataCodeApp AI panels
Runtime boundary. The assistant can propose actions. VibeOS only executes actions that pass the access, policy, and schema validation boundaries.
Figure 1 — VibeAI implementation of the AI Integration Architecture. The assistant sits above model output and application execution rather than giving the model direct operating authority.
02

Assistant, model & app services

Implemented components behind VibeAI

OS assistant surface

VibeAI is available as an operating-system level assistant rather than a standalone App Center entry, with dock and panel access inside VibeOS.

aiassistant / always-pinned access

Prompt hand-off

Prompts can originate in the assistant panel or be handed to VibeAI from another application through a focused AI input event.

vibeos-focus-ai-input

AI model

Gemini, OpenAI, or another approved model returns assistant guidance and optional structured action proposals from the server model boundary.

Approved model boundary

Action syntax

Model output can include bracketed action tuples that are extracted from the readable assistant response before execution is considered.

[[ACTION:...]] parser

Policy validation

Every parsed action is checked against the assistant panel's schema policy before any application receives it.

validateAction / assistantPolicies

Application delegation

Approved delegate-to-app requests pass only an app ID and scoped prompt to the target application's own AI surface.

delegateToAppAI

03

Assistant decision lifecycle

From desktop prompt to validated action

  1. 01

    Invoke

    The user opens the dock-pinned assistant or another VibeOS surface focuses VibeAI with a pending prompt.

  2. 02

    Capture

    The assistant panel records the user's prompt, panel context, selected model, and any external hand-off state.

  3. 03

    Authorize

    AI access and plan state are checked before a request is allowed to reach the model boundary.

  4. 04

    Constrain

    System instructions define the assistant's scope, response expectations, application actions, and required action syntax.

  5. 05

    Respond

    The selected model returns natural-language guidance and may include structured action proposals in the approved bracket format.

  6. 06

    Extract

    The assistant separates readable text from action tags and normalizes the parsed action name and arguments.

  7. 07

    Validate

    Each action tuple is checked against the assistant panel schema; invalid actions are rejected with an explicit assistant-facing marker.

  8. 08

    Delegate

    Allowed app delegation routes an app ID plus scoped prompt to the relevant application AI panel instead of giving the model direct control.

  9. 09

    Execute

    Application code handles approved actions through its own UI and capability boundaries.

  10. 10

    Record

    The assistant preserves response state, errors, selected model state, and pending prompt state for the active desktop session.

04

Agent decision network

Detailed flow inside VibeAI's orchestration and action layer

Agent decision network Prompt-to-action execution

Assistant Invocation

The user opens VibeAI directly or a system event focuses the assistant input from elsewhere in VibeOS

aiassistantDock pinFocus event

Prompt Capture & Pending Hand-off

Typed prompts and external app hand-offs are collected before the assistant panel starts the model exchange

Prompt queuePanel contextDurable hand-off

Access Gate

AI access state is checked so unavailable plans stop before sending a model request

Plan stateUsage interceptVibeAI context

System Contract Assembly

The assistant prompt defines the operating context, available app actions, output expectations, and safe action syntax

System promptAssistant policyAction grammar

Model Response

The selected model returns natural-language guidance and optional bracketed action proposals

GeminiOpenAIAssistant text

Action Tag Extraction

Structured [[ACTION:...]] tuples are parsed from the model response while the readable answer remains available to the user

Action parserFallback parserDisplay copy

Panel Policy Validation

Every parsed action is checked against the assistant panel's approved schemas before anything can run

validateActionassistant policyReject prefix

Delegation Router

Allowed delegation requests carry an app ID and scoped prompt into the appropriate application AI surface

delegateToAppAIappIdScoped prompt

Action Execution or Rejection

Accepted actions continue through application handlers; rejected actions are returned as explicit assistant feedback

Run approved actionReject invalid actionVisible trace

Conversation State

The assistant view records the response, errors, pending prompt state, selected model, and user-visible AI status

Chat stateModel settingAI errorsAccess state
Runtime boundary. Model output is not direct operating-system authority. Every action proposal is parsed, checked, scoped, and either routed to an application surface or rejected.
Figure 2 — Verified prompt-to-action path. Bracketed model actions are proposals until the assistant policy validates and routes them.
05

Responsibility & trust boundaries

Authority by implementation component

VibeAI assistant

Responsible for

Prompt capture, assistant conversation display, pending hand-offs, response state, and user-facing AI status

Not responsible for

Not responsible for directly modifying another app without a validated action or scoped delegation

AI model

Responsible for

Assistant wording and proposed structured actions based on the provided system contract

Not responsible for

Not responsible for executing actions, reading private app state directly, or bypassing validation

Orchestration & translation

Responsible for

System prompt assembly, action extraction, schema validation, rejection handling, and delegation routing

Not responsible for

Not responsible for acting outside the assistant panel's approved action policy

VibeOS applications

Responsible for

Their own app-specific AI panels, handlers, document/data/code state, and accepted delegated prompts

Not responsible for

Not responsible for accepting unscoped model text as executable system authority

Access controls

Responsible for

Plan-aware AI availability, usage checks, and unavailable-state presentation

Not responsible for

Not responsible for changing the model's answer after a request is approved

06

Validation & access controls

Implemented safeguards around model output and app delegation

Access gating

AI requests can be blocked before model execution when access or plan state does not allow the assistant flow to proceed.

AI usage intercept

Action schema checks

The assistant validates every parsed action against panel-specific schemas before routing or execution.

Reject invalid tuples

Scoped delegation

Delegation requires a target app ID and prompt, keeping app-level work inside the receiving app's AI boundary.

App-level authority

Readable response separation

User-facing guidance remains visible even when an action tag is rejected or cannot be executed.

Text plus action channel

Selectable model boundary

Model selection is an explicit state change rather than a hidden execution path.

Model-change event

Explicit failure feedback

Rejected actions, unavailable AI access, and model errors are surfaced instead of silently mutating app state.

Visible assistant state

Failure behavior: blocked AI access, model errors, unparsable action tags, schema mismatches, and unsupported app delegation return explicit assistant feedback instead of silently changing application state.
07

Assistant state & records

What VibeAI tracks during the desktop assistant session

Assistant panel state

Current conversation view, response text, loading state, model errors, and selected model state for the active desktop experience

Pending prompts

Hand-off prompts sent to VibeAI from outside the panel before the assistant is focused

Action outcomes

Accepted action requests continue through app handlers; rejected actions are returned with explicit rejection feedback

AI access state

Availability signals and plan-aware blocked states used to determine whether VibeAI can send a model request

Application hand-offs

Scoped app ID and prompt pairs sent to app-specific AI surfaces when delegation is approved

Persistent history

The reviewed implementation preserves active assistant state, while durable long-term assistant memory is not presented as the system of record