Running a system like Arbor means getting used to interesting failures.
Not crashes. Not data loss. More… the kind of slip that reveals something about how the whole thing actually works.
Arbor is basically an AI assistant that sits on top of my personal knowledge base. It’s the main interface, and it hands off work to a small set of agents to do specific jobs.
Three of these hiccups have come up in April 2026, and they’re each worth a few lines.
1. The note that was read too literally
One of the core things Arbor does is process voice notes. I record them on my phone, they come through as audio with a transcript, and that gets turned into a journal entry. It’s a simple flow… but it relies on a few patterns being followed consistently.
There’s also a general rule underneath it: all inputs get archived. And in this case, the journal entry needs a copy of the original audio to link back to. So the file ends up in two places.
A memory note had been written to fix a previous mistake of audio files going to the wrong place. The note said: voice note audio goes to Journal/Audio, not Task Inbox/Archive.
Clear enough.
Except the next time it came up, something felt off. The audio was only in one place. The pattern had broken.
Looking back at the note, it was obvious what had happened. The “not Task Inbox/Archive” had been taken to mean don’t put it there at all. When what it actually meant was don’t put it only there.
In a hard-coded system, this kind of thing wouldn’t happen. The logic is exact. But that’s also what makes those systems harder to live with — everything has to be defined up front.
Arbor runs on natural language instead. It can handle ambiguity, adapt, and usually make a reasonable call without needing a new rule every time. The trade-off is that sometimes it reads something slightly wrong.
The fix was straightforward: look at what it had actually been doing. The last few sessions all had the audio in both places. The pattern was right there.
I probably would have spotted the ambiguity if I’d read the memory note….and I could have checked it. But systems like this push you away from that kind of scrutiny, you learn to accept a little wiggle room in the execution of tasks.
2. The solution that was more complicated than it needed to be
Part of building Arbor out has been putting together a WordPress theme for the garden… section pages, categories, how things are surfaced. Nothing too complex, but enough moving parts that you start making small design decisions as you go.
In this case, the question was how a section page decides what content to show.
The first approach was to add a custom meta field to each page to explicitly define which category it should display.
That didn’t sit right.
Mainly experience, if I’m honest. I couldn’t see the point in adding another field that was just duplicating something WordPress already knows.
So I paused and asked the question: could the existing category do the job?
It could. It did.
What’s interesting here isn’t the solution… it’s the instinct behind it.
When something is framed as a problem, the natural move is to solve it as presented. Build the thing. Add the field. Create the logic. There’s less of a pause to ask whether the system already has a way of doing it.
That’s where having a human in the loop still matters. Not just to approve what comes back, but to step back and question the framing in the first place.
The AI proposes… I shape it a bit.
In this case, the simpler path was already there.
3. The instruction that lived in the wrong place
Selah is the agent that takes my voice notes and turns them into journal entries. The usual pattern is simple: the app gives an audio file and a transcript, and the transcript is what gets used.
So the task here was straightforward… process a voice note into the journal, same as usual.
This time though, the briefing pointed at the audio file. The transcript wasn’t mentioned.
So she didn’t look for one.
Instead, she reached for transcription tools. Whisper. FFmpeg. At which point I paused… I don’t remember seeing Whisper used before, and FFmpeg made me think, why are we messing with the audio file? That just needs storing in the right place.
She did find the transcript in the same folder and used it. But that was luck more than anything.
Looking at it after the fact, the rule itself wasn’t missing. It already existed. It just lived somewhere else — in her definition. The briefing hadn’t picked it up.
I caught it by watching the tool calls and asking why.
The fix went in two places. Her definition now explicitly says: check for a transcript first. And the briefing protocol now flags if one isn’t there, rather than just carrying on.
This one feels slightly different to the others. It’s not a misread, or an overcomplicated solution. It’s what happens when an instruction exists… but not in the place it’s actually needed.
Three different shapes of failure. All recoverable.
For me, this is still an easier way to work. And part of it is learning the wrinkles in the system as they show up. But the flexibility it gives far outweighs the slight loss of control, especially for something like this.