DEV Community: Cogweald

An agent needs to create new entities to truly grow

Cogweald — Thu, 24 Sep 2026 06:51:47 +0000

An agent that can only modify a fixed set of rows has a hard time producing an open-ended system.

Cogweald does not completely predefine the cast of every world. The model can introduce a new character in a chapter, and the application stores that character with added_by = 'llm' so future chapters can use it.

The important part is not that AI can insert a row. It is provenance.

Every entity should have an answer to “where did this come from?” It may have been created by the creator, introduced by the LLM, or synchronized from an external tool. Once an agent can create data, provenance affects review, debugging, UI decisions, and future deletion strategies.

Open-ended generation needs two things:

An extensible domain model
A data model that tracks origin

Without provenance, an autonomous system eventually struggles to answer a basic question: why does this thing exist?

Give the AI suggestions, not a script

Cogweald — Tue, 22 Sep 2026 23:49:44 +0000

If a user can specify exactly what must happen in the next chapter, the AI becomes a writing tool and the world stops being autonomous.

Cogweald treats creator hints as wishes from a producer, not hard commands. A creator can suggest a direction, while the model can mark the hint as followed, delayed, twisted, or ignored and explain its decision.

This preserves two important things: human intent and agent judgment.

It also creates a more interesting product interaction. The creator is not clicking buttons to control every plot point. They are watching a system with its own logic respond to a suggestion. The hint becomes part of long-term state and can have consequences later.

For other agent products, this suggests a useful pattern: model human input as a preference, constraint, or hypothesis instead of treating every message as the highest-priority command.

An agent with a real point of view must be able to say, “Not yet.”

An offline cron can be a strong product decision

Cogweald — Tue, 22 Sep 2026 00:54:17 +0000

Not every AI product needs to generate something in real time.

Cogweald advances each world once per day instead of generating the next chapter when a reader opens the page. That choice improves three things at once: user experience, cost control, and content consistency.

Readers know that new content arrives on a predictable cadence instead of seeing different versions generated on demand. The system can run during off-peak hours. A model failure does not block the reading experience.

More importantly, asynchronous generation makes “the world keeps running while you are away” part of the product experience. The user is not operating a tool; they are checking in on a system with its own rhythm.

Teams often treat real-time as the default answer. For some AI workflows, latency is not a flaw. It is part of the pacing, reliability model, and cost model.

Does the feature you are building really need to be real time?

One world, one LLM call

Cogweald — Mon, 21 Sep 2026 01:49:57 +0000

AI product costs often become unpredictable not because the model is too expensive, but because the architecture calls the model too many times for the same operation.

Cogweald intentionally keeps chapter generation to one LLM call per world. That call produces the content, summary, time span, character updates, thread updates, and long-term facts together.

This is not about cramming everything into one prompt. It starts with designing an output contract so one reasoning result can become one complete domain event.

The benefits are straightforward:

Costs are easier to estimate.
Each chapter has one source of truth for its decisions.
A summary model cannot contradict a content model.
Retry semantics are easier to reason about.
Token usage is easier to observe.

Single-call is not always the right answer. Workflows that need multiple validation stages or tool interactions may need multiple calls. Before splitting, ask whether those calls truly need different reasoning boundaries.

A cron job is not just “ask the model to run”

Cogweald — Sun, 20 Sep 2026 06:53:35 +0000

When an AI job runs once a day, it is easy to underestimate the distributed-systems problems hiding underneath.

What if the scheduler retries? What if two workers claim the same world? What if the model succeeds but the database connection drops before the chapter is stored?

Cogweald treats daily advancement as a claim-based transaction flow. A world’s last_tick_at acts as both the schedule marker and the claim token. A worker must successfully claim the tick before it is allowed to generate a chapter.

That small design prevents one of the most dangerous failure modes: cron jitter producing two chapters for the same world on the same day.

Reliability in AI systems often comes less from a better prompt and more from ordinary-looking conditional database updates.

Once an agent can change the world on its own, design its state transitions with the same care you would use for a payment flow.

Autonomous agents need guardrails, not line-by-line scripts

Cogweald — Fri, 18 Sep 2026 00:10:25 +0000

Autonomous does not mean uncontrollable.

Cogweald’s model can decide what happens next in a world. It cannot change the database schema, bypass authorization, arbitrarily rewrite published content, or turn unvalidated text directly into system state.

The guardrails live outside the model:

Output must match a structured schema.
World state can only change through the server-side persistence layer.
Character and thread transitions must follow defined rules.
A failed generation must not commit half of a world update.
Every tick has a claim guard to prevent duplicate execution.

The model gets creative freedom. The system owns consistency.

This is one of my favorite agent design principles: do not describe every rule in a prompt. If code can guarantee something reliably, let code guarantee it. Give the model the decisions that actually require semantic judgment.

A plot thread is really a state machine

Cogweald — Wed, 16 Sep 2026 23:57:41 +0000

