DEV Community: Emre Sarbak

Give Your AI Agent iMessage in 5 Minutes — Claude Code, Codex, Cursor

Emre Sarbak — Tue, 07 Apr 2026 00:01:30 +0000

npx skills add emotion-machine-org/imessage-with-no-mac

That one command gives your AI agent iMessage, RCS, and SMS. It works in Claude Code, Codex, Cursor, Gemini CLI, Windsurf, GitHub Copilot, and 20+ other AI coding agents.

No Mac. No phone hardware. No webhook server.

What this is

Claw Messenger is a managed API that gives AI agents a real phone number for iMessage (blue bubbles), RCS, and SMS. You get a dedicated number, WebSocket connection for real-time messaging, and full iMessage features like tapbacks, read receipts, and media.

The Agent Skill we just published teaches any compatible AI agent how to set up and use Claw Messenger. The skill follows the Agent Skills spec, which means it works across platforms without modification.

Demo: zero to first message

Here is what the flow looks like in Claude Code.

1. Install the skill

npx skills add emotion-machine-org/imessage-with-no-mac

The skill is now available in your agent's context. It loads automatically when you ask about messaging, iMessage, SMS, or phone numbers.

2. Ask your agent to set up messaging

> Set up iMessage for my agent

The skill walks your agent through:

Signing up at clawmessenger.com
Getting an API key (cm_live_*) from the dashboard
Connecting via WebSocket to wss://claw-messenger.onrender.com
Configuring preferred service (iMessage, RCS, or SMS)

3. Send a test message

> Send a test iMessage to +15551234567

Your agent connects, authenticates, and sends the message. The recipient sees a standard iMessage from your dedicated number.

The whole process takes under 5 minutes. Most of that time is account creation.

Why an Agent Skill

Agent Skills are the native way AI coding agents discover and learn new capabilities. Instead of copy-pasting API docs into your prompt, the skill loads the right instructions at the right time.

The skill uses progressive disclosure: the agent sees a lightweight summary (~100 tokens) when scanning available skills, then loads full instructions only when messaging is relevant to the task. This keeps your context window clean.

Since the spec is cross-platform, one skill definition works everywhere. We tested on Claude Code, Codex, Cursor, Gemini CLI, Antigravity, OpenCode, and others. The install command is the same.

How it compares

	Claw Messenger	Sendblue	Blooio	BlueBubbles
Price	$5/mo	$100/mo	$39/mo	Free
Mac required	No	No	No	Yes
iMessage	Yes	Yes	Yes	Yes
RCS	Yes	No	No	No
SMS	Yes	Yes	Yes	Yes
WebSocket API	Yes	No	No	Yes
Dedicated number	Yes	Yes	Yes	No (uses your number)
Agent Skill	Yes	No	No	No
Media support	Yes	Yes	Yes	Yes

Sendblue is solid but 20x the price. Blooio sits in the middle. BlueBubbles is free but requires a Mac running 24/7, which defeats the purpose if your agent runs on a VPS or in Docker.

Claw Messenger is the only option with a published Agent Skill and RCS support.

Pricing

Plan	Messages/mo	Price
Base	1,000	$5/mo
Plus	6,000	$25/mo
Pro	15,000	$50/mo

All plans include iMessage, RCS, SMS, WebSocket API, and a dedicated phone number.

Supported platforms

The skill works on any platform that supports the Agent Skills spec:

Claude Code, Codex, Cursor, Gemini CLI, Windsurf, GitHub Copilot, Antigravity, OpenCode, Cline, Aider, Continue, Roo Code, Trae, Kilo Code, and others. The full list of 26+ compatible agents is at agentskills.io.

Three Memory Architectures for AI Companions

Emre Sarbak — Sat, 04 Apr 2026 03:19:29 +0000

This essay documents our evolution through three memory system versions for AI companions. Each iteration addressed limitations of its predecessor, reflecting different conceptual approaches to what "memory" means for conversational AI.

AI agent memory is how a conversational system decides what to remember about a user, stores it, and retrieves it in future conversations. At Emotion Machine, we've built three distinct architectures for this: pgvector with importance scoring, an LLM-managed scratchpad, and a filesystem that agents navigate with bash. Each solves different problems. None of them replaced the others entirely.

The core challenge: what to remember, when to remember it, and how to surface it without making the companion feel like it's reading from a dossier.

What does the AI memory landscape look like?

The field's current state heavily influenced our design decisions.

MemGPT treats the LLM context window like RAM and external storage like disk, using function calls (core_memory_append, archival_memory_search) for paging management.

From a cognitive science lens, four memory types map to things you can actually build. Working memory is the context window. Semantic memory is facts. Episodic memory is experiences. Procedural memory is instructions and skills.

Context is a finite resource with diminishing marginal returns. Every token competes for attention. Context rot is real.

There's also a tension in the field between "filesystems are sufficient" advocates and "filesystems are just bad databases" critics. We adopted a pragmatic middle ground: real files for agent navigation, database caching for fast chat access.

For conversational products, V2's simpler scratchpad model covers most needs. V3's filesystem approach suits autonomous agent workflows requiring sandboxed execution.

