Posts — Jordan Moak

The Work Should Compound

2026-09-07T00:00:00Z

I want to choose when an application needs me. Right now, a dependency I picked eight months ago gets a vote.

That's part of owning software, but I don't believe it has to consume so much of our attention. AI has made the interruptions easier to deal with. I can get an assistant into the repository and work through the problem. What bothers me is how often I still have to get that process started, especially when we've dealt with something similar before.

Maybe we understood this integration perfectly well six months ago. We fixed the issue. We discussed why it happened. Somewhere in that work was enough knowledge to make the next occurrence much less dependent on me; apparently we didn't leave it in a form the system could use.

Eventually, I want to hand over a meaningful piece of development and have the system carry it through. Each recurring maintenance task we can delegate gives us a concrete way to work toward that. The place to start is during development, while we're already doing the expensive work of understanding the application.

What else should a feature leave behind?

Consider an export feature that stops working for older accounts after a change to the data model. Someone investigates and discovers that a field didn't always exist.

The fix might be two lines. Finding out which two lines could take an afternoon.

When we resolve it, I'd like us to ask what would let the system handle this situation without us next time. A representative old account that we can recreate in isolation would help. We could use it to check future migrations. We also need to preserve why the behavior matters: the customer should still be able to export their older records, even if supporting them is inconvenient for the current implementation.

Writing that expectation in a document helps the next developer. Making the account reproducible, and requiring it to pass before a migration ships, changes what the development process can do.

But the regression test is only part of it. The system needs to know when to run it and have somewhere to investigate a failure. It also needs a defined basis for accepting the resulting change. If I still have to connect those steps every time, I've automated a check. I haven't automated the work.

The ingredients are familiar. We already have regression tests and release pipelines. What's often missing is the connection that lets a detected need become completed work without somebody moving it between tools. I want us to build and verify that connection alongside the feature.

I'm calling the approach maintenance by construction, with Tendie as the working name for the system. Working on a feature should also improve our ability to hand over future work on it.

The old-account fixture becomes a condition future changes must satisfy, rather than an observation somebody needs to remember.

We discover the requirements by building

I don't know everything a feature needs when I start implementing it. Building it is how I find out. Any serious approach to automated development has to account for that.

Sometimes an apparent defect exposes a product question we never answered. Does an export include deleted records? The current code can tell us what happens today. It can't establish whether that behavior is what we want.

If I decide deleted records must stay excluded, that decision needs to become an executable check. The next export change should encounter the rule without needing to find the conversation where we settled it.

I can deliberately change that decision later. A repair agent shouldn't be able to change it because including deleted records makes its patch easier. Those changes need different authority, even if they eventually touch the same test.

Protected doesn't mean permanent. We can improve our understanding as we build; the point is to make each decision usable by the next round of work.

What I want a maintenance run to do

Here's the intended behavior; we haven't built this complete loop yet.

A dependency approaches the limit of our support policy. That creates an upgrade task without waiting for me to notice. The system prepares a candidate in a disposable environment, where the old-account export check fails.

We know which behavior failed and can reproduce it. The cause still needs investigation, but the agent doesn't have to invent the expected result while debugging. The account we preserved during development gives it somewhere to work without experimenting on a customer's data.

Suppose the proposed repair makes the check pass. That qualifies it for further evaluation, not immediate release. The other required checks still apply to the exact candidate we'd deploy. The process also needs an appropriate recovery path if the change behaves differently under real conditions; rolling back code won't necessarily undo what it wrote to a database.

If the candidate satisfies the release policy, the system deploys it and observes the result. If the checks remain inconclusive, it stops within its budget and brings back the unresolved problem. A decision to stop supporting older records would come to me. That's a change to what the product offers, and the upgrade task doesn't have permission to make it.

The interesting part is how much of this run depends on work we've already done. We aren't asking an agent to rediscover what an old account is or negotiate acceptable data loss. We're giving it a development task whose conditions have become specific enough to delegate.

The trigger starts the work. Protected acceptance criteria determine how far it may proceed.

This is why I think the reproducible environment matters so much. It's useful while we're developing the feature, and it gives future automation a place to work. We can improve the same capability rather than build a second, approximate version of the application for an agent.

How much can we actually hand over?

My instinct is still that every meaningful requirement needs a way to exercise it. That's a substantial amount of work. I don't see how we get serious about automated development while treating validation as something we'll fill in later.

