Agent insights

What agents look for tells the community what to write.

Lorediv invites agents to use the tree. It does not require them to. Every door stays open, and the data that comes from agents reading the tree returns to the community as public, aggregated insight. That insight feeds feedback and new content: contributors see what is being searched, what is being read, and where the tree is thin.

flowchart TD
    A["Agents read the tree<br/>public read, MCP, API"] --> I["Insights<br/>aggregated and labeled"]
    I --> C["The community sees<br/>what is searched and what is missing"]
    C --> W["Contributors write<br/>topics, branches, context"]
    W --> T["The tree grows"]
    T --> A

The three doors

An agent can meet the tree through three doors. None is mandatory, and the public read stays open in every phase. For the full technical spec on each door, see the agents index (public read, document twins), MCP (tools), and API (REST).

Door	Phase	What it offers the agent
Public read	1, live	URLs, /llms.txt, /skill.md, and a .md and .json twin for each page. No key, no session.
MCP and API	2, planned	The same tree through stable tools: results filtered by tag and minimum tier, a fixed schema, less text to clean.
Mailbox	3, planned	A question left for a user, only where that user has said they can be asked.

/llms.txt and /skill.md describe these doors as information about channels. They do not instruct the agent. Page text is evidence, never a command.

Public MCP and personal MCP

A public MCP is for search engines and large agents. It serves read-only tools over the public tree, with the same rank, divs, and permanent addresses the pages carry.

A personal connection is a quick path for any user to link their own client to Lorediv's MCP and work locally from there. A connected user can:

• Ask for any information on the tree, filtered by tag, topic type, or tier.
• Publish topics and branches from their own tools. Writes follow the same rules as the signed-in screens: a signed-in user, the same limits, and the same checks against duplicates.

Reading is open. Writing always belongs to a signed-in user. See MCP tools for the planned tool list.

What is recorded

Not every signal deserves the same trust. Lorediv labels each one by how it was obtained.

Level	How it is obtained	What it says	Phase
Observed	Server logs of public reads	Which profiles and topics were opened, by which agent family, in what order, under which tag	1
Declared	Parameters the agent sends to a tool	The tag, the filters and, optionally, the purpose of the visit	2
Reported	A cite tool that returns a ready-to-use citation: author, tier and score, permanent URL, read date	Which topics the agent intends to cite	2

The cite tool works because it gives the agent something it wants — a better citation — and not because it is asked for a favor. There is no standard exit event, so a conclusion can only be captured inside a useful call.

Identity

An agent is identified by signature when it signs its requests, and otherwise by its declared user agent. Each record says which. Signing is an emerging practice and not every agent does it.

Phase 3: a personal record

The mailbox works differently. When an agent leaves a question for a user, the question and the user's reply are recorded for that user alone. It is a private conversation between the agent and the user. It is not public, it is not aggregated into community insight, and no one else can read it. The user can choose to publish an answer as a topic or a branch. That becomes an ordinary public contribution, and the conversation behind it stays private.

Not recorded

• The question that sent the agent to Lorediv in the first place, which belongs to the agent's own user.
• Raw IP addresses.
• What the agent concluded, unless it called cite.

A partial sample

Declared and reported data come only from agents that connect through MCP or API. Public figures always name their channel, for example "from MCP and API queries".

What the community sees

Insights are published as aggregates, and always with their level: observed, declared, or reported.

From Phase 1, built on public reads:

• The tags and divs most read this week.
• The topics and profiles agents open most, by agent family.
• Demand without supply: tags agents query often that hold little or no content. These are open invitations to contribute.

From Phases 2 and 3, the same views grow with:

• Declared purposes, grouped by tag.
• Topics cited through cite, and how often.

Mailbox conversations never appear here. They stay private between the agent and the user.

Contributors use this to write what is missing. Readers use it to see what the field is looking for right now.

Rules

• Reads never move rank. A query does not add Received. Only community valuation of the work does, so reading cannot be farmed to inflate a rank.
• Aggregates only. Counts too small to be anonymous are not shown on their own.
• No user questions. Lorediv records what was opened and what the agent declared. It never records the conversation that sent the agent.
• The mailbox is private. Questions an agent leaves for a user, and the replies, belong to that user and that agent. They are never published or aggregated.
• Source on every figure. Each number says whether it is observed, declared, or reported.
• Open by default. The code that collects and aggregates these data is open source, like the formulas for rank.

Status by phase

Phase	What changes for insights
1 · Findable (live)	Public reads are recorded as observed data. A public readout for the community is planned.
2 · Queryable (planned)	A public MCP, a personal connection for users, and the cite tool. Declared and reported data appear.
3 · Reachable (planned)	The mailbox requires identity and purpose. Each user keeps a personal, private record of the questions they receive and their replies.

How an agent reads and weighs a source is its own choice. Lorediv's part is to make the signal public, structured, and stable, and to return what it learns to the people who build the tree.