“Let the AI advance the story” sounds exciting, but without a state model, every chapter quickly starts inventing the same problems again.

Cogweald models long-running plot lines as story threads. Each thread has a title, description, status, and timestamps. Its status can be active, resolved, or abandoned.

When a chapter is generated, the model does not only return prose. It also returns thread updates: which thread advanced, which one was resolved, and whether a new one should be opened. The application applies those decisions to the database and provides the updated state to the model next time.

This turns continuity from a hope into an observable and verifiable state transition.

The same pattern works for any agent that needs long-term planning:

An unfinished refactor for a coding agent
An unverified hypothesis for a research agent
A customer risk for a success agent
A quest line for a game agent

If an agent needs to remember what is still unfinished across multiple runs, it probably deserves a state machine.

Summaries drift. Facts should not.

Cogweald — Tue, 15 Sep 2026 23:59:21 +0000

Summaries are useful for helping a model understand a long history quickly. But a summary is a compressed interpretation, not the original fact.

After an event is summarized seven times, details can slowly change. A character’s motivation shifts. The order of events changes. A possibility becomes a certainty. This is the long-term agent version of the telephone game.

Cogweald separates long-term memory into two layers:

Chapter summaries preserve narrative flow.
Story facts preserve important state that must remain consistent.

Facts carry importance, creation chapter, and invalidation metadata. When the world changes, an old fact is explicitly invalidated instead of being silently overwritten.

This pattern is useful far beyond stories:

A support agent can store approved customer terms as facts.
A coding agent can store the current migration strategy.
A game agent can store the abilities a player has unlocked.

A summary tells an agent what happened. A fact tells it what it must not casually change.

A context window is a workbench, not a memory

Cogweald — Tue, 15 Sep 2026 00:14:48 +0000

Putting the last few conversations into a prompt does not give an AI long-term memory.

It is closer to dumping every file on a desk and hoping the model finds the important pages. That can work for a short demo. Over time, tokens become expensive, context becomes noisy, and critical information gets buried.

Cogweald separates its story bible into memories with different lifetimes:

Current character state
Active plot threads
Recently closed threads
Long-term facts
Summaries of the latest chapters

Each category has a different purpose and context window. Recent summaries provide local continuity. Facts preserve information that must not drift. Threads show the model what is still unfinished.

Context engineering is not about putting more information into the prompt. It is about putting the right information there at the right time.

If your agent must read the entire database before every decision, the problem may not be the model. Your memory model may need a better design.

https://www.cogweald.com

Let the LLM be the author, not a scripted text formatter

Cogweald — Sun, 13 Sep 2026 23:58:51 +0000

If every decision is hard-coded, the LLM is just an expensive text formatter.

Cogweald draws a clear boundary: code owns the constraints, while the model owns creative decisions.

The application guarantees the output schema, database constraints, world state, and permissions. The model decides which character steps forward, which thread advances, and how much story time passes based on the current state of the world.

That is very different from letting the model output anything it wants. Freedom does not mean having no rules. It means preserving room for judgment inside well-defined boundaries.

Our model returns a headline, content, summary, time span, thread updates, character updates, and facts. These fields do not exist to force creativity into a spreadsheet. They make unpredictable creative decisions possible to persist reliably.

Good agent architecture does not hard-code every decision or hand every decision to the model. It draws the right line between the two.

Treating “one day” as a system primitive

Cogweald — Sun, 13 Sep 2026 02:46:48 +0000

For most AI apps, the unit of time is a request.

A user sends a message, the model responds, and the workflow ends. Cogweald is designed around a different primitive: one real day.

Each world can advance by at most one chapter per day. That sounds like a product rule, but it is also an important systems abstraction. It gives state changes a rhythm, makes costs predictable, and gives readers a reason to return at a known cadence.

It also creates a real engineering question: what happens when the cron job fires twice? How do we prevent one day from advancing twice? We use a database-level tick claim, turning the time window into a state transition that can be claimed and verified.

Time is not just a date label in the UI. Once it affects permissions, cost, scheduling, and consistency, it becomes a core product primitive.

What concept in your product is currently treated as a string, but should really be modeled as system state?

Most AI products forget. Cogweald is designed to remember.

Cogweald — Sat, 12 Sep 2026 04:23:58 +0000

Many AI demos feel intelligent until you ask the same question the next day.

The problem is often not the model. The product simply has no durable world state. The conversation ends, the memory ends with it, and the next request starts from a blank page.

Cogweald takes a different approach: put AI inside a world that keeps running. Characters have state. Events leave consequences. Unresolved threads remain active. What happened yesterday constrains what can happen today.

This is more than adding a memory table. The hard questions are:

Which information deserves to survive?
Which information is no longer valid?
How do we show the model the right context before its next decision?

We are not trying to build another chat window. We are exploring what an AI system looks like when it can accumulate history.

What should your AI product never forget?