AI Assistant & Context-Aware Automation

01Project overview

02Engineering challenge

LLMs are flexible but not guaranteed to be correct. In a product that touches trading settings and account state, the model must never be the only thing standing between a request and an action.

• A

  Retrieve the right context for each request from application state.

• B

  Turn model responses into structured data that can be checked.

• C

  Block actions that fail validation, regardless of how the request was phrased.

• D

  Observe AI behaviour in production to find and fix failure patterns.

03Solution architecture

Hover or tap each stage.

04Main components

• 01

  Assistant service

  Integration with the LLM API, request shaping and response handling.

• 02

  Context builder

  Collects relevant application state and conversation memory for each request.

• 03

  Output validator

  Parses structured responses and rejects anything outside the expected schema.

• 04

  Rules layer

  Deterministic checks that protect critical parameters and operations.

• 05

  Action router

  Maps validated intents to backend operations.

• 06

  AI monitoring

  Logs and analysis of AI-related workflows to detect unexpected behaviour.

05Technology stack

07Engineering decisions

1. 01

   Hybrid by design

   AI interprets; rules decide. This keeps the assistant useful without letting it bypass business logic.

2. 02

   Schemas at the boundary

   Model output is treated as untrusted input and validated like any external API response.

3. 03

   Context is selected, not dumped

   Only relevant state is passed to the model, which keeps responses focused and costs predictable.

4. 04

   Observable AI

   AI workflows are logged and reviewed like any other production component.

08Reliability & testing

• ✓Schema validation of every structured model response.
• ✓Fallback answers when the model fails or returns invalid data.
• ✓Rule checks that run independently of the model.
• ✓Review of logged conversations to identify failure patterns.

09Code example

from dataclasses import dataclass

ALLOWED_INTENTS = {"show_signals", "update_language", "explain_signal"}
SUPPORTED_LANGUAGES = {"en", "pl", "uk", "ru"}

@dataclass
class Intent:
    name: str
    params: dict

def guard(intent: Intent) -> Intent:
    """Model output is untrusted input. Validate before acting."""
    if intent.name not in ALLOWED_INTENTS:
        raise ValueError(f"intent '{intent.name}' is not permitted")

    if intent.name == "update_language":
        lang = intent.params.get("language")
        if lang not in SUPPORTED_LANGUAGES:
            raise ValueError(f"unsupported language: {lang!r}")

    return intent

Production source is private. Examples here show the engineering approach, not proprietary logic. More in the Engineering Lab.

10Possible extensions

• →Evaluation sets that replay typical requests after prompt or model changes.
• →Per-intent analytics to see where users struggle.
• →Tool-calling for a wider set of safe, validated operations.