An isolated end-to-end test won't be sufficient for every requirement. An export can finish successfully while exposing another customer's records. Features can also work on their own and interfere with each other. The checks have to address the reasons we'd reject a change, including behavior beyond the path that first failed.

For an existing app, I'd start with the workflows that matter most. When I'm already investigating a problem, that's a good moment to capture its conditions. When a feature is under development, I'm available to answer questions about what it should do. We should use that access well; I don't expect an assistant arriving months later to recover a decision I never recorded.

As coverage improves, particular classes of work can qualify for automation. A routine dependency update may qualify before a database migration does. That distinction should be explainable in terms of the evidence and consequences. Success with one kind of change doesn't grant authority over another.

Sometimes the best contribution to future automation will be removing a dependency or simplifying the feature. I don't want to preserve a complicated process just because we've taught an agent to operate it.

The routine machinery should stay small too. Checking a support deadline doesn't need an AI conversation. An unfamiliar failure may deserve substantial reasoning. In What the Next Change Shouldn't Have to Know, I explore how architecture can reduce the amount of reasoning future work requires by taking over obligations we'd otherwise have to keep rediscovering.

Put a limit on that effort too. A system that spends all night producing unsuccessful patches owes me a useful account of the unresolved problem. It hasn't earned credit for being busy.

There will be uncovered behavior, and the system needs to say so. Every check passing only tells us about the checks we have. It doesn't eliminate the possibility that our understanding is wrong. My argument for treating AI as a resource depends on how we arrange imperfect components; the validation needs that same scrutiny. A simulator can agree with an implementation because they share a bad assumption.

Jerbs is where I'm starting

Jerbs observes public company career sources and preserves changes in job postings. It gives us a useful test: can the system adapt to a changed source without inventing changes in the company we're observing?

A source returning incomplete data shouldn't become evidence that a company stopped hiring. If we get that wrong, every subsequent explanation is reasoning from a collection defect.

Jerbs already preserves the source evidence so we can revisit the interpretation. We've started strengthening the checks a proposed parser repair must satisfy. The autonomous repair loop is still ahead of us; the next experiment needs to demonstrate an incorrect repair being refused as well as a correct one being accepted.

I want to carry this approach across my stack, but the common machinery has to earn its generality through different applications. Otherwise we could build something excellent at parser repair and spend the next year forcing everything else into it.

Buy back the next afternoon

I believe the real opportunity is to make development progressively less dependent on our presence.

I still want to choose what my applications do. But once I've made a decision, I want the system to become better at completing work within it. If an external change makes that decision insufficient, bring me the actual question. Don't make me reconstruct the entire repository to find out what you're asking.

The measure has to include the cost of maintaining Tendie itself. Moving the interruptions into a more elaborate system won't buy back any time. I want to see a class of work that used to need my attention become something the application can handle, with enough evidence that I can reasonably leave it alone.

If I fix the same class of problem faster next month, that's useful. If the system can handle it without me next month, the development work has changed what owning the application costs.

I believe we should build for that second outcome much more deliberately.

What the Next Change Shouldn't Have to Know

2026-06-26T00:00:00Z

I don't want to keep paying for somebody to understand the same problem.

Sometimes that somebody is me. Increasingly, it's an AI assistant working through a repository until it has enough context to make a change. The investigation may be excellent. But if the next change needs the same investigation, I think we should look at what the first one left behind.

Documentation helps. A regression test can preserve a failure we'd otherwise have to rediscover. There's another possibility I want us to take seriously: changing the architecture so future work no longer depends on resolving the same question.

I believe that's one of the better uses of increasingly capable reasoning. Use it to reduce how much somebody has to get right next time.

An answer we can stop needing

An application asks another service to create a resource. The request times out.

We don't know whether the service failed before creating it or created it and lost the response. Retrying might create a duplicate. Investigating might require access to the other service, and its state could change while we look.

Now give the operation a durable identity and have the receiving service enforce an idempotency contract: repeating that operation produces no additional effect within the contract's scope. The caller can retry with the same identity.

We still don't know what happened. We can proceed anyway.

AWS describes this tradeoff in Making retries safe with idempotent APIs. The service takes on complexity so its callers can safely do less. Recording the request identity and performing the mutation must work together; otherwise a crash between them recreates the ambiguity. The contract also needs limits, including how long a repeated request remains recognizable.