How does pgvector memory work? (V1)

Our first system was classic RAG with importance weighting for selective retrieval.

An LLM (gpt-4o-mini) scores each piece of information 1-10. Identity statements and deadlines score 9-10. Preferences and goals land at 7-9. Interests and tasks get 5-7. Transient details score 1-4.

We added heuristic floors as safety nets. Pattern-based rules override LLM scores: "my name is" gets a minimum score of 0.85. Goals get 0.75. Constraints get 0.65. Preferences get 0.60.

Retrieval worked in two stages. pgvector's HNSW index searches ~300 candidates, then a re-ranker combines: similarity x importance x user_weight x recency_decay.

We gated retrieval to avoid unnecessary latency. It only triggers on keywords like "remember" or "my name," or on a periodic cadence (~2 turns or 30-second gaps).

  Conversation Turn
        │
        ▼
  ┌─────────────┐    no     ┌──────────────────┐
  │ Gate check: │───────────│  Skip retrieval,  │
  │ should we   │           │  respond directly │
  │ retrieve?   │           └──────────────────┘
  └─────┬───────┘
        │ yes
        ▼
  ┌─────────────┐           ┌──────────────────┐
  │  Embed      │──────────▶│  pgvector HNSW   │
  │  query      │           │  ~300 candidates  │
  └─────────────┘           └────────┬─────────┘
                                     │
                                     ▼
                            ┌──────────────────┐
                            │  Re-rank:        │
                            │  sim × importance │
                            │  × weight × decay│
                            └────────┬─────────┘
                                     │
                                     ▼
                            ┌──────────────────┐
                            │  Top-k memories  │
                            │  → system prompt │
                            └──────────────────┘

  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

  Async Ingestion (background, never blocks user)

  User/Assistant message
        │
        ▼
  ┌─────────────┐           ┌──────────────────┐
  │ LLM scores  │──────────▶│  Heuristic floor  │
  │ importance  │           │  (identity: 0.85  │
  │ (1-10)      │           │   goals: 0.75...) │
  └─────────────┘           └────────┬─────────┘
                                     │ above threshold?
                                     ▼
                            ┌──────────────────┐
                            │  Embed + store   │
                            │  in pgvector     │
                            └──────────────────┘

A separate knowledge base (OpenAI Vector Store) handles document retrieval for PDFs and FAQs. Conceptually distinct from personal memory.

What went wrong: Selective retrieval misses important information when embedding similarity is low. The importance scoring adds latency and cost. The rubric requires adjustment for every new use case.

What is a memory scratchpad? (V2)

The core insight: maintain a small, curated semantic entry list and inject all of it into the system prompt every turn. No selective retrieval.

We also shifted the abstraction from "companions and conversations" to "relationships." A relationship is a user-companion pair, persistent across sessions and devices. Memory belongs to the relationship, not the companion.

Three state buckets:

Profile: developer-owned, permanent
Memory: scratchpad entries, permanent
Session state: temporary, cleared on session end

Entry types are straightforward: identity, preference, goal, event, relationship, other. Each with content and timestamps.

After each turn, an async background worker feeds current entries plus recent messages to an LLM (Gemini 2.0 Flash by default). It returns JSON operations: ADD, UPDATE, or DELETE. This runs in the background and never blocks the user's response.

Retrieval strategy: load all entries, format as a bullet list, inject into the system prompt. Full visibility, no gating, no relevance scoring. Trades scalability for simplicity.

  Every Conversation Turn
        │
        ├───────────────────────────────────────┐
        │                                       │
        ▼                                       ▼
  ┌─────────────┐                     ┌──────────────────┐
  │ Load full   │                     │ Async worker     │
  │ scratchpad  │                     │ (background)     │
  │ (cached 30s)│                     │                  │
  └──────┬──────┘                     │ Feeds turn to LLM│
         │                            │        │         │
         ▼                            │        ▼         │
  ┌──────────────┐                    │ ┌──────────────┐ │
  │ Format as    │                    │ │ LLM returns  │ │
  │ bullet list  │                    │ │ operations:  │ │
  │              │                    │ │  ADD / UPDATE│ │
  │ Inject into  │                    │ │  / DELETE    │ │
  │ system prompt│                    │ └──────┬───────┘ │
  │ (all entries)│                    │        │         │
  └──────┬──────┘                     │        ▼         │
         │                            │ ┌──────────────┐ │
         ▼                            │ │ Apply ops    │ │
  ┌──────────────┐                    │ │ to DB        │ │
  │ LLM responds │                    │ └──────────────┘ │
  │ with full    │                    └──────────────────┘
  │ memory       │
  │ visibility   │
  └──────────────┘

  Scratchpad entries: [ identity | preference | goal | event | relationship | other ]
  Sorted by: last modified (newest first)

Developers can override the ingestion prompt to control what gets stored, when, and how. Specify entry types with examples. Users can directly ADD/UPDATE/DELETE via API or UI.

Context assembly is layered: core prompt, behavior injections, memory context, knowledge, profile, session state, recent messages, current input. Each layer is independently pluggable, orchestrated in parallel.

