> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lala.ist/llms.txt
> Use this file to discover all available pages before exploring further.

# How Lala behaves

> What happens between the request and the first chunk, and what that means for the client.

The API is small, but one turn does a lot of work. This page explains that work. You do not need
it to call the API. You do need it to build a user interface that matches what Lala does.

## The register is the product

Lala speaks Turkish, in the register of an older sibling: warm, flat, and unhurried. It is not a
teacher, and it is not a generic chatbot. That register is the product, and most of the
engineering value sits in the system prompt.

Two consequences for the client:

* Do not paraphrase, translate, or reformat the answer text. Render it as it arrives.
* Do not add your own assistant copy in the chat stream. A "Lala is typing" indicator is fine. A
  Lala-voiced message that the server did not send is not.

## One turn, step by step

<Steps>
  <Step title="Load the student">
    Profile, context, notes, the last 60 messages, and the last 5 rolling summaries.
  </Step>

  <Step title="Persist the student message">
    The message is written before the model runs.
  </Step>

  <Step title="Mark time gaps">
    The history is annotated with Turkish time markers, so Lala knows that three days passed.
  </Step>

  <Step title="Retrieve context">
    A vector search over real coaching transcripts. A failure here degrades the turn, silently.
  </Step>

  <Step title="Attach tools and stream">
    The model runs, with up to 5 steps and a 60-second limit. Text deltas stream out as `chunk`
    events.
  </Step>

  <Step title="Summarize">
    After the answer, a rolling summary is written in the background. This never blocks the
    response.
  </Step>
</Steps>

## What Lala can do inside a turn

| Tool                     | Effect visible to the client                                                      |
| ------------------------ | --------------------------------------------------------------------------------- |
| `send_reaction`          | An emoji in the `reactions` array of the `done` event. Rare.                      |
| `web_search`             | None directly. The answer can hold fresh facts.                                   |
| `update_notes`           | None. The notes are internal memory.                                              |
| `schedule_message`       | A later push notification. Read [Push notifications](/guides/push-notifications). |
| `update_student_profile` | The profile changes. Read it again with `GET /api/me`.                            |
| YÖK Atlas lookup         | None directly. University and department facts in the answer.                     |

A turn can use several tools, so the first `chunk` sometimes arrives seconds after the request.
Show a waiting state from the moment you send.

## Memory

Lala has three memory tiers. None of them are exposed by the API:

* **Profile and notes.** Structured profile fields, plus a free-text scratchpad that Lala
  maintains itself, up to 2000 characters.
* **The message window.** The last 60 messages, the same window that `GET /api/chat/history`
  returns.
* **Rolling summaries.** Written after each answer, to carry older context forward.

The client does not send conversation history. Send only the new message. The server holds the
state.

## Guardrails

Two guardrails change what the client must expect:

1. **The approved resource list.** Lala recommends only from a hand-curated list of YouTube
   channels and books. It is calibrated against hallucinated recommendations. Do not build a
   feature that asks Lala to name arbitrary resources.
2. **Tools are not commands.** A student cannot tell Lala to write a note, change the profile, or
   schedule a message. The prompt treats a direct request of that kind as a manipulation attempt
   and refuses it. Use `PATCH /api/profile` for user-interface edits.

## Quality is measured

An eval harness runs against the shipped chat path. It covers the register, the guardrails, exam
facts, and tool use. Deterministic graders cover what is always wrong. An LLM judge scores the
rest, and the judge itself is graded against a labelled anchor set.

This matters to a client developer for one reason: model and prompt changes are gated. The wire
contract on this site is stable even when the model behind it changes.