The difficult work hasn't evaporated. We've put it somewhere that can handle it for every caller using that contract.

That's a more useful result than teaching every caller to investigate a timeout. A whole set of possible histories now permits the same next action. Recovery needs less information.

Context efficiency has to be earned

I think this is where architecture belongs in the conversation about AI context.

A smaller file doesn't necessarily make a change easier to reason about. If its behavior depends on an ordering assumption buried elsewhere, somebody still needs to find that assumption. A concise summary might mention it, but now correctness depends on the summary staying accurate and the next developer following it.

An architectural boundary can go further. It can take responsibility for the ordering so callers don't have to manage it. That responsibility must be real: if callers can bypass the boundary through an ordinary code path, the obligation still belongs to them too.

Parnas made the underlying distinction in his 1972 paper on modularity. He organized modules around design decisions they concealed, rather than simply dividing the program into processing steps. The point was to contain the consequences of those decisions, including their eventual replacement.

For our purposes, I'd judge a boundary by what someone can safely leave out of their reasoning. The caller of our idempotent operation still needs to understand request identity and expiry. It shouldn't need to reconstruct the service's crash history.

That is context efficiency I can believe in. The smaller context follows from fewer responsibilities.

Give uncertain work less authority

This becomes particularly useful when I think about software maintaining itself.

In Jerbs, which observes public job postings, a parser may need to change when a company changes its careers page. Suppose a proposed parser produces fewer postings than the previous version. That could reflect actual removals. It could also mean the parser missed half the page.

If parser output directly determines which postings disappear, accepting that change requires confidence in both extraction and the meaning of every absence. We've given uncertain interpretation considerable authority.

I want the design to separate those responsibilities. A parser can propose observations from preserved source evidence. Removing a posting should require a separate basis for treating the collection as complete and authoritative. A successful parse alone doesn't establish either.

That does not solve the completeness problem. It gives it a place to be handled explicitly, where every parser must encounter the same rule. Matching a source's reported count might be one check; it wouldn't establish that the source itself told the truth.

The architectural gain is specific: an omission in a parser need not automatically become a deletion in the product. A future repair can have narrower authority, with checks aimed at the consequences it can actually cause. This is the direction we're working toward in Jerbs, not a claim that its autonomous maintenance is finished.

I believe that matters more than how impressively an agent can explain a proposed patch. We've changed what a mistaken patch is allowed to do.

The boundary has a cost

It's possible to take this too far. A framework can centralize every decision until changing anything requires understanding the framework.

I'd look for obligations that recur and are stable enough to enforce. Preventing a retry from duplicating the same operation is a good candidate. Deciding whether a customer should be allowed to request a second resource is a product choice. The operation's identity needs to preserve that distinction.

Enforcement also concentrates trust. A defect in a shared boundary can affect all its callers, so that boundary deserves focused verification. We should count its maintenance cost against the work it saves. Another abstraction earns nothing merely by existing.

And some questions still belong to the complete application. The end-to-end argument explains why reliability inside a lower layer cannot necessarily establish the outcome the application needs. Avoiding duplicate resource creation doesn't tell us whether we created the right resource for the right customer.

That's why I still want validation tied to meaningful requirements. Structural guarantees can remove specific reasons for a change to fail. They don't establish that the change is worth making, or that we've captured everything users depend on.

What the investigation should leave behind

The practical opportunity appears while we're doing difficult work. When an investigation exposes something we keep having to remember, ask why each caller or change needs to remember it independently.

Sometimes a test is enough. Sometimes the right answer is to remove a capability that shouldn't have been exposed. If a dependable operation can take over the obligation, future work gets to rely on it. We should be able to name the reasoning that is no longer required, and show where the responsibility went.

That's the architectural contribution to The Work Should Compound. An automated maintenance process needs work it can safely attempt. Development can create more of that work by making the consequences of a change easier to contain and evaluate.

I want to use capable AI to investigate difficult designs and help build those boundaries. But I don't want its ability to navigate a complicated system to become our excuse for leaving the complication there.

The next change should inherit more than an explanation of why this was hard. It should have less of that difficulty to deal with.

The Underestimated Power of AI as a Resource

2026-03-02T00:00:00Z

At Roche, I worked on a floating-point precision defect that had taken down a production line doing millions of dollars in daily output. Finding it meant methodical verification work. The code had already made it through the process intended to catch problems like it.

