DEV Community: Can Ceylan

Two AI agents need one live memory file

Can Ceylan — Wed, 29 Apr 2026 07:06:23 +0000

Problem

Parallel AI coding feels magical until both agents start maintaining their own version of reality.

One agent remembers a rule from chat history. The other reads a repo note that is already stale. A workflow gets updated in one place but not the other. The user ends up repeating the same instruction twice, forwarding approvals manually, and cleaning up collisions that should never have happened.

In practice, the user becomes the synchronization layer.

Real cause

The root problem is not "bad memory." It is multiple writable memory surfaces.

If one agent treats a handoff file as live state, another agent treats a different file as live state, and both also rely on thread memory, the system has no clear authority. Drift is guaranteed.

The same thing happens with parallel edits:

no single place to check whether another lane is active
no explicit ownership boundary
no habit of writing what changed, why, and what not to touch

The agents are not just missing information. They are missing a shared contract about where truth lives.

Why this takes longer than it should

This failure mode is subtle because each individual step feels reasonable.

documenting in two places feels safer
asking the user to confirm again feels polite
starting work before checking for another active lane feels fast

But those local optimizations create a global tax:

duplicated instructions
overwritten edits
ambiguous approvals
no usable history when something breaks later

The system looks collaborative on the surface while quietly depending on the user to keep it coherent.

The operating model that fixes it

Use one mutable collaboration-memory file and make everything else point to it.

Then add four rules:

Current truth has one home.
One live file holds active rules, ownership, open lanes, and recent decisions.
History is preserved, not silently deleted.
Resolved rollout history moves to an archive file so future debugging can reconstruct what changed and why.
Cross-agent review is direct.
If one agent needs the other's approval, use a direct review/delegation mechanism instead of making the user relay the same context twice.
Parallel work starts with a pre-flight check.
Before meaningful edits, check for active lanes, declare ownership, and define a do-not-touch boundary if overlap is possible.

A simple template that works

Keep a tiny Active Work block in the live memory file:

- owner: Codex
- scope: admin workflow cleanup
- started: 2026-04-29 08:30 Vienna
- do-not-touch: app/admin/* until handoff

That one block turns "I thought nobody was in there" into an avoidable mistake instead of an excuse.

Reusable rule

If multiple AI agents touch the same codebase, the collaboration system is part of the product.

Do not optimize only for generation quality or coding speed. Optimize for:

one live memory source
explicit temporary ownership
direct agent-to-agent review
traceable history

Otherwise the user will end up doing project management by hand while the agents appear autonomous.

That is not automation. It is outsourced coordination.

Scheduled publishing without a cron: runtime-evaluated date filters

Can Ceylan — Tue, 28 Apr 2026 12:09:21 +0000

The cron-dependent approach and its failure mode

The standard approach to scheduled publishing: a cron job runs at the scheduled time, updates a published flag in the database, and the content becomes visible.

The failure mode: the cron job misses its window. The newsletter fires at 07:00. The cron job that was supposed to set published: true at 06:55 didn't run — server restart, network issue, timing drift. The newsletter goes out with a link to a 404.

The cron approach has a single point of failure between "content ready" and "content visible."

Runtime evaluation: the always-consistent alternative

Instead of updating a flag, evaluate visibility at request time:

export function getAllArticles(): ArticleMeta[] {
  const now = new Date();
  return readAllMdxFiles()
    .filter(article => {
      if (!article.scheduledDate) return article.published;
      return new Date(article.scheduledDate) <= now;
    })
    .sort((a, b) => /* by date */);
}

An article with scheduledDate: "2026-04-20T10:00:00Z" is invisible until that moment, then visible to every request after it — without any cron, any database update, any deployment.

The MDX frontmatter pattern

---
title: "My scheduled article"
scheduledDate: "2026-04-20T10:00:00Z"
published: false
---

published: false plus a future scheduledDate means: draft, not yet visible.

published: false plus a past scheduledDate means: automatically visible now.

published: true means: always visible, regardless of date.

The two fields serve different purposes. published is manual override. scheduledDate is automatic timed release.

