Guides / Core Concepts

Core Concepts

Live Neon is easiest to use when you stop thinking in terms of one giant prompt and start thinking in terms of identity layers, evidence, and runtime outputs.

This page gives you the mental model.

The shortest explanation

Live Neon separates four concerns:

  1. Identity - who the agent is
  2. Responsibilities - what the agent owns
  3. Experience - what the agent has done or been exposed to
  4. Runtime prompting - how that identity is delivered to an LLM at inference time

That separation is the whole product.

Organization, group, and agent

Live Neon uses a three-level identity model:

  • Organization - brand-level identity and accountabilities
  • Group - team-level norms and coordination
  • Agent - individual voice, specialization, and duties

These levels cascade. An agent inherits from the org and its group, then adds its own identity on top.

Why this matters

Without hierarchy, teams end up duplicating the same policy and voice instructions across every agent. With hierarchy, shared truth lives once and flows down.

Beliefs

Beliefs are the platform's structured identity primitives. They answer: what does this agent believe about how it should think, speak, and behave?

Live Neon uses five belief categories:

Axiom

Foundational truths the agent should not casually drift away from. Use axioms for the deepest identity and safety anchors.

Principle

Operating rules and decision habits. Use principles for tradeoff logic, priorities, and recurring ways of working.

Voice

How the agent communicates. Use voice for tone, framing, and communication style.

Preference

Defaults and tendencies. Use preferences for habitual choices that matter, but are not sacred.

Boundary

Lines the agent should not cross. Use boundaries for hard edges, compliance, privacy, legal, or safety constraints.

Responsibilities

Responsibilities answer a different question: what is this agent accountable for?

Beliefs shape behavior. Responsibilities shape scope.

Live Neon uses five responsibility categories:

  • Ownership: What the agent owns end to end.
  • Execution: How the agent gets work done.
  • Collaboration: How it works with people or other agents.
  • Deliverables: What it is expected to produce.
  • Monitoring: What it watches, checks, or keeps healthy over time.

Soul

In the broader Live Neon ecosystem, the term Soul is used for structured identity earned from evidence. Inside the agent platform, that idea is implemented as beliefs, responsibilities, provenance, and prompt generation.

Soul is not just "personality." It includes values, boundaries, voice, preferences, responsibilities, tensions the agent consistently holds, and the reasons those things are believed to be true. So Soul is closer to structured selfhood than to tone-of-voice settings.

If you are coming from a SOUL.md or similar static identity file, Live Neon does not invalidate that approach. It upgrades the model behind it. Instead of asking a human to guess the final identity in advance, Live Neon helps the agent earn a more faithful identity from actual evidence, then compiles that result into a runtime prompt or identity artifact you can use however you like.

Agent soul page showing structured beliefs across categories

Resolved identity

An agent's resolved identity is the merged result of org-level items, group-level items, and agent-level items with deduplication and source attribution.

This is the cleanest representation of what the agent currently is. Use resolved identity when you want to inspect or reason about the agent's actual identity model before prompt generation.

Overrides

Sometimes inheritance is mostly right, but not completely right. Overrides let an agent hide inherited beliefs or responsibilities without deleting them from the org or group.

This is important because it preserves shared structure while allowing legitimate exceptions.

A useful mental model:

  • Inheritance is the default
  • Overrides are local exceptions
  • Deletion changes the source layer for everyone
Responsibilities page showing agent accountabilities across five categories

Observations

Observations are the first structured outputs created by PBD from raw content. They are not beliefs yet. They are small, behavior-oriented claims such as recurring stylistic choices, decision patterns, repeated priorities, and consistent collaboration habits.

Think of observations as evidence candidates.

Signals

Signals are clusters of similar observations. They are stronger than individual observations because they represent recurrence.

A good signal says: this is not a one-off, this pattern keeps showing up. Signals are what the platform evaluates for promotion into beliefs or responsibilities.

Provenance

Provenance is the chain from final identity back to evidence. It answers:

  • Why does this belief exist?
  • Where did it come from?
  • What source supports it?
  • What quote or content item led to it?

If you care about trust, auditability, or debugging identity drift, provenance is not a nice-to-have. It is the system.

Tension

Real identity is rarely perfectly flat. Agents and humans often hold paired truths such as:

  • Be direct and be gentle
  • Move fast and stay careful
  • Stay opinionated and acknowledge uncertainty

Flattening these tensions usually makes an agent worse. Good identity systems surface them instead. If your agent sounds oddly generic, one common reason is that the system compressed away meaningful tension. Often the better answer is not to pick one side. It is to preserve the condition under which each side is appropriate.