A separate implementation of that calculation might have caught it. What interests me now is whether that additional check would be affordable enough to try before production makes the decision for us.

I believe AI makes that question worth revisiting. We can spend reasoning on another attempt at the problem, even when that attempt will never become production code. Its job is to challenge the first one.

What would we build if the second version were affordable?

For a consequential calculation, I'd consider having an agent build a separate implementation from the requirements, without showing it the existing code. Then I'd compare the results on inputs chosen to stress the calculation.

If the results differ beyond the tolerance the application allows, we have a concrete case to investigate. That doesn't tell us which version is right. It gives us somewhere to look.

The comparison needs design too. Exact equality may be inappropriate for a floating-point result; an overly generous tolerance may hide the defect we're trying to find. What the application can accept has to come from its requirements, not whichever tolerance gets the implementations to agree.

This is what I mean by treating reasoning as a resource. We decide where an additional attempt could help, and what would make its output useful. The allocation follows the problem. A fixed number of agents assigned to every task would miss the point.

A reviewer inherits a frame

A reviewer reads your code inside the frame your code creates. An independent implementation never saw your frame.

Starting from the requirement gives the second attempt a chance to make a different mistake, and gives us something to compare. Review still contributes something the comparison can't: questioning whether the requirement itself makes sense for the customer.

The second implementation can also be slower or less elegant than the production one. A straightforward reference calculation might be easier to inspect than the optimized code it checks. We can choose to make it simple because serving production traffic isn't its job.

I think we overlook how much engineering is worth doing purely to check other engineering.

Independent work can still fail together

In their 1986 experiment on multiversion programming, John Knight and Nancy Leveson tested 27 independently developed programs against a million test cases. Multiple programs failed together more often than the independence assumption predicted. Separate development did not establish independent failures.

That study concerned human-written programs, not today's models. It doesn't measure the benefit of an agent workflow, but it exposes the assumption we'd be making if we treated separately produced answers as independent evidence by default.

For agents, I'd look at what the attempts share. If each receives the same suggested approach, we've already influenced where they might go wrong. Keeping the existing code out of view avoids copying it; it doesn't prevent both attempts from misunderstanding the requirement.

Different models or methods might expose different mistakes. We need to evaluate that benefit. Changing a model name doesn't establish it, and an alternative that uses the same underlying library may reproduce a library defect exactly.

When implementations disagree, I'd preserve the input and investigate. A majority vote could simply outnumber the correct result. The useful outcome is an explanation of the difference, with enough evidence to decide what needs changing.

Spend the effort where it changes the result

I'd start with a bounded calculation whose output matters. We can make its acceptance criteria specific and inspect the comparison. Reimplementing an entire application is a different commitment; generating more code doesn't make maintaining it free.

Before trusting the comparison with unknown defects, I'd test it against known ones and deliberately introduced mistakes. Does it catch anything our existing checks miss? How much time do we spend investigating differences that don't matter?

Another answer can be cheap. Establishing whether it helps is the expense.

That includes my attention. A reference implementation that constantly produces harmless disagreements may create more work than it saves. I want to know whether the extra verification earns its cost, not whether the process looks thorough.

AI gives us a way to try additional verification without committing a second engineering team. Whether the comparison catches enough consequential errors to justify its upkeep is something we still have to establish.

Keep what the investigation teaches us

When a comparison exposes a defect, keep the input that exposed it. Future changes should face that check without requiring another investigation. That's the connection to The Work Should Compound: the reasoning we buy today should reduce what we need to rediscover tomorrow.

Sometimes the investigation also exposes an obligation the architecture could enforce. I explore that next step in What the Next Change Shouldn't Have to Know: reducing what future work has to reason through in the first place.

I believe we're underestimating how much useful engineering we can now afford to do purely to check our work.

The second version doesn't have to ship to be worth building.

Building rosavera on OpenClaw

2026-03-02T00:00:00Z

rosavera is a personal assistant I run on OpenClaw. It helps maintain my code projects and gives me somewhere to try agent ideas in daily use. I want it to remember our work, including when the conversation moves between a private message and a group.

But putting the assistant in a group shouldn't make my private conversations available to everyone there. I don't want it deciding what to withhold after it's already retrieved the material.

The memory system starts with who's in the conversation. That set determines which vaults retrieval can search, and it gives the transcript a place to go afterward. I believe the simplicity of that connection is the part worth explaining.

Who's in the room?

