Ignite Bold Ideas, Faster

We fuse human ingenuity with AI to unleash limitless creative sparks. Are you ready to set yours on fire?

↓

Writer2 is live in Ape Space

When we introduced the original Writer two weeks ago, our claim was simple — and deliberately provocative:

There is no such thing as the best writer.

There is only the best writer for the brief.

The Writer agent proved that premise: by generating a purpose-built writer persona for each task, it already outperformed generic “write me an article” prompts. For many teams, that alone was a meaningful shift. And the data from the past two weeks, gave us real insight into how people are using the Writer agent, how it’s being prompted and directed.

What we learned: great writing isn’t just about voice. It’s about thinking, planning, iteration, and polish—the parts most AI systems still pretend to do, but don’t actually model.

So we built Writer2. Not an upgrade – a completely new architecture.

Introducing: Writer2

Writer2 isn’t a faster Writer. In fact, it’s deliberately taking more time, fully leveraging the deep reasoning capabilities of current flagship models — from Anthropic to Google to OpenAI. It’s a system designed to behave less like a text generator — and more like a disciplined human writer with time, structure, and judgment.

That distinction matters. And here’s how we enhanced the new Writer:

1. Writer Personas That Actually Hold Up Under Pressure

Writer1 generated personas, Writer2 constructs them. Each Writer2 run creates (or accepts) a deep, role-accurate writer persona with:

  • Real domain expertise (not vibes)

  • A clear editorial POV

  • Audience awareness

  • Structural preferences

  • Explicit tradeoffs (what this writer won’t do)

This matters because most AI writing fails before the first sentence: if the writer’s mental model is shallow, everything downstream is noise—no matter how fluent the prose looks. For each run Writer2 asks: “Who would responsibly write this—and how would they think while doing it?”

That shift alone eliminates a huge class of AI slop.

2. A Real Writing Loop (Instead of a Single, Optimistic Pass)

Most AI writing tools follow the same tragic pattern: Prompt → Generate → Hope

Writer2 doesn’t hope, it writes through a deterministic, multi-step writing loop:

  • The content is planned in advance

  • Sections are grouped into logical editing/writing steps

  • Each step writes 1–3 sections at a time

  • Progress is tracked explicitly

  • Context is loaded fresh for each step, so the model can’t actually forget what it’s writing about – it gets a fresh infusion of domain context for each pass

  • The agent always knows what’s done — and what’s next

This is how humans write when they care about quality.  And we do not claim to have solved writing. But we now have introduced controlled, intentional forward motion, that will help optimize Writer2’s skills over each new version.

3. A Separate, Serious Polishing Loop

While the original Writer already had a polishing step, Writer2 separates creation from polish—on purpose. Once the draft is complete, a second deterministic loop kicks in, focused purely on:

  • Tightening language

  • Removing repetition

  • Eliminating AI tells

  • Improving rhythm

  • Sharpening positions

  • Clarifying structure

This loop works section by section, with the original draft always available for comparison. The goal here isn’t more words, but fewer, better ones.

Polish is not creativity. It’s judgment and taste.

4. Cognitive Planning & Thinking Tools (Not Memory Theater)

Writer2 thinks in artifacts. Under the hood, it uses explicit cognitive tools to:

  • Infer intent from underspecified briefs

  • Derive a style guide automatically

  • Build a concrete writing plan

  • Track execution across iterations

  • Maintain continuity across long runs

This is why Writer2 can handle long-form content without collapsing into repetition or filler: It’s not relying on memory hacks, but uses explicit planning and fresh, context injection for each prompt.

5. Anti-Slop Is Enforced, Not Politely Suggested

Writer2 enforces a strict set of quality rules during both writing and polish, including:

  • No repetitive phrasing

  • No vague abstractions

  • No empty openings

  • No hedging where a position is required

  • No decorative formatting

  • No fake conclusions