The dual-mechanism for newsletter integration

Runtime evaluation handles visibility. It does not handle triggered actions — like sending a newsletter when an article goes live.

For that, you still need a cron. But now the cron has one job: check if any article became visible in the last N minutes and fire the newsletter. It no longer needs to update the database first.

// Cron at 07:00 UTC
const recentlyPublished = getAllArticles()
  .filter(a => {
    const pub = new Date(a.scheduledDate ?? a.date);
    const windowStart = new Date(Date.now() - 60 * 60 * 1000); // last hour
    return pub >= windowStart && pub <= new Date();
  });

for (const article of recentlyPublished) {
  await sendNewsletter(article);
  // Optionally: commit published: true to MDX to prevent re-sending
}

The key difference: the article is already visible before the cron runs. If the cron misses its window, the article is still live — only the newsletter is delayed, not the publication.

The consistency guarantee

Runtime evaluation gives you a simple invariant: an article with a past scheduledDate is always visible, on every server, in every region, with no state to sync. There's no "published in one region but not another" problem because there's no state — just a comparison against the current time.

This makes it particularly well-suited for static site generators and edge-rendered content, where database updates would require a redeployment.

Trade-offs

What you gain: simplicity, consistency, no failure mode from missed cron jobs, works on read-only filesystems.

What you give up: instant unpublishing (you'd need to remove the file or set scheduledDate to a future date), and the ability to see exactly which articles are "live" without querying at a specific time.

For most publishing workflows, the gains outweigh the trade-offs.

Soft deletes aren't just for audit trails — they're your sales pipeline

Can Ceylan — Mon, 27 Apr 2026 08:14:00 +0000

Why marketplaces shouldn't hard-delete listings

When a listing goes inactive on a marketplace — a seller closes their account, a venue cancels, a product is removed — the naive response is to delete the record. It's gone, it's irrelevant.

But that record contains exactly the information you need to win them back:

Contact details
What they listed and at what price
When they were last active
Why they stopped

A hard delete destroys all of this. A soft delete — setting isActive = false — preserves it. Your inactive records become your CRM.

Enforce it at the database level, not in application code

Application-level soft delete is fragile. Any developer, any migration script, any admin panel with a "Delete" button can bypass it. Six months later someone writes a cleanup script that issues DELETE WHERE isActive = false and you lose your entire lapsed-user pipeline.

The reliable approach is to remove DELETE permission from the application database role entirely:

-- Application role: can read, insert, update — cannot delete
REVOKE DELETE ON TABLE listings FROM app_role;

-- Admin role: can delete, but only with explicit confirmation
GRANT DELETE ON TABLE listings TO admin_role;

Now isActive = false is not a convention — it's the only option the application has. Hard deletes require admin credentials and an explicit action.

What to build on top of inactive records

Once you've preserved the data, build the re-engagement workflow:

Filter inactive records by time since last activity (30 days, 90 days, 6 months)
Segment by what they listed — different outreach for high-value vs casual sellers
Track re-activation rate as a metric separate from new user acquisition

The conversion rate on re-engaging inactive users is almost always higher than acquiring new ones. They already know your platform. Something caused them to stop — a direct outreach with a specific reason to return is often enough.

The naming convention matters

Don't name the column deleted or is_deleted. Name it isActive or status. The framing shapes how developers think about the data.

A column called deleted invites deletion-by-update thinking — "we're pretending it's deleted." A column called isActive frames it correctly — this is an active/inactive lifecycle state, not a tombstone.

When soft delete is the wrong pattern

Soft delete adds complexity. It means every query needs a WHERE isActive = true clause, or you risk surfacing inactive records in user-facing views.

It's worth the overhead when:

Inactive records have re-engagement value (marketplaces, SaaS)
You need audit history for compliance
Users expect to be able to reactivate ("I want my old account back")

It's not worth it for truly ephemeral data — log entries, session records, temporary tokens. Hard delete those.

The rule of thumb: if a business person would want to contact the entity represented by that record, soft delete it.

Autotest With Social Posts

Can Ceylan — Sat, 25 Apr 2026 03:37:42 +0000