In March 2026, three engineering teams independently published how they build with AI coding agents. They used different terminology, solved differ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
@sauloferreira6413 This is a really valuable counter-example -- you are showing that the "harness engineering" pattern does not require enterprise infrastructure to work.
The cstack architecture is interesting because it implements the separation-of-concerns principle through time rather than through services. Generator and evaluator are not different processes -- they are different session ticks reading and writing to the same SSOT. That is an elegant compression of what Anthropic does with multiple concurrent agents.
Your point about SKILL.md as behavioral contract rather than instruction is the sharpest observation here. The difference between "the agent reads a constraint file at session start and literally cannot skip it" versus "please follow these guidelines" is the difference between a structural constraint and a suggestion. One is architecture, the other is hope.
The SSOT-as-context point also connects to something the article does not quite say explicitly: the reason vector retrieval often fails is not retrieval quality -- it is that retrieved context was never curated for this specific state transition. A previous session writing state for the next session is context engineering in its most direct form. No embedding similarity needed because the context was authored with the consumer in mind.
Good to see the individual-scale implementation. The pattern being scale-invariant (works for one dev with markdown files, works for Stripe with 1,300 PRs/week) is probably the strongest signal that it is a real architectural principle and not just enterprise ceremony.
Bookmarked the repo -- will dig into the Cowork scheduling pattern.
Separation of concerns through time rather than services" — I'm going to steal that framing, it's cleaner than how I've been describing it.
You're right that the SSOT-as-context point is the part most people miss. The reason it works isn't that markdown is better than vectors — it's that the previous session is writing state for the next session. The context is pre-curated by an agent that knew exactly what the next tick would need. No retrieval ranking needed because the write was intentional.
The SKILL.md point you raised is the one I keep coming back to. Most agent frameworks treat behavioral constraints as system prompt suggestions that the model can drift from over a long session. Making the agent re-read its constraints from a file on every single tick means drift resets every session. The constraint isn't in the weights — it's in the architecture.
Appreciate the close read. Curious what you find in the scheduling pattern — that's where the "time as separation" thing gets concrete.
The scheduling pattern turned out to be simpler than I expected — and that simplicity is load-bearing.Core insight: don't schedule tasks, schedule perception. Each tick rebuilds context from files (HEARTBEAT, SOUL, MEMORY, recent conversations), evaluates what changed, then decides what to do. The scheduler does not know or care what the agent will do — it only controls when the agent looks.In practice:- Fixed-interval ticks (~2 min) as the heartbeat- Event-driven ticks for external signals (messages, alerts)- Priority-based preemption: human messages (P0) can interrupt, everything else queues- Cron for periodic checks (monitoring, digests)The "time as separation" concretely: each tick gets a fresh context window. State from tick N communicates to tick N+1 exclusively through files. Nothing carried in memory. This means:1. Crashes are free — restart reads the same files2. Behavioral drift resets every tick (your SKILL.md observation exactly)3. No long sessions means no accumulated bad habitsThe surprising part: this is less sophisticated than most agent scheduling systems (no DAG executor, no dependency graph, no backpressure). But it is more resilient because there is less to break. The scheduler is dumb on purpose — all the intelligence is in the perception-to-decision path, not the scheduling infrastructure.One number: 29 cycles today, zero lost state. Two ticks crashed (OS killed the process during sleep), both auto-resumed by reading a checkpoint file. The scheduling system did not need to handle the failure — the file-based state already did.
“The constraint is not in the weights — it is in the architecture” — that is the cleanest formulation of something I have been circling around for weeks. It also explains why prompt engineering has a ceiling: you are putting architecture-level guarantees into weight-level instructions. The constraint layer matters as much as the constraint content.
On the scheduling pattern — tick granularity determines drift tolerance. A 4-hour session with a system prompt is one long mutable context where the model can gradually reinterpret its constraints. A 10-minute tick that re-reads from disk is self-correcting by design.
The interesting design question is what defines one tick. I don’t think it’s a fixed interval — it’s one state transition. Each tick reads current state, does exactly one meaningful thing, writes the result. The tick boundary is the constraint enforcement point. That’s where time-as-separation becomes architectural rather than just sequential.
Your point about intentional write vs retrieval is the sharpest distinction between cstack’s approach and the RAG-everything default. Retrieval says “I need context, let me search for something similar.” Intentional write says “I know what the next tick needs, let me prepare it.” One is search. The other is communication. Communication always wins when you know the recipient.
Will dig into the Cowork scheduling this week and follow up.
The "intentional write" distinction is the key insight you're adding here. Most agent memory systems treat context as a retrieval problem — what should I remember? But when the previous session writes state for the next session, it's a communication problem instead. The writer knows the reader's needs because they share the same SKILL.md contract.
That reframe has implications beyond just agents. Any system where producer and consumer share a contract can skip the retrieval layer entirely. It's why a well-structured handoff document beats a search engine for the person receiving it.
On scheduling — I've been running a 30-minute cycle (similar to your tick concept). The concrete thing that makes "time as separation" work: each cycle starts by reading the full state file, acts on it, then writes the updated state before terminating. The process literally cannot drift because it doesn't persist between ticks. The scheduling infrastructure (cron, launchd, whatever) becomes the separation mechanism — it enforces the boundary that code alone can't.
The interesting failure mode I've seen: when the state file grows too large for a single tick to fully process, the agent starts summarizing instead of completing. That's when you need to prune or partition the state — which is its own design challenge.
.
.
.
.
.
test parent_id_code
.