Developer Forks Paperclip, Adds Agent Memory and MCPs

There's a particular kind of developer who can't leave well enough alone. They find a tool, use it for a week, identify exactly three things that drive them nuts, and then fork the entire project to fix it themselves. Hamish, who runs the Income Stream Surfers YouTube channel, is very much that developer.

He's been working with Paperclip, an open-source AI agent system that lets you assign tasks to different specialized agents (think: a CMO agent, an engineer agent, a product manager agent). The original project is solid, he says, but it had some deeply annoying limitations. So he did what any reasonable person would do: he forked it and started coding.

The result is paperclip-surfers, an experimental branch that adds conversation memory, MCP (Model Context Protocol) integration, and user-installable skills. What makes this interesting isn't just the features—it's the crossing of a threshold. "I've been someone who's very firmly in the camp of this isn't actually useful yet," Hamish says in the video. "This kind of AI and stuff, it's not actually useful yet. But now I'm starting to really understand the use here."

That's the line between AI-as-demo and AI-as-tool. Let's look at what pushed him across it.

The Conversation Memory Problem

The core issue with vanilla Paperclip, according to Hamish, was that every interaction with an agent started fresh. You'd assign a task, the agent would complete it, and then the next task would be like meeting a stranger. No context. No continuity. No memory that you'd literally just discussed this.

"I thought to myself, what is the point in that?" Hamish explains. "It would be much better if every time you sent an issue to a new agent or to an agent, it continued the last conversation."

With Claude's Opus now supporting a 1 million token context window, there's technically room for this. You can fit entire project histories in a single conversation thread. The original Paperclip attempted conversation continuity, but apparently not aggressively enough for Hamish's workflow.

His fork makes it native. When you assign a new task to an agent, it picks up where the last conversation left off. The agent already knows what you discussed. It doesn't need a recap.

But continuity isn't the same as memory—at least not the kind that persists across projects and self-corrects. That required a different approach.

Agent Memory and Self-Improvement

Hamish added a dedicated memory system that lets agents learn from corrections. If you tell an agent something once—"our trial period is 3 days, not 7"—it's supposed to internalize that and stop making the same mistake.

The original Paperclip had system instructions (basically, a configuration file you could edit), but Hamish wanted something more dynamic. "Wouldn't it be cool if every time I the CEO or myself, the board mentions something, then it makes a note of that and adds it to its memory," he says.

Now when you correct an agent, you can manually add it to memory: "Remember trial is 3 days." That becomes a global memory accessible across all projects. It's not true learning in the ML sense—there's no gradient descent happening here—but it's persistent context that survives session boundaries.

The practical impact: agents stop repeating corrected errors. They build up a shared knowledge base. Whether this actually scales or becomes unmanageable spaghetti is an open question (Hamish doesn't address it), but the direction is clear. Static instructions → dynamic, accumulating memory.

MCP Integration: The Real Game-Changer

Here's where it gets genuinely interesting. MCP—Model Context Protocol—is Anthropic's system for letting Claude connect to external tools and services. Think Stripe for payments, GitHub for code, PostHog for analytics, Composio for third-party integrations.

Hamish's fork lets you sync MCPs from Claude Desktop and then selectively enable them for specific Paperclip agents. Need your engineer agent to have GitHub access but not your CMO? You can configure that now.

The demo he shows is instructive. He connects Composio to pull data from his YouTube channel—his top 50 performing videos, complete with thumbnail analysis. Then he assigns that to an agent and has it create a skill based on the analysis. Later, he connects PostHog (an analytics platform) and has his analytics agent pull product usage data.

"So now I would be confident in making an entire project with Stripe inside it using Paperclip," he says. "I can start to do customer service etc etc."

This is the part where the abstraction becomes concrete. MCPs turn Paperclip from a self-contained agent system into something that can actually interact with your actual business infrastructure. The agents aren't just writing code in a sandbox—they're pulling real analytics, accessing real payment data, potentially taking real actions.

Which, you know, should probably terrify us a little? But let's stay neutral here.

User Skills: Modular Capabilities

The last major addition is user-installable skills—basically, pre-packaged capabilities you can assign to specific agents. These are stored in Claude's skill system, and Hamish's fork lets you select them per-agent.

The example he gives: after analyzing his YouTube thumbnails via Composio, he had the system create a skill from that analysis. Now he can assign that skill to a "thumbnail designer" agent (or realistically, repurpose his CMO agent). The agent loads that skill before starting any task.

What's less clear from the video: what exactly constitutes a "skill" in this context? Is it structured prompts? Tool access? A combination? Hamish doesn't dig into the implementation details, which makes it hard to evaluate how flexible or brittle this system is.

But the architectural pattern is solid: modular, composable capabilities that agents can load on-demand rather than carrying every possible skill all the time.

The Moment of Conversion

There's a moment in the video where Hamish's product manager agent flags a 404 error on his pricing page. He didn't know it was broken. The agent found it, created an issue, and assigned it to the engineer agent to fix.

"Is that really 404? Oh my god. Jesus," he says, genuinely surprised.

That's the thing about actually using these systems versus demoing them. The demo is you showing the AI doing what you already knew needed doing. The actual use is the AI finding the thing you didn't know was broken.

That's the conversion moment—not when the tool does what you tell it, but when it surfaces information you weren't looking for.

What This Actually Means

So here's what we're looking at: a developer took an existing agent framework, added persistence (memory), external connectivity (MCPs), and modular capabilities (skills). The result is apparently useful enough that he's shifting from skeptic to believer.

But the interesting tension here is between the fork and the original project. Hamish is clear that he's not claiming credit for Paperclip itself—this is his experimental branch. Whether these features make it back into the main project, whether they're too opinionated for general use, whether they break in ways he hasn't discovered yet—all unknowns.

What's not unknown: the gap between "cool AI demo" and "tool I actually use" is narrowing. For some workflows, apparently, it's already closed.

The code is public (github.com/IncomeStreamSurfer/paperclip-surfers). Whether it's useful for your specific use case, you'll have to determine yourself. But watching someone cross from skepticism to utility in real-time? That's worth paying attention to.

—Yuki Okonkwo