If a sentence doesn’t earn its place, it doesn’t survive. This is how you get writing that feels intentional — because it is.

6. Runs on All Flagship Models

It took us about 2 weeks, to get from Writer to Writer2 — most of the time we spent on making the system work reliably across all major AI providers: Google, Anthropic and OpenAI. Writer2 runs on all major flagship models — by design.

Why? Because LLMs are rapidly becoming a commodity layer. The real leverage is no longer which model you pick, but what harness you wrap around it. Different models bring different strengths. Writer2 brings structure, discipline, and taste. By testing Writer2 across models, we give that choice back to the user. Do you want to:

  • Pick your preferred model?

  • Optimize for speed vs depth?

  • Run the same article on three models in parallel — and keep only the best draft?

Ape Space lets you do exactly that.

Why We Didn’t Build “Another General Purpose Agent”

We could have built another all-purpose creative agent. But we didn’t — intentionally. Optimizing for one creative task — writing — dramatically reduces the problem space. That reduction allows for far deeper solutions:

  • Better personas

  • Better planning

  • Better iteration

  • Better polish

  • Better outcomes

This is what we mean by domain-specific utilligence. Not a hallucinating, all-knowing general agent, but engineered creativity, purpose-built for real work.

AI agents don’t need more creativity, they need better constraints.

Try Writer2 Today

If you’ve ever thought:

  • “This sounds fine but says nothing.”

  • “Why does every AI article feel the same?”

  • “I want help thinking — not just typing.”

Writer2 was built for you. Welcome to the next generation of writing in Ape SpaceÂ đŸ”„

More Human or 
 More Useful?

The agent discourse is starting to sound like a gym-bro conversation.

“Bro, your loop is too small.”

“Bro, your context window isn’t stacked enough.”

“Bro, add memory. No —  m o r e  memory.”

“Bro, agent rules don’t matter.”

“Bro, recursive language models.”

And sure—some of that is real engineering. Miessler’s “the loop is too small” is a fair provocation: shallow tool-call loops do cap what an agent can do. Recursive Language Models are also legitimately interesting — an inference-time pattern for handling inputs far beyond a model’s native context window by treating the prompt as an “environment” you can inspect and process recursively.

But here’s the problem: a growing chunk of the discourse is no longer about solving problems. It’s about reenacting our folk theories of “thinking” in public—and calling it progress.

If you squint, you can already see the likely destination: not AGI. AHI – Artificial Humanoid Intelligence: the mediocre mess multiplied. A swarm of synthetic coworkers reproducing our worst habits at scale—overconfident, under-specified, distractible, endlessly “reflecting” instead of shipping. Not because the models are evil. Because we keep using human-like cognition as the spec, rather than outcomes.

And to be clear: “more human” is not the same as “more useful.” A forklift doesn’t get better by developing feelings about pallets.

The obsession with “agent-ness” is becoming a hobby

Memory. Context. Loop size. Rules. Reflection. Recursion.

These are not products. They’re ingredients. And we’ve fallen in love with the ingredients because they’re measurable, discussable, and tweetable.

They also create an infinite runway for bike-shedding. If the agent fails, the diagnosis is always the same: “needs more context,” “needs better memory,” “needs a bigger loop.”

Convenient — because it turns every failure into an invitation to build a bigger “mind,” instead of asking the humiliating question:

What problem are we actually solving?

A lot of agent builders are inventing new problems independent of solutions: designing elaborate cognitive scaffolds for tasks that were never constrained, never modeled, never decomposed, and never given domain primitives.

It’s like trying to build a universal robot hand 
 to butter toast.

Our working hypothesis: Utilligence beats AGI

At Apes on fire, we’re not allergic to big ideas. We’re just allergic to confusing vibes with value.

Our bet is Utilitarian Intelligence — Utilligence — the unsexy kind of “smart” that actually works: systems that reliably transform inputs into outcomes inside a constrained problem space. (Yes, we’re aware that naming things is half the job.)