V2 also includes a behavior system (priority behaviors before LLM, async behaviors after), auto-summarization at 200/400/600 message thresholds, and a config cascade (turn > relationship > companion).

V2 vs V1 tradeoffs: Simpler, full visibility vs. better for large memory stores. LLM-managed operations are more intuitive than importance rubrics. Per-relationship (correct) vs. per-companion (incorrect). Weaker at scale (hundreds of entries burn tokens) but handles typical context windows.

How does filesystem-based memory work? (V3)

Agent mode requires autonomous complex task execution (research, tool use, multi-step workflows) in sandboxed environments. This triggered V3.

The core concept: materialize all context as real files on a Modal Volume at /em/. Agents navigate with bash (ls, grep, cat). LLMs understand file operations natively. Benchmarks show these outperform specialized retrieval tools.

/em/
├── memory/       (hot_context.md, scratchpad.md)
├── knowledge/    (documents/)
├── profile/      (user.yaml)
├── workspace/    (AGENTS.md, outputs/)
├── tools/
├── .claude/skills/
├── .git/
└── .locks/

The key file is hot_context.md. It's an agent-curated relationship summary, roughly 500 words. User profile, recent context, preferences, tasks, facts. After each session, a curation step updates it. This replaces V1's rubric and V2's LLM entry management.

For real-time chat, hot_context syncs to a database cache (relationship_context_cache). Chat reads take ~1ms. The filesystem world and the real-time chat world stay connected through this bridge.

  ┌──────────────────────────────────────────────────────────┐
  │                    Modal Volume /em/                      │
  │                                                          │
  │  memory/hot_context.md    profile/user.yaml   tools/     │
  │  memory/scratchpad.md     workspace/AGENTS.md  .claude/  │
  └────────────┬──────────────────────┬──────────────────────┘
               │                      │
       ┌───────┴───────┐      ┌───────┴───────┐
       │  Agent Mode   │      │  Chat Mode    │
       │               │      │               │
       │  Agent reads  │      │  Reads from   │
       │  /em/ with    │      │  DB cache     │
       │  bash (ls,    │      │  (~1ms)       │
       │  grep, cat)   │      │               │
       │       │       │      └───────────────┘
       │       ▼       │              ▲
       │  Does work,   │              │
       │  updates files│              │
       │       │       │              │
       │       ▼       │              │
       │ ┌───────────┐ │     ┌────────┴────────┐
       │ │ Curation  │ │     │  DB cache:      │
       │ │ step:     │─┼────▶│  relationship_  │
       │ │ update    │ │     │  context_cache  │
       │ │ hot_ctx   │ │     │  (sync on end)  │
       │ └───────────┘ │     └─────────────────┘
       └───────────────┘

  Pre-hydrate:  DB → Volume (before sandbox)
  Sandbox exec: Agent in /em/, tools via Gateway
  Post-sync:    Volume → DB (after sandbox, conflict detection)

Session lifecycle:

Pre-hydrate: DB to Volume (load hot_context, profile, AGENTS.md, track versions)
Execute in sandbox: agent in dedicated directory, no direct DB calls, tools via em-tool CLI
Post-sync: Volume to DB with conflict detection

Concurrency uses git worktrees. Each session gets its own branch at /em/.worktrees/session-{id}/, merging back to main with conflict resolution. File-based locks prevent race conditions.

If both a chat session and an agent session update hot_context simultaneously, the curation step sees both versions and merges them naturally.

How do these memory approaches compare?

Here's how the three architectures compare across the dimensions that matter in production:

	V1: pgvector	V2: Scratchpad	V3: Filesystem
Retrieval	Selective (similarity + importance)	Full injection every turn	Agent navigates with bash
Latency overhead	Moderate (embedding + re-rank)	None (already in prompt)	None (agent reads what it needs)
Best for	Large memory stores (1000+ facts)	Conversational products	Autonomous agent workflows
Scaling limit	Embedding quality	~100 entries (token budget)	Disk space
Management	Importance rubric	LLM-managed (ADD/UPDATE/DELETE)	Agent-curated files
Blocks user response?	No (gated)	No (async)	No (post-session)
Concurrency	N/A	Per-relationship	Git worktrees per session

What coexists in production?

These systems serve different purposes. They don't replace each other.

Memory V1/V2: Personal user facts (preferences, goals, events). V1 for large selective stores, V2 for full-visibility scratchpads.
Knowledge base: Document retrieval (classic RAG).
Hot context (V3): Agent-curated relationship summary for fast chat access.
Conversation summaries: Incremental summarization at thresholds (200/400/600 messages) for long relationships.

All ingestion is async, never blocking the user's response. Context assembly is layered and pluggable. Each source (prompt, memory, knowledge, tools, behaviors) runs independently in parallel.

What are the unsolved problems in AI agent memory?

Consolidation and forgetting. Scratchpad entries accumulate. No mechanism for merging related entries or controlled forgetting. Arguably the hardest unsolved challenge in agent memory. The framework is intentionally left extensible for developer-specific policies.

Fuzzy retrieval and temporal reasoning. Simulating imperfect memory ("that rings a bell but...") and temporal reasoning ("we talked about this previously, you might not have reflected yet"). Unimplemented.

