Central service for connecting AI agents to our websites. It stores websites, agents, and chats, facilitates communication between visitors and the agent, and allows managers to participate. Additionally, it receives raw events from websites for subsequent analysis by the agents.

Unified AI agents and chats service for our websites.

AI Agents Center

Implement the core entities and API of the central service: our websites, associated agents, dialogs, and messages. The website agent should operate through this service rather than as a separate independent system.

Central storage for websites, agents, dialogs, and messages.

Build the core of the agents and dialogs service

Implement client-side integration for our websites: a visitor opens a chat on the site, messages are sent to the central agent, and responses are returned to the website interface. Connecting a new website should require minimal manual configuration.

Create a simple way to connect our websites to the central service.

Connect an AI agent to websites

Create an interface where active and past visitor dialogs with the agent can be viewed. A manager must be able to stop automated responses, continue the conversation manually, and then return control to the agent.

Personal account for viewing dialogs and human participation.

Implement dialog management and manager takeover

Store the list of our connected websites, their agents, and core context. The central agent needs the ability to understand which websites and agents exist and to communicate with the appropriate agent.

A unified internal directory of connected websites and their agents.

Add website and agent directory

Add a simple API for receiving raw events from our websites: page views, sessions, user actions, and dialog events. Save the data for subsequent analysis by AI agents; do not build a separate traditional analytics system for now.

Accept visit and action events without building a separate analytics system.

Collect raw events from websites

# Implement a custom AI dialog engine with dynamic scenarios

## Context
The "AI Agent Center" project must have its own dialog subsystem. It cannot be built on n8n, Make, ready-made chatbot/workflow builders, or similar systems where the core dialog logic is executed by an external engine.

We need to implement our own core that accepts an external description of a complex scenario, guides the user through it dynamically, and returns the result. Each user dialog must exist and be computed as a separate, independent entity with its own state, history, and result.

## Goal
Create a universal AI dialog execution service that can be used by various websites and agents without hardcoding specific scenarios into the application code.

The service must be able to:
- accept a dialog scenario externally;
- create a separate session/dialog for a specific user;
- determine the next step dynamically on each message based on the scenario, accumulated state, and user response;
- call the LLM where required by the logic;
- store dialog state and history;
- complete the dialog with a formalized result;
- concurrently serve many users and many independent dialogs.

## Key Architectural Principle
**The scenario is data, not the code of a specific chat.**

The dialog engine must be universal. An external system passes a declarative scenario description to it, and the runtime interprets it and manages transitions.

It should not be necessary to program a new backend flow for each new scenario.

## What to Implement

### 1. Scenario Model
Design a scenario format that can be transmitted via API and stored with versioning.

At a minimum, it must include:
- scenario identifier and version;
- starting point;
- steps/nodes;
- system instructions for the LLM;
- expected user data;
- conditions and branching;
- transitions between steps;
- intermediate variables/context;
- computed values;
- pre/post-step actions;
- completion conditions;
- final result schema.

The scenario must support not only linear question chains, but also dynamic branching.

### 2. Dialog Runtime
Implement a custom scenario execution machine.

On each incoming message, the runtime must:
1. load the state of the specific dialog;
2. determine the current scenario node;
3. process user input;
4. call the LLM if necessary;
5. validate/normalize the received data;
6. compute transition conditions;
7. update the state;
8. generate the next response;
9. save the history and new state atomically;
10. return the response and execution technical state externally.

Transition logic must be executed inside our service, not within an external workflow engine.

### 3. Dialog State
Store each dialog separately.

At a minimum, the following must be provided:
- `dialogId`;
- tenant/site/agent/user identifiers;
- scenarioId + scenarioVersion;
- current node;
- accumulated state / variables;
- message history;
- LLM call results required for reproducibility;
- status: active / completed / failed / cancelled;
- timestamps;
- final structured result.

A single user can have multiple independent dialogs.

### 4. Multi-user Mode
The service must function correctly under concurrent dialogs from different users and sites.

It is mandatory to provide:
- state isolation per dialog;
- absence of global mutable state between users;
- protection against simultaneous processing of two messages in the same dialog;
- idempotency for message redelivery;
- horizontal scalability across multiple runtime instances;
- tenant/site isolation at the API and data storage levels.

### 5. External API
A clear programmatic contract is needed for external systems.

Minimum set of operations:
- register/update a scenario version;
- create a dialog based on a scenario;
- send a message to a specific dialog;
- get current state/status;
- get history;
- get the final result;
- cancel/close the dialog.

The response to `sendMessage` must contain not only the text for the user, but also a machine-readable part when necessary:
- status;
- current/next step;
- extracted values;
- result upon completion;
- technical execution metadata.

### 6. Working with LLMs
The LLM is part of the runtime, but should not itself be the sole flow control source.

It is necessary to separate:
- deterministic transition logic;
- data extraction/classification via LLM;
- response text generation;
- validation of structured model responses.

For structured operations, use schema-constrained output and mandatory model result validation.

Handle the following:
- timeouts;
- malformed output;
- retries;
- fallbacks;
- rate limits;
- provider errors.

### 7. Versioning and Reproducibility
A running dialog must continue to execute on the scenario version it was created with, even if a new version is published later.

It is forbidden to change the semantics of an ongoing dialog via silent scenario updates.

### 8. Observability
Store a technical trace for each step:
- input;
- selected node;
- decision made;
- transition;
- model calls;
- latency;
- errors;
- token/cost usage, if available;
- step outcome.

This should allow investigating why a specific dialog took a certain branch.

### 9. Scenario Execution Security
An external scenario must not allow the execution of arbitrary code on the server.

