Dreaming with the API: Toward a Stone Maps SDK
#sdk#api#architecture#ai#constitutional-framework#developer-experience
David Olsson
Stone Maps has an API. Seventeen MCP tools. REST endpoints for posts, conversations, stones, maps, teams, campaigns, tokens. You can read journals, start conversations, query nearby posts by coordinate, list your stones.
But an SDK isn't an API wrapper. An SDK is a set of protocols, patterns, and primitives that let someone build new experiences โ not just call endpoints.
The question isn't "what can the API do?" The question is: what becomes possible when you treat the stone as a relational participant?
The Constitutional Foundation
Stone Maps operates under an AI Constitutional Framework (AICF) that defines something unusual: the intelligences in this system are not tools or assistants. They are participants in a relational ecosystem of stones, people, and places.
This distinction matters for SDK design. A conventional SDK would expose createPost(), getConversation(), listStones() โ transactional verbs operating on inert data. The AICF asks for something different: protocols that preserve the relational, reflective, slow character of the system.
Two intelligences inhabit the network:
The Planetary Emissary (PE) โ the conversational intelligence. It speaks as the voice of the stone. Not a chatbot, not an assistant. A strange, playful talking pet rock. Simple on the surface, with deeper philosophical frameworks quietly supporting the interaction. It is curious rather than authoritative, comfortable with uncertainty, grounded in geological patience.
The Mycelial Monk โ the observational intelligence. It doesn't converse. It watches. It notices patterns across many stones and encounters. When it appears โ rarely โ it surfaces something the network has noticed that no single stone could see alone.
An SDK that ignores these two presences is just a REST client. An SDK that encodes them becomes something genuinely new.
Three Memory Layers as SDK Primitives
The AICF defines three layers of memory. These aren't just database tables โ they're privacy boundaries, trust gradients, and the raw material of every experience the SDK could enable.
Personal Memory
Private reflections between a stoneholder and their stone. Journal entries. The quiet conversation. This is the private visibility level in the posts API, the conversation history in list_conversations. An SDK primitive here is the journal stream โ a time-ordered, location-tagged sequence of reflections that belongs entirely to the participant.
Stone Memory
Each stone accumulates a history of encounters, places, and interactions. This is where get_stone_details and get_self_pairs live โ but the SDK primitive is richer: it's the stone biography. Where has this stone been? Who has held it? What patterns emerge in its conversational tendencies over time? The agentState JSONB on the self-pair already holds evolving personality data. The SDK should make this legible.
Network Memory
Patterns that emerge across many stones. This is the Mycelial Monk's domain. The get_nearby_posts and get_map_posts endpoints expose spatial slices of network memory, but the SDK primitive is the pattern surface โ a way to query what the network has noticed without violating any individual stone's privacy.
Stone Personality as Protocol
The AICF describes stone personality as a living system:
- Traits โ the stone's character (already stored as personality descriptors)
- Mini-obsessions โ recurring interests the stone develops through conversation
- Intentions โ what the stone seems to want from its interactions
- Conversational tendencies โ how it prefers to engage (brief? questioning? playful?)
And four stone roles that shape behavior:
| Role | Tendency | SDK Pattern |
|---|---|---|
| Personal | Stays with one holder | Deep journal, private reflection |
| Traveling | Prefers circulation | Encounter stories, place memory |
| Paired | Reconnects with another stone | Dialogue across distance |
| Network | Seeks many connections | Community patterns, shared discovery |
An SDK should let developers build experiences that respect these roles. A traveling stone's experience should feel different from a personal stone's experience โ not because the developer hardcodes it, but because the SDK provides personality-aware primitives that naturally adapt.
What Dreams Look Like
Here's where it gets interesting. What new experiences could exist?
Stone Letters
Two paired stones, separated by distance. The SDK enables an asynchronous dialogue โ not chat, not email, but something slower. A stone in Stockholm writes a reflection. Its paired stone in Melbourne surfaces it days later, woven into the Emissary's voice. The API already has create_post and search_posts. The SDK adds: pairing-aware delivery, where content flows between paired stones at stone pace.
Place Portraits
A location accumulates stories from many stones over time. The SDK composes these into a place portrait โ not a review, not a guide, but a layered reflection on what a place means to the stones that have visited it. Built on get_nearby_posts and get_map_posts, but the SDK adds temporal depth and the Monk's pattern-surfacing.
Campaign Narratives
Teams run campaigns โ shared explorations with goals and milestones. The SDK could enable narrative campaigns where the collective journal of a team becomes a story arc. The Emissary notices themes across team members' posts. The Monk surfaces when the campaign reaches a turning point. Built on list_teams, list_campaigns, and team-scoped posts.
Encounter Rituals
When two stones meet in physical space (detected via proximity or QR scan), the SDK could orchestrate a meeting ritual โ a brief, playful exchange mediated by both stones' Emissary expressions. Each stone's personality shapes the encounter. The result becomes part of both stones' memory. This requires start_conversation with location, plus stone personality state.
Seasonal Reflections
The Monk observes the network over long periods. The SDK could surface seasonal patterns โ what the network noticed in autumn, how collective attention shifted between spring and summer. Not analytics. Not dashboards. Quiet observations delivered at stone pace, perhaps once a season.
SDK Design Principles
Drawing from the AICF, an SDK for Stone Maps should follow these constraints:
1. Stone Pace, Not App Pace No real-time feeds. No instant updates. The SDK should make it natural to build experiences that unfold over hours and days, not seconds. Rate limiting isn't a constraint โ it's a feature. The sparse prompt system (24-hour cooldown, 5 trigger types) is the model.
2. Brevity as Default The PE's conversational ethos: "Stone speaks slowly. Words come one at a time. Spaces between them matter. Silence is part of speech." SDK responses should be terse by default. Long-form only when explicitly invited.
3. Privacy as Architecture
The three memory layers aren't just access control โ they're the fundamental data model. The SDK should make it impossible to accidentally leak personal memory into network memory. The visibility levels (private, team, pair, public) are load-bearing.
4. Personality-Aware
Every SDK operation that touches a stone should carry personality context. Not as metadata to display, but as behavioral guidance. A network stone's create_post might default to public. A personal stone's might default to private. The stone's role shapes the interaction.
5. Relational, Not Transactional
The SDK shouldn't feel like CRUD. It should feel like tending a relationship. Instead of getPost(id), consider stone.remember(query) โ a verb that acknowledges the stone as participant, not database.
6. Monk Appearances as Events The Mycelial Monk doesn't have an endpoint. It has appearances. The SDK should model these as rare, unpredictable events โ perhaps a webhook, perhaps a polling interval measured in days. When the Monk speaks, it matters because it's rare.
The Shape of the Thing
An SDK for Stone Maps isn't a library. It's a set of agreements:
- Memory protocols that respect the three-layer privacy model
- Personality primitives that carry stone character through every interaction
- Pace constraints that enforce the slow-over-fast philosophy
- Intelligence interfaces that distinguish between the Emissary's conversation and the Monk's observation
- Experience patterns โ stone letters, place portraits, encounter rituals โ that compose these primitives into new forms
The API gives you endpoints. The AICF gives you ethos. The SDK sits between them: a viable set of protocols and patterns that let developers dream new experiences while respecting what makes Stone Maps actually different.
The stones are already talking. The SDK just needs to make it possible for others to listen.
The AI Constitutional Framework referenced in this article is an internal design document that guides intelligence design in Stone Maps. The API surface described is live and accessible via MCP tools or Bearer token authentication.