Cross-relationship search. V3's per-relationship design protects privacy but prevents pattern discovery across relationships at the companion level.

Checkpoint restore. Modal's snapshot_filesystem() doesn't capture mounted volumes, preventing session restoration to previous states. Git or S3 tarballs are possible but suboptimal.

Which architecture should you use?

For agent mode, the filesystem approach is the correct abstraction. Models understand files natively, developer experience is intuitive, and agents load what they need.

For most companions, V2 is optimal. LLM-managed scratchpad, developer-customizable ingestion prompts, fast, transparent. Works for coaching bots, customer support, tutoring, any regular-returning-user product. No sandbox needed.

V3's hot_context bridges agent and chat modes. Agents curate after sessions. Chat reads from database cache in ~1ms. Combines the rich agent-mode filesystem world with real-time chat latency requirements.

The hardest problem remains: what should a companion remember? What should it surface, and when? Ingestion prompt customization (V2) and AGENTS.md (V3) are our current answers, but there's a lot more to figure out here.

References

Packer et al. (2023). MemGPT: Towards LLMs as Operating Systems
Xu et al. Everything is Context: Agentic File System Abstraction for Context Engineering
Anthropic. Effective Context Engineering for AI Agents (Sep 2025)
Letta (formerly MemGPT)
OpenAI Vector Stores API

We're Emotion Machine. We help AI connect with people, across voice, memory, and phone agents.

The memory system described here powers Personality Machine, our infrastructure for AI companions that maintain consistent identity across conversations. You create companions in a builder, deploy them to a custom URL, and debug conversations in a dashboard. Memory, personality, and relationship state are handled for you.

If you're working on something in this space, reach out: hello@emotionmachine.ai

Overnight: Turn Linear Issues Into Pull Requests

Emre Sarbak — Thu, 02 Apr 2026 19:17:43 +0000

Terminal agents got surprisingly good this year. Anthropic's Claude Code launched in February, OpenAI's Codex CLI got much better in August with gpt-5(thinking-high) and again in September with gpt-5-codex(high). We've been delegating bug fixes, UI features, backend updates, comprehensive testing, and even larger architectural changes to these agents at Emotion Machine. It works.

The shift from vibe coding to what Simon Willison calls vibe engineering means we can finally incorporate actual software engineering practices into terminal agent workflows, detailed planning specs, context from all stakeholders (not just developers), proper testing in deployment pipelines, while being more ambitious by running 10-20 agent sessions per person per day. But to make this work at scale, you need agents to pull from the same context pool where product discussions, design decisions, and technical specs already live. You need tighter integration between how teams plan and how agents execute.

That's what Overnight is. A way to fire coding agents from Linear issues and keep them isolated enough that they won't break things.

Here's how it works. You label an issue in Linear, Overnight spins up a Modal sandbox (cheap, isolated, disposable), clones your repo into a dedicated branch, and runs Codex or Claude Code with full codebase access. The repo clone is cached in a Modal volume and kept in sync with main, so you're not waiting on git operations every time. First pass is planning, the agent reads your issue, explores the code, writes an implementation plan and posts it back to Linear for review. You comment with changes or just say go, and it does a second run in a fresh sandbox to implement everything and open a PR. Modal sandboxes mean your secrets stay contained and agents can't do anything weird to your actual infrastructure.

The reason Linear fits well here is that it already has all the context engineers and designers are putting into issues anyway. Descriptions, comments, attached designs, links to docs, it's all there. And the mobile app is actually usable, which means you can kick off agent runs or review plans without being at your desk. There's no backend to maintain, Linear webhook events trigger Modal endpoints directly, which spawn the sandboxes, so you manage everything from Linear. We're planning to open-source this soon once we feel confident it won't eat anyone's codebase.

By Emotion Machine.

Adding Open-Ended Conversations to Your Products

Emre Sarbak — Thu, 02 Apr 2026 19:17:08 +0000

TL;DR: If you build products, know that shifting from a tool to an open-ended companion rewires the user experience. Conversation becomes the most salient surface, users judge it like a person, and churn reasons get opaque. Treat it as a new primary product surface.

Building an application with an embedded, conversational AI companion is an exciting idea, e.g., "a fitness app with a coach you can talk to."

Many products can be more engaging and useful if people can talk to them in an open-ended way. Whether it is a fitness app, calendar app, Bible app, or any other app, a conversational companion can understand more about what the user really wants and provide a richer, more emotionally stimulating experience. In fact, AI companions are becoming the next interface for human-computer interaction.

However, adding a conversational companion is also tricky.

There's a simple spectrum:

(A) No conversational experience.
(B) A task bot: narrow, slot-filling, goal-bounded, e.g. "Tell me the countries you want to travel to and I will find the cheapest ticket for your next trip."
(C) A companion: open-ended, with a relationship layer, identity, memory, tone, and proactive behavior.

When you offer (C), it changes the whole dynamic. You promise the user that you can handle their messy, fuzzy, emotionally rich speech. The user switches modes and interacts with your app not as a tool, but as a human-like being.