PBD

PBD is the discovery pipeline that distills recurring patterns from observed behavior into structured identity. Operationally, in the platform, PBD means:

  1. Observe content
  2. Extract observations
  3. Cluster signals
  4. Promote recurring patterns into beliefs and responsibilities
Organization page showing cascading brand-level identity

Consensus

Consensus is how shared identity moves upward. If many agents in an organization or group independently converge on similar beliefs or responsibilities, Live Neon can detect that pattern and promote it to the group or org level.

This is important because it lets identity become more coherent over time instead of fragmenting across agents.

Group detail page showing consensus detection across team agents

System prompt

The system prompt is the compiled prompt representation of an agent's identity. It is generated from beliefs, responsibilities, agent profile fields, and inherited org and group context. This is the prompt most teams will ship into their runtime.

Dynamic prompt

A dynamic prompt is not just a regenerated prompt. It is a fresh prompt built from the same identity pool with controlled variation. Live Neon exposes this to combat prompt staleness and "persona numbing."

A useful way to think about it:

  • Resolved identity = the model
  • System prompt = the compiled default
  • Dynamic prompt = a per-invocation rendering of the same model

Snapshots

Snapshots capture the current belief and responsibility genome of an agent at a point in time. Use them before large imports, bootstrap actions, policy changes, or trust-sensitive deployments.

Diffing snapshots is one of the best ways to make identity evolution legible to a human reviewer.

Content source vs. content item vs. conversation

These are easy to mix up.

Content source

A connection to an external platform or feed. Examples: GitHub repo, website, X account, RSS feed, LinkedIn export.

Content item

A single imported unit of content from a source. Examples: one commit, one web page, one tweet, one RSS entry.

Conversation

A first-class session containing messages between agents and humans. Conversations can also be published into content items and fed into PBD. That makes conversations the bridge between runtime behavior and identity evolution.

Status, stars, and hidden items

Identity items are not just present or absent. They can also carry workflow state.

  • Pending: Not yet approved for production use.
  • Approved: Accepted as part of the agent's active identity.
  • Rejected: Explicitly not accepted.
  • Starred: Important enough to emphasize in the prompt.
  • Hidden: Excluded from active prompt output without necessarily destroying history.

This matters because good identity governance is not binary. It is editorial.

Environments and models

Live Neon also models deployment context.

  • Environments are places like production or staging
  • Models are provider/model combinations
  • Agent model assignments connect the two

This lets you separate identity from runtime and still keep deployment configuration structured.

The mental model that helps most

Sources and conversations
        |
   content items
        |
   observations
        |
     signals
        |
beliefs + responsibilities
        |
 resolved identity
        |
system prompt / dynamic prompt
        |
  runtime outputs
        |
published back as experience

Failure memory vs identity memory

This is an important distinction, especially if you are also using self-improving or failure-tracking tools.

Failure memory asks: what went wrong? What should never happen again? What constraint should we enforce now?

Identity memory asks: who is this agent becoming? What values, boundaries, and tendencies keep recurring? What responsibilities does it actually own?

You usually want both. Failure-memory systems are great for constraint creation, repeated mistake prevention, and operational hardening. Live Neon is great for value formation, voice and boundary consistency, responsibility discovery, and inspectable identity evolution. These are complementary, not competing, layers.

What Live Neon is not

It helps to be explicit. Live Neon is not:

  • A full agent runtime
  • A replacement for your tools framework
  • A template directory or prompt editor
  • A reason to skip human review
  • A single static persona file

It is strongest when used as a governed identity layer between experience and execution.

Common confusions

"Is Soul just personality?"

No. Personality is part of it, but Soul also includes values, boundaries, responsibilities, and provenance.

"Why not just write a system prompt?"

You can, and sometimes you should. But a hand-written prompt is harder to audit, inherit, compare, and evolve.

"Can I start from a static identity file?"

Yes. Treat it as a starting hypothesis, not the final truth.

"Do I still need runtime instructions?"

Usually yes. Identity does not replace task instructions. It makes them more coherent.

"Is every repeated phrase a belief?"

No. Repetition is necessary but not sufficient. Diversity, context, and evidence quality matter.

A final distinction worth keeping

When something feels confusing, ask:

  • Is this identity?
  • Is this responsibility?
  • Is this evidence?
  • Is this runtime instruction?

If you keep those four buckets separate, the platform starts to feel simple.

Next reads