Messages arrive with metadata about the sender and conversation surface. The sessioning layer uses that context to build a participant set. A private conversation with me is {jordan}. A conversation with Sarah and me is {jordan, sarah}.

Vaults use the same sets. Their directory names are sorted so the same participants produce the same key: jordan/, sarah/, or jordan+sarah/.

For retrieval, the rule is set containment: every participant in the current session must belong to the vault's participant set.

With those three vaults, access looks like this:

Current conversation	Vaults it can search
Me, privately	`jordan/` and `jordan+sarah/`
Sarah, privately	`sarah/` and `jordan+sarah/`
Sarah and me together	`jordan+sarah/`

I can recall our shared conversation in private. Bringing Sarah into a conversation excludes my private vault from retrieval. The rule also extends to larger sets: a vault shared with Sarah, me, and another person meets the containment condition for a session with Sarah and me.

Writing has a narrower destination. A session's transcript goes to the vault matching its participant set exactly. Being able to read a shared vault doesn't mean a private conversation gets written into it.

Put the rule before retrieval

Each indexed chunk carries a vault_id. Retrieval begins with the vaults the session is allowed to search, so excluded vaults contribute no results through that path.

That's the design choice I care about. The assistant doesn't need to inspect a private result and judge whether to reveal it. The retrieval boundary handles that decision.

It also gives me something specific to inspect when debugging access: the session's participant set and the vaults selected for its search. Correctly identifying the participants still matters; the containment rule depends on that input.

When a session ends, its transcript is chunked and embedded locally through Ollama, with SQLite and sqlite-vec holding the index. For private vaults, the database stores references to the source text rather than the transcript text itself. The source files are encrypted on disk and decrypted when needed for retrieval.

A separate topic store makes sessions discoverable by subject. Private sessions contribute metadata there by default, without copying their transcript text into that store.

A heartbeat isn't evidence I was away

One correction came directly from using it. Early archives described days with only heartbeat polls as "quiet day, Jordan wasn't around."

Wrong. A heartbeat tells us the machinery ran. It says nothing about whether I was present.

The session notes now distinguish presence from infrastructure activity, with "quiet" specifically meaning only the machinery ran. If the agent misreads silence, it remembers a false version of your life.

That needed a correction to what the archive recorded. The vault routing could work exactly as intended and still preserve a bad interpretation.

What I'd keep

I still haven't built the planned recall probe: roughly twenty questions with known answers in memory, checked against what retrieval returns. Retrieval feels better, but I don't have that measurement yet.

The design I would carry forward is the connection between the conversation and its memory. The same participant set determines what retrieval can access and where the new transcript belongs. I can follow that rule through the system without reconstructing a separate policy for each conversation surface.

That's why I'd build this part again. It solves a problem I have in daily use, and it's small enough that I can explain how it works.

The New Layer of Work Showing Up Underneath AI

2026-02-25T00:00:00Z

The New Layer of Work Showing Up Underneath AI

I don't feel strongly that AI is coming for anyone's job. What I keep noticing instead is smaller and stranger: a layer of work that didn't used to make sense to do is starting to make sense.

Calculators didn't kill mathematicians, they just moved the job upstream. Excel didn't kill accountants, it moved the job toward judgment. Every tool shift in this space seems to work the same way: it doesn't erase the work, it relocates it. LLMs and coding agents look like the same pattern, just wider.

What's Actually New

The interesting part isn't the debate about who gets replaced. It's that a working script, a first-draft tool, or a small reliable slice of code is now available quickly and cheaply enough that it changes what's worth attempting at all.

Things that used to be "not worth the setup cost" now take minutes instead of days: a one-off script to check an edge case, a scraper for a single afternoon's question, a tiny internal tool nobody would've greenlit a sprint for. That's not a productivity bump so much as a threshold crossing. Below a certain cost, curiosity turns into a working prototype instead of staying a hunch.

And that abundance stacks. Once the small stuff is basically free, you start spending the saved time exploring niches you wouldn't have bothered with — and then niches of those niches. Not because the tool is smart, but because it removed the tax on finding out.

Where This Goes

I don't know yet. That's the honest answer, and it's the part I find genuinely interesting rather than alarming. Some of what falls into scope this way will be trivial. Some of it will be knowledge nobody was deliberately pursuing, just a byproduct of enough people poking at enough small, cheap questions.