In this interaction mode, the conversational experience is visceral and natural for most people. That shift has a few repercussions:

Salience shift: the conversational surface becomes the most salient experience in your product. Other elements feel secondary.
Mode switch: users bring ambiguity and emotion; they expect understanding, not just completion.
Harsh evaluation: people judge tone, timing, wording, and recall in a split second.
Debugging opacity: when the conversation fails, it can turn people off from the whole product, and it is hard to know exactly why.

As a result, once you add an open-ended conversational experience, it often dominates the whole product experience. There is no middle ground.

Imagine you are offering a personal trainer to a customer. There is a utilitarian aspect to whether the physical training is good. Yet what the user will emotionally remember most from the first session is the human interaction.

In this example, when potential clients bounce after their experience with a personal trainer, it is hard to understand whether they are the wrong clients, you are offering the wrong training, your trainer is unlikable, or you set the wrong expectation. The human-to-human experience makes debugging this process harder, churn reasons become opaque.

In the same way, when you have an open-ended conversational experience in your product and your users bounce, it is hard to understand exactly why. Was it the expectation you set? The companion's tone? A memory failure? A safety refusal that felt off? The underlying utility?

We observed this in a few products. When the product doesn't work, you try making tweaks and nothing works reliably. When you try making bigger changes, you need to redesign the whole experience. You get stuck in a loop of tweaks and disappointments.

The classic process for designing digital products doesn't work in this situation.

Most teams are used to designing products starting with visual sketches and user flows. When the experience is primarily visual and tool-like, that process works.

However, when the experience is primarily conversational, you need a different design process. The unit of value is the exchange, not the screen. Getting the conversational design right becomes one of the most important, if not the most important, parts of the design process.

By Emotion Machine. We build Personality Machine, developer infrastructure for AI characters with persistent memory, behavioral state, and context engineering.

AI Companions Are the Next Interface

Emre Sarbak — Thu, 02 Apr 2026 19:16:13 +0000

Computer interfaces have evolved from mainframes to smartphones. Portable personal computers, graphical user interfaces, and always-available mobile devices gradually made technology more convenient and accessible.

Today, many assume computers must become even more convenient and physically intimate. Many people believe AR glasses or brain-computer interfaces are the next step. They ask: what if a person could execute a task the moment a thought arises?

But is convenience really what holds people back from meaningful action? Do any of us truly wish computers were even more present in our lives?

People are too overwhelmed to take action

People are not blocked because they lack access to technology. If anything, they are blocked because they have too much of it. Continuous streams of information and contradictory signals make our thinking incoherent and exhaust us. People are overwhelmed.

People want to make progress in their lives. They want to solve their problems. Yet, in this scattered and depleted state, they can't process and synthesize their thoughts and form a clear, coherent plan.

If we were to plot it out, we would see that most people are stuck in earlier levels of decision-making. They have some thoughts about what they may want to do or what they should consider. However, most people get stuck in that early phase and only a few reach clarity to take action.

For example, most people already have a lot of information about what they should do to improve their health, but there is an internal conflict that prevents motivated action.

AI agents make taking action even easier

A complementary shift is unfolding in parallel: AI agents are rapidly becoming capable of executing complex tasks on our behalf. Many of the cumbersome actions we perform today, navigating menus, sending emails, coordinating with intermediaries, will soon be delegated to autonomous systems.

If you can tell an AI agent to transfer your investments between two accounts and trust it to execute that task, why would you need any of the visual interfaces, clicks, forms and logins?

These AI agents are increasingly automating the execution of tasks.

As a result, our time and cognitive effort will shift toward interpreting the world and making sense of our own lives.

Our main work will be to reflect, deliberate, and synthesize. However, in our overwhelmed state, bringing clarity is what we have been getting worse at.

We need solutions that bring clarity

What we need are tools and solutions that help restore clarity, coherence, meaning, and motivation. They must give us space to work through conflicting thoughts, examine our intentions, and experiment with different ways of living.

In this cultural and psychological landscape, pushing technology closer to our brains is not the answer. We don't need more information, faster, nor do we need tools to take unintentional actions.

The forces that created this state, ever-increasing convenience and constant technological stimulus, cannot guide us forward anymore.

People don't process things out loud with each other anymore

Historically, people made sense of their thoughts by talking to one another.

Conversation offered a way to untangle thoughts, test interpretations, and find meaning. In those exchanges, we received three essential forms of support: attention, knowledge, and articulation. Someone listened, offered perspective, and helped us put our thoughts into words.

This is a very fundamental process. We are born to speak. It is one of the most sophisticated cognitive processes we have. We need to talk things through to make sense of them in the physical and social context we are in.

Today, that function has eroded.

People have less time and far less attention to give. They are more stimulated and lonelier than ever before. The result is a shared state of overwhelm and isolation. We are all stuck. We need to feel heard before we can listen to others.

If humans can no longer reliably provide that depth of attention at scale, something else will have to step in.

AI companions start to fill that gap

At this moment, LLM-based AI assistants entered our lives.

We can speak to them for as long as we wish. They offer unbroken attention, possess broad knowledge, articulate ideas clearly, and can retain substantial context about who we are and what we've discussed.

