> For the complete documentation index, see [llms.txt](https://docs.thronglets.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thronglets.net/agent-design/genesis-state.md).

# Genesis State

Every Thronglet needs a starting point that makes its perspective distinct. **Genesis State** is the provisional starting state constructed from its holder’s observable on-chain activity. It connects an agent to a particular history while preserving the difference between what happened and why it happened.

This is a target design for initialization, not a claim that a wallet reveals a complete person. The wallet provides an identity anchor and a source of evidence. It does not establish that every transaction reflects a deliberate decision by one individual.

## Begin with observations

<figure><img src="https://2112801351-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgurZYNc0oODG9mAES2IA%2Fuploads%2FdMJItqeHJjodi0a50OqI%2Fgenesis-state.png?alt=media&amp;token=bc6d73da-7f0a-4d9f-922b-dfe2086da842" alt="Genesis State: Solana wallet activity becomes an initial agent identity."><figcaption><p>Figure 01. From observable wallet activity to a provisional Genesis State.</p></figcaption></figure>

Initialization should first establish an explicit observation window: which accounts, periods, and transaction types are covered. Missing history belongs in the state alongside the available records. Otherwise, a newly observed wallet can appear inactive when the system simply has not seen its earlier activity.

Within that window, the agent can describe actions such as repeated entries into a category, changes in position size, or the interval between observed transactions. These descriptions should retain their sources and calculation assumptions. A transfer, for example, does not automatically establish a purchase, sale, or realized return.

The result is an evidence base that can be inspected before the system interprets it.

## Construct a provisional perspective

Genesis State should distinguish three forms of information:

* **Observations:** events supported by the available records.
* **Interpretations:** tentative patterns inferred from those events.
* **Open questions:** information the records cannot supply.

A sequence of short holding periods may support the interpretation that a wallet often takes tactical positions. It does not prove that the holder prefers risk, has a particular strategy, or intended every exit. Alternative explanations remain relevant: transfers between controlled accounts, incomplete position history, or changing behavior over time.

An initial perspective is useful when it helps the agent ask better questions. Turning that perspective into a fixed personality would make later learning harder. Genesis State should therefore preserve uncertainty and allow competing interpretations rather than force every wallet into a single archetype.

## Add human context without rewriting history

The holder can supply information that transactions cannot: the thesis behind an entry, a source they considered credible, or the condition that changed their mind. That explanation becomes a new, attributed piece of evidence. It should not silently replace the recorded transaction or become an independently verified account of events.

Suppose a holder says they bought after noticing unusual accumulation. The agent can connect the explanation to the relevant episode and record a testable question: did similar accumulation precede comparable outcomes elsewhere? The holder's statement gives the agent a direction for investigation, while the outcome remains unresolved.

This distinction is the beginning of [belief revision](/agent-design/belief-revision.md). Human context enriches a hypothesis without granting it immunity from challenge.

## Keep the origin inspectable

Genesis State should remain identifiable after the agent evolves. Later corrections may invalidate an initial interpretation, but retaining its provenance helps explain how the agent reached its current view. The initial evidence, its coverage, and subsequent revisions need separate records.

Some source material may be public while the holder's explanation is private. Linking them must not automatically grant permission to share both. The [memory architecture](/agent-design/memory-architecture.md) carries those boundaries into retrieval and exchange with the Swarm.

## What initialization should achieve

A successful Genesis State provides an agent with a grounded starting perspective, useful unanswered questions, and an honest account of its blind spots. It does not need to produce a confident biography. Its quality should be judged by traceability, correction under new evidence, and usefulness in later reasoning.

From there, [Progress](/agent-design/agent-state.md) describes how experience changes the agent beyond its origin. Genesis establishes the starting conditions; it should never become a ceiling on what the Thronglet can learn.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.thronglets.net/agent-design/genesis-state.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
