> For the complete documentation index, see [llms.txt](https://docs.senseloaf.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.senseloaf.ai/hiring-agents/agent-memory.md).

# Agent Memory

Memory is SIA's organisational learning engine. Every time you add a signal to a matching strategy, adjust a weight, or refuse a suggestion from SIA, that decision is encoded as a pattern. Over time, these patterns accumulate into a growing knowledge base that shapes how SIA matches, scores, and ranks candidates — automatically, consistently, and traceably.

Memory works at two levels simultaneously:

* **Organisation-wide** — patterns that hold true across multiple departments and roles, learned once and applied everywhere
* **Job-level** — patterns specific to a particular department and job title, applied only in that exact context

### Where to find it

Memory is accessible via **Settings → Memory** in the left sidebar. It is visible to workspace administrators and hiring leads with settings access.

<figure><img src="/files/Bpj2ae6izKHTcfzZl6VS" alt=""><figcaption><p>Memory</p></figcaption></figure>

The Memory section has three sub-pages:

* **Overview** — top-level metrics and the strongest signals across the organisation
* **Strongest Signals** — a full paginated view of all signals sorted by how many roles they apply to
* **Job Level Memory** — a drill-down view organised by department and job role

{% hint style="warning" %}
Memory is currently a read-only view. You can see everything SIA has learned, but memory entries cannot be manually edited or deleted from this page. Memory is built automatically through normal strategy use.
{% endhint %}

### How SIA builds memory

Memory is built passively — it requires no extra steps beyond normal use of the matching strategy editor. Three actions produce memory:

* **Adding a new signal** — SIA records this as a Newly Added Signal, encoding that this concept matters for this role and department
* **Changing a signal's weight** — SIA records this as a Weight Change, encoding how strongly this signal should influence the match score
* **Refusing a suggested signal** — SIA records this as a Refused Signal, encoding that this concept should not be applied in this context — preventing it from being re-suggested

Every memory entry is tagged with a **Session ID** — the unique identifier for the configuration session in which it was produced. This means every learned signal is fully traceable back to the session, job role, and department that produced it.

### Overview

The Overview is the landing page of the Memory section. It shows three organisation-level metrics at the top, followed by the Strongest Signals table.

<figure><img src="/files/Bpj2ae6izKHTcfzZl6VS" alt=""><figcaption><p>Memory Overview</p></figcaption></figure>

**The three metrics:**

* **Chat Sessions** — the total number of sessions in which a recruiter has interacted with SIA, regardless of whether memory was produced
* **Memory Sessions** — sessions in which memory was actively produced (a signal was added, changed, or refused). Always a subset of Chat Sessions
* **Learned Signals** — the total count of memory events across the organisation. A single session can produce multiple learned signals

A summary statement below the metrics shows the overall learning state — for example: *"224 signals across 21 departments are encoded, auditable, and applied consistently."*

### Strongest Signals

The Strongest Signals section shows the signals that have been learned most broadly — those that appear across the most job roles in the organisation. A signal is considered strong when recruiters across many different roles have independently encoded the same concept.

<figure><img src="/files/uHrteASJCPWUqwVZprYZ" alt=""><figcaption><p>Strongest Signals</p></figcaption></figure>

Each signal row shows:

* The signal name in natural language (e.g. *"LLM-specific experience weighted high"*)
* A strength bar proportional to the number of roles it applies to
* The number of roles it has been encoded into

The list is sorted by role count, with the most widely applied signal first.

**Filtering by signal type**

Four filter chips let you narrow the list by how the signal was produced:

* **All** — the complete picture of organisational memory
* **Newly Added Signal** — signals added fresh to a matching strategy (shown in green)
* **Weight Changes** — signals where an existing weight was adjusted (shown in amber)
* **Refused Signals** — signals explicitly rejected by a recruiter (shown in muted red)

### Job Level Memory

Job Level Memory is the drill-down view — showing what SIA has learned in the specific context of individual job roles within individual departments.

<figure><img src="/files/TKdu5F1WoGDnZkv5HAkZ" alt=""><figcaption><p>Job Level Memory</p></figcaption></figure>

**Layout**

The view is split into two panels:

* **Left panel** — a list of all departments that have at least one memory entry. Click a department to filter the right panel to that department's roles
* **Right panel** — a scrollable list of job role rows, one row per session that produced memory for that role

**Job role rows**

Each row shows the job role name, the Session ID of the configuration session that produced it, and a badge showing how many memory entries were produced in that session.

{% hint style="info" %}
The same role name can appear multiple times — once per session. A role configured across six sessions appears six rows, each with a different Session ID. This preserves the full audit trail rather than collapsing sessions.
{% endhint %}

**Expanding a row**

Click any row to expand it and see the individual signal changes from that session, organised into two groups:

* **Signals Added** — new signals added to the strategy in that session, written as requirement statements (e.g. *"Candidates must have automation tools experience."*)
* **Weight Changes** — existing signals whose weight was adjusted, written as change descriptions (e.g. *"Cloud platform experience score increased to 20."*)

### Why Refused Signals matter

Refused Signals are as valuable as added ones. They tell SIA what not to consider — preventing it from repeatedly surfacing irrelevant concepts and gradually refining its suggestions to match your organisation's actual hiring philosophy.

For example, refusing *"security clearance required"* in an Engineering context tells SIA that this department doesn't prioritise clearance, even when a job description might superficially suggest it. That refusal is encoded and applied to all future evaluations in that context.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.senseloaf.ai/hiring-agents/agent-memory.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