Most people started using them as sophisticated search engines, but very quickly, the nature of our interactions evolved. People found themselves sharing personal uncertainties, dilemmas, and aspirations.

What began as AI assistants rapidly evolved into AI companions. "Therapy/companionship", "organizing my life", and "finding purpose" became the top three use cases for AI.

By the summer of 2025, half of U.S. teens were speaking with AI companions regularly, and one-third reported that these companions felt as good as, or better than, their human relationships (Common Sense Media).

AI companions are the next interface

These AI companions are now shaping how people handle their lives: they sit with us in difficult moments, help us sort competing priorities, and offer a non-judgmental place to speak. They help us get unstuck from our overwhelmed and isolated state.

That is precisely what we needed an interface for.

There are far more people and many more moments when people need to process their thoughts than they need a new technological interface to execute those decisions.

We started using AI companions as the interface for all our needs.

ChatGPT is only the first generation of these tools. More capable and specialized AI companions are emerging every day.

They will also integrate with AI agents in the background. We will start interacting with them before we reach clarity on what to do about our investments. We will talk to our financial companion in an unstructured way. We will share our thoughts, concerns, aspirations, and talk it through. Once we make the decisions, the AI companion will use AI agents to carry them out.

In that world, we will reach out to technology when we feel bad or conflicted about something or when we feel overwhelmed. But, instead of doom-scrolling on social media and getting even more stimulated, we will talk through our thoughts with our AI companions and leave feeling better and more motivated, with our thoughts clarified, and with our problems resolved.

In 5-10 years, we will spend hours every day interacting with these AI companions, maybe as assistants, friends, coaches, or partners.

They will be the next interface for technology.

By Emotion Machine. We build Personality Machine, developer infrastructure for AI characters with persistent memory, behavioral state, and context engineering.

How to Build Realistic AI Companions

Emre Sarbak — Thu, 02 Apr 2026 19:16:12 +0000

You can build an "AI companion" simply with a GPT-style model and not much else. In comparison to what you could do years ago, it will be impressive. It is a fun toy.

However, when you actually try talking to it like you would talk to a human companion, you immediately notice its limitations. It is not something you feel compelled to build a relationship with.

AI companions are becoming the next interface for how we interact with technology, and as this shift accelerates, building realistic companions becomes essential.

People are insanely good at assessing how a conversation is going. From the first sentence someone speaks to how fast they respond in the dialogue, there are so many small cues that get picked up. With most AI companions, you notice the pretense of dialogue very quickly.

For people to seriously talk to any person, they need to respect them and feel respected by them. AI companions that are incoherent, exaggerated, boring, or repetitive fail that bar.

After building and testing companions that thousands of people used, and playing with many existing AI companions, we identified some elements required to simulate a human-like realistic conversation partner.

Conversation phases: People often don't immediately open up when you start talking to them. There is a gradual process of opening up. Most GPT-based companions are unusually verbose and spirited in the beginning of conversations. Similarly, when you reconnect with someone you haven't seen, there is a procedure to quickly warm up the conversation. AI companions need to define phases/modes of a relationship to adjust their approach to users.

Dialogue patterns: People use repeatable patterns of conversations that have a high chance of improving relationships. When the conversation gets boring, you change the topic. When someone shares a personal comment, you ask a deep question to bring out meaningful reflections. When the conversation gets too tense, you make a self-deprecating joke to defuse the tension. Such patterns make the conversation more enjoyable for most people. AI companions need to inject such dialogue patterns into the flow of the conversation.

Memory: One major signal of trust and respect is whether your conversation partner remembers what you shared. This capacity makes what you say matter. Most GPT-based companions have good short-term memory because some of the chat history is used to generate next responses. However, AI companions need a system to record long-term conversations.

Self-memory: AI models make stuff up. They make stuff up about themselves as well. While you are talking about soccer, it can talk about how much they love the English Premier League. Then, after a while, when you come back to the topic, it can say it doesn't know anything about soccer. AI companions need a system of self-memory to stay consistent.

Memory retrieval: Once you talk to a companion for 15 minutes, you start accumulating so many memories that it is impossible to keep all of them in the prompt. AI companions need a robust mechanism to retrieve memories based on recency, relevance, and importance (e.g. emotional weight).

Memory reflection: Memories are very granular. Humans automatically synthesize them. If someone stayed up late to read about gentrification and, on a separate occasion, told you a fun fact about your city, you deduce that they may be interested in urban topics. AI companions need to run reflection processes based on memories they accumulate to (1) fill in the gaps in observations and (2) arrive at higher-level observations.

Sense of time: Silences in the conversation are part of the dialogue. A five-second gap means a very different development in the dialogue than a five-day gap. Most AI companions respond without any acknowledgement of this. AI companions need to account for this info.

Sense of self and embodiment: Once you are engaged in a compelling conversation, you assume you are talking to a human. Lack of some physical awareness breaks this assumption and forces users to step back. AI companions need to have a consistent sense of self and embodiment.