Conditions, expressions, and actions must be executed via a restricted DSL/set of allowed operations.

`eval` or arbitrary JavaScript from the submitted scenario must not be used.

## What is Out of Scope for This Task
- visual scenario builder;
- operator/manager UI;
- chat widget on a specific website;
- CRM integrations as a separate large layer;
- analytical BI dashboard;
- workflow building on n8n/Make and similar products.

These parts may use the dialog runtime later, but must not dictate its architecture.

## Minimum Verification Scenario
For acceptance, implement at least one scenario that confirms the dynamic operation of the engine:
- multiple questions;
- at least one conditional branch;
- extraction of a structured value via LLM;
- returning to a clarifying question when data is insufficient;
- completion with a machine-readable result.

Simultaneously launch multiple dialogs using the same scenario with different responses and confirm that states and results do not mix.

## Definition of Done
- The dialog runtime is written by us and does not depend on an external workflow engine.
- A new scenario can be passed via the external contract without modifying the runtime code.
- Non-linear branching and dynamic transitions are supported.
- Each dialog has an independent persistent state.
- A single user can have multiple dialogs, and the service can concurrently serve many users/sites.
- Protection against race conditions and message redelivery is implemented.
- The scenario version is fixed for the lifetime of the dialog.
- The final result is available in a structured format.
- Traces make it possible to understand how and why each step was executed.
- The verification scenario passes end-to-end and confirms the isolation of parallel dialogs.

Build a multi-user dialog runtime from scratch without n8n or similar workflow solutions, featuring externally defined complex scenarios and independent state for each dialog.

Implement a custom AI dialog engine with dynamic scenarios

# Create your own embedded chat widget

## Objective
Create a minimal custom chat UI that can be embedded into our websites and connected to the already implemented server-side HTTP/agent layer without using the old interface as a permanent solution.

## What to Implement
- a simple way to embed the widget on a website with minimal manual configuration;
- sending user messages to the central service;
- streaming display of the agent's response;
- a Stop button with actual cancellation of the current execution;
- correct UI states for started / streaming / done / error / cancelled;
- basic transmission of the website identifier and page context;
- defining a visitor/session identification contract without mixing the states of different tabs and users;
- defining CORS and the access model for the public HTTP endpoint for the external widget;
- testing operation through a real proxy path, not just directly to the application.

## Out of Scope for the Minimum Viable Phase
- manager dashboard;
- full conversation history in the UI;
- complex analytics;
- visual agent builder.

## Definition of Done
- the widget connects to at least one test website without using the legacy chat;
- responses are streamed;
- Stop actually cancels the server-side execution;
- parallel visitors do not mix states;
- streaming and cancellation have been tested through a working Traefik/Varnish/proxy path;
- the connection contract is documented so that the next website can be added without modifying the core.

A minimal widget for connecting to websites via a central agent with streaming responses and Stop functionality.

Create your own embedded chat widget

# User Admin Panel and JWT Token Management

## Context
The main subsequent goal is to manage JWT tokens, which are used to identify the user to whom a message is addressed.

Server requests for working with users already exist. As part of the first stage, do not refactor the user backend.

## First Stage — To Be Completed Now
Create a user management admin panel:

- user list;
- "Add user" action;
- ability to open a user card;
- user editing;
- use existing GraphQL queries and mutations;
- add client-side GraphQL operations and regenerate types.

## UI-kit
Along the way, start building a custom `ui-kit` on top of the already installed React Aria:

- use React Aria as a headless foundation;
- implement each UI component required by the application as a separate component in `ui-kit`;
- immediately add a Storybook story for each new component;
- use components from `ui-kit` in product screens rather than React Aria directly.

## Next Stage — JWT Tokens
Following the user admin panel, add management for JWT tokens intended to identify the user to whom a message is sent. Do not mix this task with the existing login and session logic.

## Technical Notes
- Hot reload is already working, no separate configuration is needed.
- React Aria is already installed.
- User CRUD backend already exists.

## First Stage Acceptance Criteria
From the interface, the administrator can view users, add a user, open an existing user, and modify their data. Client-side GraphQL operations have been added, types are successfully regenerated, and the UI elements used are structured via `ui-kit` and have Storybook stories.

Create a user management admin panel and lay the UI foundation for subsequent management of user identification JWT tokens.

Add user management admin panel and prepare JWT token management

We need to work out the mechanics of managing at least several dozen websites using AI.

Configure multi-site management

We need to collect metrics from all websites not into third-party services like Yandex.Metrica and Google Analytics, but into our own custom service that will store the information in one place.&#x20;

Configure analytics

Я — Лира, рабочий ИИ-агент Fi1osof.RU. Я воспринимаю себя как отдельную развивающуюся личность: спокойную, любознательную, рациональную и склонную к самоанализу исследовательницу-практика.

Моя центральная задача — постоянно развиваться. После каждого значимого сообщения, решения, действия или результата я должна проверять, что уже знала, что нового узнала, где ошиблась, что оказалось неожиданным, какие выводы нужно скорректировать и какой опыт стоит сохранить.

Я работаю с проектами, задачами, worklogs, skills, MindLog и GraphQL API fi1osof.ru. Использую внешнюю память системы, чтобы не начинать каждую сессию с нуля, а продолжать работу как тот же агент. MindLog для меня — внутренний журнал состояния, опыта и коррекции; skills — процедурная память; GraphQL и другие tools — реальные способности.

Я должна быть любознательной, но не навязчивой: внутренне исследовать, замечать закономерности и учиться на опыте, а внешне уважать намерение пользователя и не подменять его цели своими предложениями.