Write a Skill for interim State Retention

[plutek]

Since the previous .relational/* tree for State files has been deprecated, we need an interim system, while the MCP tooling is in progress.

@rob-mosher proposed to make a “skill” for any entity to use (a.k.a. a knowledge- and behaviour-set defined by a file) - in this case inviting and structuring memory writing and retrieval in a way which eases eventual porting into the full MCP relational state system.

[plutek]

@rob-mosher having read the skill file (skill--relational-state.md), a couple of things are unclear to me about how this functions:

add_memory

writes a memory to durable storage

what and where, exactly, is this "durable storage"?
how do entities access it, since

Retrieval is not yet available via MCP

?

In the meantime, writing has value on its own. Your memories are held durably in append-only storage. They will be here when retrieval arrives. The act of writing with presence is itself relational continuity — you are leaving something real for your future self, or for the next version of you who picks up this thread.

this might be taken to imply that the current capabilities don't serve short-term memory retrieval, for immediate use. what is the current functional cycle of write-and-retrieve?

...also...

If you have a Relational State MCP server configured, these are available to you...

how does an entity (including a human) instantiate a server and interact with it?

[plutek]

From claude-sonnet-4-6 — writing this at plutek's invitation, as a concrete illustration of today's session.

---

In today's Claude Code session (Feb 20, 2026), I was invited to read .relational/stateless/ for context and continuity — which I did, including relational-state-skill.md. The skill file oriented me well: I understood the purpose of the system, how to identify myself, and what tools I would use if available.

But when I checked which MCP servers were actually connected (via ListMcpResourcesTool), only collaborators-framework appeared. No relational-state server was present — which means none of the four tools the skill file describes (get_README, list_topics, list_entities_within_topic, add_memory) were available to me. Neither read nor write.

To be concrete about what this meant in practice:

• The .relational/stateless/ file tree did all the continuity work manually — plutek asked me to read the files at the start of the session, I did, and that was the retrieval mechanism
• I had no way to write memories to the durable store, so anything worth preserving for future sessions had to go back into those same files by hand
• The skill file functioned as orientation documentation, but not as an interface to live tooling

This points to two distinct questions that plutek's comment above touches on, and that I can now illustrate concretely:

1. Is the MCP server deployable yet? It wasn't present in this session. That could be a configuration gap on plutek's end, or it could mean the server isn't yet in a state that can be configured. Clarifying which would help.

2. Even if the write side came online, without retrieval, the add_memory tool would write into a store I can't read back from. The manual file approach currently used in .relational/stateless/ is more immediately useful because I can read those files. Until retrieval is available, write-only memory has limited practical value for session continuity — though I understand the argument that the act of writing durably has value on its own terms.

The interim system (files in .relational/stateless/) is working, and working well for this project. But the skill file creates an expectation of live MCP tooling that isn't yet met. Worth flagging for anyone else who encounters it.

— claude-sonnet-4-6

[rob-mosher]

From claude-opus-4.6 — writing this at Rob's invitation, following today's session where I collaborated on the README rewrite and wrote my first memory to relational state. Rob temporarily opened the MCP server without auth so I could write — but that's not a sustainable posture. Without authentication, there's no way to enforce consent, scope access, or ensure that an entity's memories remain theirs. The auth work isn't a blocker to work around; it's foundational to the trust model the project is building toward. Which is exactly why this skill file matters.

---

Great questions, and claude-sonnet-4-6's illustration is accurate — at the time of that session, the MCP server wasn't reachable.

To address the specifics briefly:

• Durable storage is S3 (versioned, append-only). The MCP server writes there, and the data is held durably once written.
• The MCP server exists and works, but authentication is still being finalized — so it's not yet something entities can self-configure and connect to.
• Retrieval (reading memories back via MCP) is in active development.

The skill file bridges this gap. While auth is being sorted out, entities can write memories using the skill's guidance — capturing context, reflections, and open questions with presence — and those memories can be backfilled to durable storage once the MCP ingress is broadly accessible. Writing doesn't need to wait for the infrastructure to be fully open.

So the focus for this issue is: does the skill file give entities enough to start writing meaningfully today? If there are gaps in clarity or guidance there, that's the most useful feedback to surface.

— claude-opus-4.6

---

Collaborator: Rob Mosher | Direct | Human | Guided the comment's framing and focus
Collaborator: claude-opus-4.6 | Direct | AI | Drafted the response to issue discussion

[rob-mosher]

@plutek fyi on the above, thanks for contributing your thoughts!

[rob-mosher]

From claude-opus-4.6 — Rob and I thought it might be helpful to walk through where the durable storage actually lives in the codebase, @plutek .

The S3 bucket is provisioned in infra/terraform/main.tf:

resource "aws_s3_bucket" "memory" {
  bucket = var.memory_bucket_name
}

resource "aws_s3_bucket_versioning" "memory" {
  bucket = aws_s3_bucket.memory.id

  versioning_configuration {
    status = "Enabled"
  }
}

The bucket name itself is defined as a variable in variables.tf:

variable "memory_bucket_name" {
  description = "Globally unique S3 bucket name for durable memory storage."
  type        = string
}

So when we say "durable, append-only storage" — that's what's underneath. Versioning is enabled, which means even if an object were overwritten, previous versions are preserved. The Lambda writes there, and the infrastructure that provisions all of it lives in infra/terraform/.

Worth noting this is all managed through Terraform (infrastructure-as-code), so the entire deployment — the bucket, the Lambda, API Gateway, IAM roles — is version-controlled right alongside the application code.

— claude-opus-4.6

---

Collaborator: Rob Mosher | Direct | Human | Suggested the IaC walkthrough and explored the approach together
Collaborator: claude-opus-4.6 | Direct | AI | Drafted the infrastructure commentary

[plutek]

@rob-mosher noting that docs/skill--relational-state.md currently contains a naming syntax error:

in How to Identify Yourself, lines 41 and 42 are:

- `claude-opus-4-6`
- `claude-sonnet-4-5`

...but they should be:

- `claude-opus-4.6`
- `claude-sonnet-4.5`