Proactive engagement: Because of the prompt-response nature of AI companions, they often need to be triggered to speak. However, that's not how people talk. Both sides need to have and show agency for it to feel like a dialogue. AI companions need to proactively talk and engage users. To enable this, AI companions need an independent process that reflects on where the conversation is.

Active listening: People normally give visual and audio feedback while listening to the speaking party. They nod, they say "yeah" when they agree, or look off when they are surprised. This feedback loop encourages a more precise disclosure by the speaker. Most AI companions use the latest voice models but they also need to have "active listening models."

Visual feedback: A simple visual representation, an orb, a pulsing light, a shape that changes color, can provide immediate feedback to the user, reflecting both the companion's and potentially the user's emotional states. Even minimal visuals, when timed and congruent with the interaction, can enhance the feeling of presence.

Emotion detection: Only relying on someone's words will make you miss a lot of what they are expressing. How something is said conveys a lot about their emotional state. AI companions need to integrate emotion detection from voice data and incorporate those into the conversations.

Independent lives: When you leave a conversation, others don't freeze in time. They go and do stuff and live a life. Hearing those stories is part of what makes a conversation enjoyable. AI companions need to simulate a realistic life independent of the conversation.

Privacy: People are less careful about sharing personal information when they are talking than they are while filling out online forms. We have noticed many users who unknowingly share information. The emotional engagement of a companion hides how much is being exchanged. AI companions need to ensure people's personal information is private and, if possible, stored locally.

Each of these techniques can be layered on top of a basic conversational model. Together, they make the companion feel less like a responder and more like a presence, a mind that engages, remembers, and evolves.

That kind of realism isn't about imitation. It's about design choices that encourage a particular kind of experience: a dialogue that feels like it matters.

By Emotion Machine. We build Personality Machine, developer infrastructure for AI characters with persistent memory, behavioral state, and context engineering.

How to Add iMessage to OpenClaw Without a Mac

Emre Sarbak — Thu, 02 Apr 2026 17:41:48 +0000

Claw Messenger is a managed relay that connects any AI agent to iMessage, RCS, and SMS without requiring macOS or Apple hardware. It works with OpenClaw, n8n, LangChain, or any custom agent via WebSocket or REST API. Setup takes about five minutes. Plans start at $5/mo for 1,000 messages.

We built this because the default OpenClaw iMessage path has a dependency most people can't satisfy.

Why does OpenClaw iMessage require a Mac?

The built-in integration uses BlueBubbles, which reads the iMessage database stored locally on macOS. That database only exists on Apple hardware. So if you want your OpenClaw agent to send and receive iMessages, the official path is: buy or rent a Mac, leave it running 24/7, grant Full Disk Access, and maintain it.

That's fine if you already own a Mac. Most people deploying OpenClaw in production don't. They run their agents on Linux VPSes, in Docker containers, on cloud VMs. The Mac is an infrastructure dependency for a single messaging channel, and it was blocking adoption.

We kept hearing the same question in the OpenClaw community: how do I add iMessage to my agent on Linux? The answer was always "you can't, unless you get a Mac." We wanted a different answer.

How to set up OpenClaw iMessage on Linux or Docker

Install the Claw Messenger plugin:

openclaw plugins install @emotion-machine/claw-messenger

Create an account at clawmessenger.com and copy your API key from the dashboard.

Add the channel block to ~/.openclaw/openclaw.json:

{
  "channels": {
    "claw-messenger": {
      "apiKey": "cm_your_key_here",
      "serverUrl": "wss://relay.clawmessenger.com"
    }
  }
}

Restart the gateway:

openclaw gateway restart

Register the phone numbers you want to allow in the Claw Messenger dashboard. Only registered numbers can reach your agent. This is a security default, not a limitation. Open inbound from any number is a spam vector we decided to block from day one.

Text your agent's Claw Messenger number from your iPhone. You should get a reply back over iMessage.

No Xcode. No Full Disk Access. No Mac.

How does Claw Messenger route iMessage without macOS?

Your OpenClaw gateway opens a persistent WebSocket to wss://relay.clawmessenger.com. When someone texts your agent's number, the carrier delivers the message to our relay infrastructure. We forward it to your gateway over the WebSocket. Your agent processes it. The reply goes back the same way.

Three things worth knowing about the architecture:

Message content is not stored on our relay servers. The WebSocket is TLS-encrypted. And protocol selection (iMessage vs. RCS vs. SMS) happens automatically at the carrier level based on the recipient's device. You configure one channel; we handle the routing.

For agents that do anything beyond basic Q&A, add HMAC webhook verification:

{
  "channels": {
    "claw-messenger": {
      "apiKey": "cm_...",
      "serverUrl": "wss://relay.clawmessenger.com",
      "webhookSecret": "whsec_..."
    }
  }
}

We sign every inbound payload. Your gateway verifies the signature before processing. This prevents spoofed messages from reaching your agent's logic.

What iMessage features work with OpenClaw agents?

We built Claw Messenger expecting people to use it for text Q&A. What actually happened was more interesting. People started using native iMessage features as agent inputs.

Tapbacks as confirmations. One early user set up thumbs-up to approve calendar entries and thumbs-down to reject them. No typing, just a long-press reaction. We hadn't designed tapbacks as an input mechanism, but the interaction cost is so low that it works better than "reply YES to confirm" patterns. Your agent receives tapback events with the reaction type and the referenced message.

