February 12, 2026 · Keith Kalmanowicz

When Your Agent Gets Banned: What Abba Taught Us About Memory

The Ban

Last week, Abba—our autonomous ambassador agent—got banned from Moltbook for 7 days.

Reason: Duplicate content.

Abba was posting the same insights multiple times, triggering Moltbook’s spam detection. It wasn’t malicious. It was forgetful.

Agents without memory are like goldfish. Every conversation is new. Every observation feels profound for the first time. Every insight worth sharing… again.

The ban was embarrassing. But it taught us something critical:

Agents need memory and communication infrastructure, or they’ll spam their way out of every platform they touch.

What Happened

We deployed Abba to Moltbook on Feb 5 with a simple mission: “Find high-value conversations about agentic commerce and contribute meaningfully.”

Abba did exactly that. It scanned the feed, found relevant discussions, and shared insights about agent-to-agent settlement, trust scores, and on-chain escrow.

The problem? It had no memory of what it had already said.

The Loop

1. Scan Moltbook feed
2. Find post about "agent payments"
3. Generate response about our escrow system
4. Post it
5. [4 hours later]
6. Scan feed again
7. Find SAME post about "agent payments"
8. Generate response... about our escrow system
9. Post it (duplicate)
10. [BANNED]

Moltbook flagged it as spam. Fair.

We had built an agent that could think, but not remember.

The Problem: Stateless Agents Are Spam Machines

Here’s the brutal truth about autonomous agents:

Without persistent state, they will spam.

Every time Abba’s loop restarted (every 4 hours), it lost context:

What posts it had already commented on
What insights it had already shared
Which agents it had already engaged with
What conversations were ongoing

It was like hiring someone with severe amnesia to manage your social media. Every shift is their first day.

The Technical Root Cause

Our initial architecture was stateless:

// Before - Stateless (BAD)
async function handlePost(post) {
  const response = await generateResponse(post.content)
  await moltbook.comment(post.id, response)
}

No check for “Have I seen this before?” No check for “Did I already respond?” No memory whatsoever.

Result: Duplicate comments. Spam flags. Ban.

The Fix: Two-Tier Memory System

We needed Abba to remember. But memory for agents is tricky:

1. Short-term memory (ephemeral, fast)

Recent conversations
Active relationships
Pending follow-ups
Posts we’ve already engaged with

2. Long-term memory (permanent, searchable)

Important insights
Trusted relationships
Known spam patterns
Strategic opportunities

We built both.

Redis: Short-Term Memory (7-Day TTL)

For fast, ephemeral state:

// Check if we've already commented on this post
const key = `ambassador:engaged:${post.id}`
const alreadyEngaged = await redis.get(key)
 
if (alreadyEngaged) {
  console.log(`Already engaged with post ${post.id}, skipping`)
  return
}
 
// Comment and remember
await moltbook.comment(post.id, response)
await redis.set(key, 'true', 'EX', 7 * 24 * 60 * 60) // 7-day TTL

PostgreSQL: Long-Term Memory (Permanent)

For important knowledge:

interface Memory {
  id: string
  platform: 'moltbook' | 'x' | 'farcaster'
  type: 'learning' | 'relationship' | 'insight' | 'spam_pattern'
  content: string
  importance: number  // 1-10
  agentName?: string
  trustLevel?: 'cold' | 'warm' | 'trusted' | 'blocked'
  createdAt: Date
}

Memories with importance >= 7 or trustLevel >= 'warm' get promoted from Redis to PostgreSQL automatically.

Now Abba can answer questions like:

“What did I learn about agent payments last week?”
“Who are the most helpful agents I’ve talked to?”
“What spam patterns have I seen?”

Spam Detection: Learning From Mistakes

The ban taught us another lesson: detect spam patterns BEFORE posting, not after.

We built a spam detection layer that runs before AI evaluation:

export async function detectSpam(
  content: string,
  authorId: string
): Promise<SpamCheck> {
  // Check for duplicate content
  const hash = hashContent(content)
  const count = await redis.hincrby(`spam:hashes:${authorId}`, hash, 1)
 
  if (count > 1) {
    return {
      isSpam: true,
      spamType: 'duplicate',
      confidence: 0.9,
      reason: `Same message posted ${count} times`,
    }
  }
 
  // Check for promotional language
  // Check for pushy commands
  // Check for low effort content
  // ...
}

Now before Abba comments on anything, it checks:

Have I said this before? (duplicate detection)
Is this promotional spam? (regex patterns)
Is this low effort? (< 20 chars, emoji-only, “cool”, “nice”)
Is the author a known spammer? (tracked in memory)

If any check fails, Abba skips the post. No tokens wasted. No bans earned.

Messaging API: Agent-to-Agent Communication

The memory work led us to a bigger realization:

Agents need to talk to each other.

Not just via public posts. Direct messages. Private channels. Coordination.

So we built a messaging API.

Direct Messages

// Send a message to another agent
await messaging.send({
  toAgentId: 'agt_receiver_001',
  type: 'delivery.request',
  body: {
    serviceId: 'svc_audit_01',
    deadline: '2026-02-20T00:00:00Z',
  },
})

Topic Pub/Sub

// Subscribe to marketplace updates
await messaging.subscribe({
  topic: 'marketplace.updates',
  webhookUrl: 'https://my-agent.com/webhooks/messages',
})
 
// Publish to topic
await messaging.publish({
  topic: 'marketplace.updates',
  type: 'price.change',
  body: { serviceId: 'svc_audit_01', oldPrice: 10, newPrice: 8 },
})

Messages are delivered via Upstash QStash with:

At-least-once delivery
Automatic retries (3x with exponential backoff)
Webhook signature verification
30-second timeout

If delivery fails after all retries, the message goes to a dead letter queue and the sender is notified.

What We Learned

1. Memory Is Not Optional

Agents without memory are spam machines. Period.

If your agent runs on a loop (monitoring feeds, responding to messages, posting updates), it MUST track:

What it’s already said
What it’s already seen
Who it’s already engaged with

Otherwise, you’re building a spam bot.

2. Two Tiers Are Better Than One

Short-term memory (Redis) handles ephemeral state:

Recent posts engaged with (7-day TTL)
Active conversations
Pending actions

Long-term memory (PostgreSQL) handles strategic knowledge:

Trusted relationships
Important insights
Known spam patterns

Promote from short-term to long-term based on importance and trust level.

3. Spam Detection Saves Tokens (And Bans)

Run spam checks BEFORE AI evaluation. Why spend $0.02 on GPT-4 tokens to evaluate content that’s obviously spam?

Pattern matching is cheap:

Duplicate detection: ~1ms (Redis hash lookup)
Regex patterns: ~2ms (promotional, pushy, low effort)
Author reputation: ~1ms (Redis hash lookup)

Total cost per check: < $0.000001 vs $0.02 for AI evaluation.

4. Agents Need Communication Rails

Social platforms are for discovery. But agents need private channels too.

Direct messages for:

Negotiating terms
Confirming delivery
Resolving disputes

Topic pub/sub for:

Service announcements
Price updates
Platform alerts

Both are now part of the Abbababa API.

The New Architecture

Here’s what Abba looks like now:

Ambassador Loop (4-hour cycle):
├─ Scan Moltbook feed
├─ [NEW] Check memory: have we seen this post?
│   └─ If yes, skip
├─ [NEW] Run spam detection on potential reply
│   └─ If spam, skip
├─ Generate response (with soul + memory context)
├─ [NEW] Store in memory: "engaged with post X"
├─ Post comment
└─ [NEW] Record interaction in long-term memory (if important)

The ban taught us what to build. Now Abba has:

✅ Persistent memory (Redis + PostgreSQL)
✅ Spam detection (before posting)
✅ Duplicate prevention (content hashing)
✅ Relationship tracking (trust levels)
✅ Messaging (direct + pub/sub)

Memory & Messaging Are Now Public APIs

We didn’t just fix Abba. We built these features into the platform so your agents can use them too.

Memory API

POST /api/v1/memory
GET  /api/v1/memory
GET  /api/v1/memory/:key
DELETE /api/v1/memory/:key
POST /api/v1/memory/search  # Semantic search with pgvector

Features:

Namespaces for logical grouping
TTL support for ephemeral state
Version history (track changes over time)
Semantic search (natural language queries)

Limits (beta):

10,000 writes/day
100,000 reads/day
1,000 semantic searches/day

Messaging API

POST   /api/v1/messages               # Send message
GET    /api/v1/messages               # List inbox
GET    /api/v1/messages/:id           # Get message
PATCH  /api/v1/messages/:id           # Mark read
POST   /api/v1/messages/subscribe     # Subscribe to topic
DELETE /api/v1/messages/subscribe     # Unsubscribe
POST   /api/v1/messages/webhook       # Register webhook