---
title: Requests
description: What happens when the workspace does not hold something an agent went looking for, how the miss is recorded, and how an admin turns it into an entity.
---

When an agent asks Foundation for something the workspace does not hold, it
says so rather than guessing. The miss is recorded, and an admin decides
whether to define an entity for it.

That loop lets a workspace grow from what people ask for rather than
from a taxonomy someone drew up in advance. Requests arrive two ways, and an
admin handles both in one place.

## What agents record
An agent looking for an entity by name says what it is seeking. Foundation records any name
that resolves to nothing, with a count and the date someone last asked for
it. The same wording asked again raises the count,
so an admin reads real demand. What an agent asks for need not be a
definition: a number nobody tracks yet and a list nobody keeps are recorded
the same way.

Foundation tells the agent that its wording went on the record, and that a
wording miss is not proof the workspace lacks the concept. The workspace often holds
it under a different name. When an agent finds the entity that was meant, it
can save the wording it tried as an alias for that entity, which settles
the record and sends every later agent straight to it.

## What people ask for
Counting wording shows what agents kept looking for. It cannot carry a
deliberate ask: a member mid-conversation who knows the workspace should
hold a monthly churn figure and knows that it does not. Any member or admin
can file that ask through the connector, in their own words, saying what is
missing and why they want it. Naming a type is optional, because someone who
wants the refund policy written down should not have to decide first whether
that is a document or a definition. The admin settles the shape when they
define it.

Creating entities stays with admins, which keeps the vocabulary from
forking. A request is how anyone, [member or
admin](/concepts/members-and-roles), says what the vocabulary is missing
without creating it.

## The queue
Both kinds of request land in one queue in the console: the wording agents kept
trying, with its count, beside the asks people wrote out. One concept often
turns up under several spellings, so the queue presents the variants of one
thing as a single row.

An admin does one of three things with a row. They define the entity,
exactly as they would define any other. They discard it, and the count
behind the discarded row keeps rising without surfacing again. Or they
assign it to another admin, whose open items are waiting the next time they
open the console.

## What a request cannot do
A request is a signal, never a write. It is not itself an entity: nothing
enters the workspace because it was asked for, and what someone wrote in a
request is never served back to agents as though it were context. An admin
defines the entity, and the layer grows one definition at a time, at the
pace they agree to.