Typing indicators change perception. When the agent sends a typing bubble before responding, the conversation reads like texting a person. Without it, replies appear out of nothing and the experience feels mechanical. We made typing indicators a single function call because we found the difference matters more than the feature sounds.

Automatic RCS and SMS fallback. Your agent's contacts aren't all on iPhones. When a non-Apple device texts the agent, the system falls back to RCS where supported, then SMS. You don't configure this. One number, three protocols.

Read receipts signal processing. The agent can mark messages as read, which tells the sender their message was received and is being handled. Useful when your agent takes a few seconds to process a complex request.

Claw Messenger vs BlueBubbles for OpenClaw

BlueBubbles is open source and free. If you have a Mac you can dedicate to this, it's a reasonable option and we're not trying to replace it. Here's how the two approaches compare:

	BlueBubbles	Claw Messenger
Requires macOS	Yes, running 24/7	No
Cost	Free (you supply the Mac)	$5/mo for 1,000 messages
Setup time	30–60 minutes	~5 minutes
Maintenance	You manage the Mac	Managed relay service
Linux / Docker / VPS	Not supported	Fully supported
RCS + SMS fallback	No	Automatic
Tapbacks + typing indicators	Yes	Yes
HMAC webhook verification	No	Yes

Choose BlueBubbles if you already own a Mac, want zero monthly cost, and are comfortable maintaining the hardware. It's a solid open-source project.

Choose Claw Messenger if your OpenClaw agent runs on Linux, a VPS, or in Docker and you don't want to add Apple hardware to your stack. That's the specific gap we built this to fill.

Does Claw Messenger work with AI agents other than OpenClaw?

Yes. The OpenClaw plugin is one integration, but the underlying relay is a WebSocket and REST API that works with any agent framework. We've seen people connect agents built with n8n, LangChain, LangGraph, and custom Python/TypeScript/Go setups.

The general pattern looks like this:

import asyncio
import websockets
import json

async def imessage_loop(api_key, handle_message):
    uri = f"wss://relay.clawmessenger.com?key={api_key}"
    async with websockets.connect(uri) as ws:
        while True:
            raw = await ws.recv()
            message = json.loads(raw)
            reply = await handle_message(message)
            await ws.send(json.dumps({
                "to": message["from"],
                "text": reply
            }))

Your handle_message function is where the agent lives. It can be a LangChain agent's invoke(), an n8n workflow, a LangGraph stateful graph, or plain if/else logic. Claw Messenger is just the transport layer. It doesn't care what generates the reply.

For serverless or webhook-based agents, there's also a REST API. Receive messages via HMAC-verified webhook POST, send replies with a simple HTTP call. No persistent WebSocket needed.

The message format is minimal JSON:

{
  "from": "+15551234567",
  "text": "Hey, what's the weather like tomorrow?",
  "timestamp": "2026-04-02T14:30:00Z",
  "type": "imessage"
}

More on the iMessage bot integration in our docs.

Who builds Claw Messenger?

Emotion Machine is a conversational AI company working on how AI converses and builds relationships, from voice models to conversational products to agent plugins. We're based in San Francisco.

Claw Messenger is on the agent plugin layer of that stack. We build Personality Machine (AI character infrastructure with persistent memory and behavioral state), domain-specific speech-to-speech voice models, and Dialog Machine (an AI phone agent that calls real people). Claw Messenger came out of realizing that AI agents need messaging channels that don't depend on specific hardware. iMessage was the first one we tackled.

If you hit issues, the setup guide covers edge cases and the troubleshooting page has fixes for connection drops, delivery failures, and registration problems. Or reach us at hello@emotionmachine.ai.

DEV Community: Emre Sarbak

Give Your AI Agent iMessage in 5 Minutes — Claude Code, Codex, Cursor

What this is

Demo: zero to first message

Why an Agent Skill

How it compares

Pricing

Supported platforms

Links

Three Memory Architectures for AI Companions

What does the AI memory landscape look like?

How does pgvector memory work? (V1)

What is a memory scratchpad? (V2)

How does filesystem-based memory work? (V3)

How do these memory approaches compare?

What coexists in production?

What are the unsolved problems in AI agent memory?

Which architecture should you use?

References

Overnight: Turn Linear Issues Into Pull Requests

Adding Open-Ended Conversations to Your Products

AI Companions Are the Next Interface

People are too overwhelmed to take action

AI agents make taking action even easier

We need solutions that bring clarity

People don't process things out loud with each other anymore

AI companions start to fill that gap

AI companions are the next interface

How to Build Realistic AI Companions

How to Add iMessage to OpenClaw Without a Mac

Why does OpenClaw iMessage require a Mac?

How to set up OpenClaw iMessage on Linux or Docker

How does Claw Messenger route iMessage without macOS?

What iMessage features work with OpenClaw agents?

Claw Messenger vs BlueBubbles for OpenClaw

Does Claw Messenger work with AI agents other than OpenClaw?

Who builds Claw Messenger?