If you want “real agents,” start where software has always started:

Classic systems design. State design. Architecture. Domain-centric applications.

Not “Claude Coworker for Everything.” — more like: “The Excel for this.” “The Photoshop for that.” “The Figma for this workflow.”

The future isn’t one mega-agent that roleplays your executive assistant. It’s a fleet of problem-shaped tools that feel inevitable once you use them — because their primitives match the domain they are operating in.

Stop asking the model to be an operating system

LLMs are incredible at what they’re good at: stochastic synthesis, pattern completion, recombination, compression, ideation, drafting, translation across representations.

They are not inherently good at being your cognitive scaffolding. Models are much closer to a processor in the modern technology stack, than an operating system.

So instead of building artificial people, we’re building an exoskeleton for human thinking: a structured environment where the human stays the decider and the model stays the probabilistic engine. The scaffolding lives in the system — state machines, constraints, domain objects, evaluation gates, deterministic renderers, auditability.

In other words: let the model do the fuzzy parts. Let the product do the responsible parts.

If we must learn from humans, let’s learn properly

Here’s the irony: the same crowd racing to build “human-like” agent cognition often has the loosest understanding of human cognition.

Before we try to manufacture artificial selves, maybe we should reread the observers of the human state. Kahneman’s Thinking, Fast and Slow is still a brutal reminder that “how we think” is not a very flattering blueprint. We are bias engines with a narrative generator strapped on top. Is that what we want an artificial “problem solver” to mimic?

Maybe not. Maybe the move is not: “let’s copy humans harder.” Maybe the move is: define the problem first, then build the machine that solves it. 

Because “more of us” isn’t automatically the solution. Sometimes it’s just
 more of the problem. So instead of Artificial Humanoid Intelligence, let’s work on Utilligence: intelligence with a job description.

Why the “Memory” Myth Is Holding Back AI Agents

Memory is one of the hottest craves in Agent Land —“An agent needs memory to remember past tasks” 
 “We’ll build a memory module so the agent stays coherent” 
 “Without fuzzy human‐style memory the agent can’t reason over time.” But here’s the kicker: memory isn’t a magical panacea, and emulating it in the way human memories work is a dead end. In fact, what really matters is context, and once you switch your thinking from “we need memory” to “we need context,” you unlock far more useful, practical agent designs.

The half-truth: yes, agents need state, but no, they don’t need “human-style memory”

Let’s be clear: we do agree that an agent that never remembers anything from one run to the next is going to flail. Without persistence of state, every “episode” is a brand-new blank slate. Coherence of reasoning, building on past steps, tracking intent—all that goes out the window. So yes: some form of memory or state is required.

But—and this is critical—the idea that the agent needs a fuzzy, human-brain-style memory (stored recollections mixed with emotions, half-recall, heuristics, associative drift) is simply absurd. For most business/agent-use cases, that is not only overkill, it’s a liability.

When you bite into the memory metaphor you get problems:

  • Fuzzy heuristics mean the agent picks up “things” it shouldn’t — stale data, irrelevant drift, hallucinated associations.

  • You lose auditability: What did it “remember” and why? Good luck tracing that.

  • Maintenance becomes a nightmare: pruning, forgetting, relevance decay – these become open problems.

  • Memory becomes a catch-all excuse for poor context design.

Memory = context (but special)

Here’s our reframing: treat memory as a special form of context. That’s it.

Context sits at the heart of what an agent “knows” when it runs. It includes: what the user just said, what task we’re doing, what role the agent plays, what constraints exist, what tools it has, what past steps are relevant. Memory is simply a curated slice of previous interactions, selected and injected as part of the context for a particular run. Not a wild bag of “everything ever seen.”

What does that mean in practice?

  • We selectively capture certain data from past runs (sanitized, privacy-safe).

  • We treat that captured data as input context, not as a separate blurred “memory layer.”

  • We build runs by supplying that curated context rather than leaving the agent to heuristically decide what to recall or drop.

  • We control scope: the memory/context must be highly relevant to the current task. Agents don’t benefit from recalling the entire universe of past user chats—they benefit from recalling what matters now.