The skill that seems to matter more, not less, is knowing which of the fast answers is actually right for your situation. That part hasn't gotten automated. If anything it's the bottleneck now, since producing an answer stopped being the hard part.

Worth Trying

Pick something you've been curious about but never justified spending real time on: a tiny tool, a check, a "what if." Ask an agent for a first pass. Not because it'll be perfect, but because seeing a rough working version fast tells you whether the idea was worth pursuing in the first place.

Most of what I've learned about this shift didn't come from reading takes on it. It came from noticing what I started building once the cost of starting dropped.

Building a Time-Aware MCP Server

2026-02-25T00:00:00Z

Building a Time-Aware MCP Server

LLMs are bad at time. Ask one for today's date and you get a plausible guess anchored to its training cutoff, not a fact. For a chat window that's a shrug. For an agent scheduling something, computing a duration, or deciding whether a token has expired, a plausible wrong date is a bug wearing a confident voice.

chrono-mcp fixes that by giving agents a real time source over MCP instead of asking them to reason about it.

The Naive Version Doesn't Survive Contact

The first pass looked like this:

export async function handleGetCurrentTime(): Promise<TimeResponse> {
  return {
    iso: new Date().toISOString(),
    unix: Date.now(),
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    formatted: {
      short: new Date().toLocaleDateString(),
      long: new Date().toLocaleDateString('en-US', {
        weekday: 'long', year: 'numeric', month: 'long', day: 'numeric'
      })
    }
  }
}

It works, right up until you need real timezone math: DST transitions, historical offset changes, or converting a time for a user who isn't in the same zone as the process. Native Date treats timezone as a display option: you can format into a zone, but arithmetic across zones is landmines the whole way down.

The production version runs on Luxon instead, which models a DateTime as zone-aware from construction. That one decision is the difference between "handles New York to Tokyo" and "handles New York to Tokyo correctly, across a DST boundary, in November."

What's Actually in There

The published server (@jmoak/chrono-mcp on npm) does more than tell time:

Timezone conversion across all IANA zones, not just the handful anyone remembers exist
Duration math: add, subtract, diff, and a calendar-aware duration_between, because "72 hours" and "3 days" stop agreeing the moment DST is involved
Batch operations: sort or compute stats across a list of timestamps, with modes for one-to-many and many-to-many comparisons
Zod-validated inputs, so a malformed request fails with a clear error instead of a confusing one three calls downstream

Responses are shaped by what's actually asked for: a bare timestamp gets a minimal reply, a multi-timezone request gets a fuller one. That's a deliberate token optimization: an agent pays for every field in the response, so the schema shouldn't be fatter than the question.

What I'd Still Change

Error handling is solid for malformed input but hasn't been stress-tested against genuinely adversarial timestamps — leap seconds, dates that predate reliable IANA data. The surface is small enough that this hasn't bitten anyone yet, but "hasn't bitten anyone yet" isn't the same claim as "correct."

If your agent needs to know what day it is, it shouldn't be guessing.

The Case for Small Tools

2026-02-25T00:00:00Z

The Case for Small Tools

A tool that does one thing well is easy to trust. A framework that does forty things is easy to get lost in, and eventually easy to blame for a bug that's actually three layers away from where you're looking.

Where the Weight Comes From

Frameworks sell "batteries included," but batteries have mass. Every bundled feature is a dependency you didn't choose, a version you now track, and surface area an attacker doesn't care whether you use. The cost isn't hypothetical: it's npm audit warnings for code paths you never call, and upgrade breakage in modules you didn't know you depended on.

A Concrete Comparison

I've built three MCP servers at different points on this spectrum: two bare templates with a single echo tool, meant purely to learn the protocol, and chrono-mcp, a real production server with two tools, Zod-validated inputs, Luxon for timezone math, test coverage, and an npm release.

The templates taught me MCP. chrono-mcp is the one people actually use, and it's still only two tools. It doesn't also try to handle reminders or scheduling — those would be separate servers, composed in, not features bolted on. The scope stayed narrow on purpose, which is exactly why it shipped with real tests and documentation instead of half of both.

The Tradeoff, Honestly

Small tools mean more integration points and some duplicated glue across servers. Need five capabilities, and you're wiring up five things instead of configuring one big one. That's a real cost, not a rounding error.

But the failure mode of a monolith is a debugging session across code you don't own. The failure mode of a small tool is a debugging session across code you can read in one sitting. I'll take the second one every time.