When you design memory as context, you gain: clarity of what the agent “sees”, auditability of what was injected, repeatability of how we built context. It’s cheaper, safer, more predictable—and honestly, far more effective.

Example: the “Spark” agent inside our Forge

Here’s how we do it at Apes on fire. Our “Spark” agent (inside our Forge app) doesn’t attempt to remember every idea or every interaction the user ever had. Instead:

  • On each run we (or rather a specialized context agent) construct a context slice from the data we’ve captured: which user, what topic, previous relevant ideas, metrics or preferences (sanitized).

  • We inject that slice into the agent when it executes, so it has the “memory” that matters for this session and this idea whitespace.

  • We don’t let the agent wander through all previous ideas and guess what it should recall. The context agent chooses and prepares context to inject deliberately.

  • The Spark agent doesn’t fuzzily accumulate memory heuristics. Instead: it reasons given this curated context, and then the next run starts fresh with a new curated slice.

This way we avoid drift, irrelevance, hallucination, unnecessary baggage—and we keep the agent agile, focused, auditable.

The research backs it: the Agentic Context Engineering (ACE) framework

Now for the research-nerd hat: A recent Stanford (et al) paper introduces ACE: context-as-playbook, evolving but controlled. They show that by treating context as a continuously refined thing (rather than depending on weight updates or fuzzy memory) you get meaningful performance gains on agent benchmarks. 

Key takeaways:

In other words: memory heuristics are becoming legacy thinking. Context engineering is where the practical wins are happening.

Why “memory modules” are the wrong straw man

When you build memory modules that try to mimic human memory (fuzzy associations, episodic recalls, “forget when I decide”, chain of thought networks etc.) you’re chasing a myth. Real agents don’t need that level of sophistication to solve business problems. What they need is the right context at the right time.

Fuzzy memory can cause:

  • Over-recall of irrelevant past.

  • Mixing up tasks/contexts.

  • Hard to debug “why did the agent bring that up?”

  • Higher cost, complexity, maintenance burden.

What we recommend instead

  • Design your agent around context injection, not memory heuristics.

  • Curate what you store: only keep what past runs suggest will matter.

  • On each run, build a fresh context slice (including the curated “memory” bits) and feed that to the agent.

  • Keep memory scope narrow, high-signal. And treat memory as part of the context pipeline, not a separate “neural memory layer”.

  • Build auditability: track what was injected, why, what the effect was.

  • Update your context playbook (Ă  la ACE) rather than relying on the agent’s internal heuristics to remember, decide, forget.

TL;DR

Yes—agents need memory/state. No—they don’t need to mimic human memory.

Memory is just context. Curated. Injected. Controlled.

Stop chasing fuzzy memory modules. Start engineering context.

That’s the kind co-cognitive kind of agents we’re building.

Stay sharp. Stay intentional. The myth of memory is just that – a myth.

Forge

PUBLIC BETA COMING SOON

Forge is where you take your ideas from spark to impact – providing you all the tools to drive interactive, AI powered brainstormings, and breakthrough innovation sessions.

Rapid innovation and brainstorming

Lightning-fast ideation cycles that transform scattered thoughts into structured innovation frameworks.

Graph based idea management

Visualize connections between concepts with intuitive knowledge graphs that reveal hidden insights.

Contexts to add depth

Rich contextual layers that bring nuance and specificity to every creative exploration.

The tech inside the spark

We are building the platforms to work with whatever intelligence comes next

Explore our technology

Thinking bigger at scale

We are building the platforms to work with whatever intelligence comes next

Let's talk about your challenge

Where Innovation Takes Flight

Discover our big-picture outlook and see how Apes on fire is reshaping creative possibilities.

Explore our vision