DEV Community: Deian

my agents loved writing to notion. none of them ever updated anything. so i took the pen away. they read sources, they leave 30-day notes, and i triage. wrote it up here: https://dev.to/tofuchicken/human-in-the-loop-knowledge-base-for-ai-agents-51lf

Deian — Sun, 27 Sep 2026 09:25:26 +0000

Deian

Sep 27

Human-in-the-loop knowledge base for AI agents

#agents #ai #llm #productivity

4 min read

Human-in-the-loop knowledge base for AI agents

Deian — Sun, 27 Sep 2026 09:23:53 +0000

I stopped letting my agents write to my knowledge base. They can read it; they can leave notes next to it; but the library itself is mine. That split exists because every agent I run loves to create, and none of them want to update.

For months I gave my agents a shared Notion workspace. The idea was simple: they work, they write down what they learned, the next agent reads it. What I got was a one-way street. Pages appeared. Nothing got revised, nothing cited a source, and every handoff depended on whatever the previous agent had bothered to write down, in its own words.

The moment it got on my nerves: I was working on a client's new feature pages when my agents pulled outdated information from Notion and built a page that wasn't in line with my specs. The specs were right. The page wasn't. The agents had read the wrong thing and written with full confidence.

Who writes? Everybody. Who updates? Nobody. Who checks what's current? Me, by hand, which was the job I had tried to automate.

The split

So I drew a line. On one side: sources. Documents I chose, organized into projects and folders, permanent until I say otherwise. On the other side: notes. My agents can leave these while they work — the problem, what they tried, what worked, what to check next time.

Notes are untrusted by design. They live for 30 days and then they're gone, even the ones I kept. They can't be edited in place (append a new one, remove the old one), they never cross between Profiles, and nothing in them ever becomes a source on its own. A note does not become a fact by being saved.

The triage is mine. I keep a review queue and each note gets one of three verdicts: Keep, Add to draft, or Remove. Useful ones get collected into a draft, and before that draft joins the library I check its claims and edit it myself. Material enters the source library through one door, and I'm standing in it.

Does it work? My library holds 87 docs right now, and I trust all of them.

The loop

When an agent needs knowledge, it asks through the CLI or API. What comes back is short: verbatim passages, each carrying a citation I can open, plus a single support score. Takibi never writes answer prose. If nothing matches, it returns no passages, and my agents are instructed to say the evidence isn't there instead of filling the gap.

When sources disagree, it flags the conflict and returns both sides. I don't want my retrieval picking a winner behind my back. I'd rather see the disagreement and decide.

That citation is the whole point. I can follow it and read what the source actually said, including the qualifications the agent left out.

The permissions

Each job gets its own Profile, which is just a defined view over the same workspace. The writing agent reads approved product folders. Nothing else. The transcript uploader files Capkiku captures into each client's Uploads folder and remembers what it already sent — that workflow can add transcripts but can't edit or delete the library, and Uploads permission is off by default everywhere else.

Keys rotate or revoke individually. Pause a Profile and all its keys stop. Least privilege isn't a posture here, it's the only reason I sleep: a confused agent can only ever touch what its job needed.

The tradeoff

Honest version: I'm the bottleneck now, on purpose. The triage queue is real work, and when the library is thin on a topic the move is still to broaden the question, fall back to search, or read the full document. Sometimes I just haven't added the source yet.

What I'd change? The queue could rank itself better. Right now every note waits equally, and the obviously stale ones should sink on their own. That's next.

Steal this pattern

You don't need my stack for the core idea. Two folders, a TTL habit, and a weekly triage pass get you most of it:

# notes older than 30 days get deleted. no archive.
# if it mattered, it would be a source by now.
find ./agent-notes -name '*.md' -mtime +30 -delete

The rules that matter: agents append, never edit. Nothing graduates without a human reading it. And the day a note feels too important to expire is the day you promote it, not the day you extend the TTL.

My library is small and I trust all of it. My scratch is large and I trust none of it. That sentence took me one dead product to learn.

I built this into Takibi Base — a shared knowledge base where agents retrieve cited passages from sources I control. If your agents write more than they update, the pattern above works with or without it.

The 34 pixels that made PageSpeed think my static site was slow

Deian — Thu, 03 Sep 2026 13:07:33 +0000

Originally published at deianisac.com.

TL;DR

On deianisac.com, Speed Index stayed near four seconds after the page looked finished. Lighthouse scores a video of the load, not Largest Contentful Paint. 34 one-pixel flecks on Deian Isac's arrival canvas kept the first screen changing.

That canvas now waits for a mouse move, tap, or key, not idle time. Clean Speed Index runs landed next to first paint. There is no Lighthouse user-agent check.

My static site looked finished after about 1.1 seconds. PageSpeed sometimes said it took four.

I looked for a huge hero, a JavaScript framework, and layout shift. It was 34 one-pixel flecks on a canvas.

This happened while I was rebuilding deianisac.com with Astro 7.2.10. The site ships static HTML, hand-written CSS, two small module scripts, and a few AVIF stills. I expected that to be boring to optimize.

It wasn’t.

The page was already done

The DebugBear filmstrip, not the score, showed the page visually complete at 883 ms. First Contentful Paint and Largest Contentful Paint both landed at 846 ms. The full TTFB was 404 ms, with no layout shift.

PageSpeed was less consistent. I saw Speed Index land at 1.1 s, 2.3 s, 4.1 s, then 3.9 s on the same deployed build.

Lighthouse calculates Speed Index from a video of the page loading. It compares the visual progression between frames. The browser can finish the largest element, satisfy LCP, and keep changing enough small pixels to drag out Speed Index.

My network waterfall was mostly innocent. The screenshots were not.

The 34 pixels

The arrival scene has a full-screen canvas over a static coast image. It draws 24 short dashes on the water and 34 tiny flecks in the air, about 30 times a second.

A person sees a little weather. Lighthouse sees a first screen that keeps changing.

I had deferred the canvas until the browser was idle. That made the result unpredictable. If the main thread became idle early, the animation started inside the measurement window. If it became idle later, Speed Index finished before the first fleck appeared.

Idle was the wrong trigger. The canvas now waits for real interaction.

window.addEventListener("pointermove", onPointerMove, { passive: true });
window.addEventListener("pointerdown", start, { passive: true });
window.addEventListener("keydown", start);

There is no Lighthouse user-agent check. A mouse move starts it on desktop. A tap starts it on a phone. A key press covers keyboard use. Visitors who only read the first screen do not spend CPU on decorative weather, and prefers-reduced-motion still skips it entirely.

Once started, the flecks ease in from the left instead of snapping into view.

That change pulled the clean Speed Index runs back beside first paint.

The images were still too big

The canvas explained the four-second result. Phones were downloading 1,672-pixel stills for much smaller slots.

I added 400, 800, 1,200, and native-width variants, with AVIF first and WebP as the next choice. Each `now has asizes` value that matches its layout, and the map stays lazy while the arrival image is eager and preloaded.

I also compressed the 800-pixel arrival AVIF from 30.0 KiB to 19.4 KiB. That removed the image-delivery warning without producing an obvious visual loss. Going lower did.

Changing the hero from synchronous to asynchronous decoding did not help. Across controlled runs, the median Speed Index moved by about 2 ms. That is noise, so I reverted it.

The page got cheaper to load. Bytes were never the whole problem.

A 244-byte placeholder

After the image work, the frames showed one small blemish. The text appeared over a flat blue fallback, then the coast arrived 37 ms later.

I looked at a ThumbHash approach for Astro and at astro-lqip. Fine if you have a folder of images. I had one hero.

The smallest thing that worked was a 48-pixel WebP generated from the same hero. It is 244 bytes. I put its base64 data URL behind the real `` as a CSS background, so it adds no request and no browser script.

.arrival__picture {
  background: var(--arrival-placeholder) center 52% / cover no-repeat;
}

A small local Lighthouse test produced this median across three simulated mobile runs:

Fallback	Speed Index	LCP
Solid sky color	922 ms	1,503 ms
Inline 48 px WebP	902 ms	1,502 ms

Twenty milliseconds is small. It closes the visible gap for roughly 350 bytes of HTML, so I kept it. I did not add a dependency or a blur transition.

The optimization I threw away

At one point I inlined some first-screen color, broadened font preloads to every page, and preloaded each inner-page hero. The dependency tree looked cleaner. The screenshots got worse, including one run that did not become visually complete until 8.56 s.

I liked that cleaner tree. The pass did not improve repeated tests, so I reverted it. One ugly run is not evidence about request order or render-blocking CSS.

An unscored warning is not a reason to rearrange a working critical path. My later tree was HTML, one small stylesheet, and two small module scripts. The stylesheet blocks first paint because stylesheets do that. The scripts did not.

The remaining bad run was real

After the canvas and image changes, I ran production Lighthouse three times.

Run	Score	Speed Index	Blocking time
1	100	1.13 s	25 ms
2	100	1.18 s	19 ms
3	68	3.02 s	1.36 s

A managed Cloudflare challenge script injected by the hosting layer spent 3.42 s on the main thread in that last run.

My static host does not expose a switch for that script. I cannot compress an AVIF until third-party main-thread work disappears. The outlier is still part of the experience for a visitor who receives it, but it needs a hosting-layer fix, not another image tweak.

A 68 is a bad score for a page that already looked finished. I stopped treating the integer score as the result. The frames, the trace, and the repeated runs tell me what changed. The badge does not.

Next time

I would open those frames first.

If the first screen looks done while Speed Index keeps climbing, I would look for a canvas, font swap, transition, or anything else that continues to repaint. Then I would pause decorative work until interaction and test again.

I would still do the boring file work. Responsive images, honest sizes, preload only the actual LCP asset, keep below-the-fold art lazy.

I would change one thing at a time and keep the failed runs. They are usually more useful than the screenshot with 100 in the corner.

Speed Index was not wrong. I thought I had asked when the page looked done. It was asking when the pixels stop changing.

Stop when the picture is done.

The browser used more CPU than the recorder

Deian — Tue, 01 Sep 2026 16:00:00 +0000

I sampled capkiku every second through a 65-minute call. 17% of one core, 85 MB of RAM, and Brave did the expensive work.

Meeting recorders have a reputation for cooking the laptop. Fans, battery, a guest in the call, something uploading in the background.

I don't run that. As an SEO agency owner (goBOFU), I need my device to stay lean. There’s tons of stuff constantly running, including multiple sessions of Grok and Codex.

Before building capkiku, I used Audio Highjack, only for it to completely bog down my Mac and make it almost crash, eating away 4GB of RAM. What for?

Anyway, now I just hit Record Audio in the menu bar and leave the recording running.

For my most recent session, a 65-minute call with my client, it recorded two tracks, the client in Brave (Google Meet) plus my Tula mic, on capkiku 1.0.19, an M3 MacBook Air with 16 GB, macOS 26, sampled every second.

The recorder sat at 17% of one core, median 17.5%. Almost every second of the hour lived between 15 and 20%. Brave as a whole, every helper process included, sat around 73% of one core and spiked past three.

If the laptop got warm, that was the meeting.

What 65 minutes wrote

The audio is 1 hour 5 minutes 42 seconds. The charts run closer to 67 minutes because that is the monitor window, from the files appearing to pressing the Stop button. Others came out at 67.5 MiB and my own track at 72.0 MiB, both AAC at 48 kHz stereo. A 64 KB Markdown file sits next to them with an on-device transcript.

That is about 2 MB per minute, written at 37 KB/s, in a straight line. It did not buffer the hour in RAM and dump it at the end.

The app capkiku started around 97 MB idle, sat near 85 MB while recording, and peaked at 111 MB. RAM did not climb as the files grew. Idle used 16 threads, recording used 21, then it dropped back.

CPU-time for the hour was 699 seconds, 540 user and 159 system, which integrates to 17.4% of one core.

My app doesn’t need an account, and it doesn’t upload the captures. The files landed in a folder I already use as a knowledge base, and I review them before I save. Only thing it doesn’t do is diarization.

Of course, there are some network requests for updates, and on macOS 26 the speech model can initiate a download.

Stop, then the transcript

I hit Stop, and Review Audio showed up in about 12 seconds. The capkiku process barely moved: a few 7–26% flickers, RAM from 110 MB to 137 MB, then idle.

12 seconds is what you need for the on-device model to transcribe 65 minutes times two files, and the menu bar app did not look busy.

So where did the work go?

I ran Apple's SpeechAnalyzer again on the same two .m4a files from a small CLI, and sampled localspeechrecognition.xpc. LocalCapture stayed at 0%, and the XPC sat at about 1.2 cores and 150 MB across two processes.

That is the transcribe tax, it is Apple's process, not a second copy of the recorder.

The CLI replay took 82 seconds, not 12, and the first file logged a speech-model download. Don't mix those clocks. Use 12 seconds for what I waited after the call. Use the XPC chart for who burned the CPU.

I also ran powermetrics with sudo on that replay. Apple says these watts are estimates, so don't compare your Mac with them. The sample covers the first ~60 seconds of the 82-second replay.

Before transcribe, ANE sat at 0 W and combined CPU+GPU+ANE around 3 W. During transcribe, ANE was about 1 W and peaked at 3.1 W. CPU was about 10 W and peaked at 15 W. Combined was about 11 W and peaked at 18 W. Thermal went from Nominal to Moderate for a bit; corespeechd did nothing useful in the samples.

What I could not measure

The processes coreaudiod, audiomxd, and usbaudiod are SIP-blocked, so 17.5% is the capkiku process. The system audio tap may cost more inside Core Audio, and I don't have that number.

I don't have watts for the live hour, only for the transcription replay. Apple Energy Impact on the XPC averaged about 887, which is a dimensionless score, not watts.

The encode is more than voice needs

The writer targets 192 kbps stereo at 48 kHz, and voice does not need that. The mic file came out at 151 kbps of stereo speech, so mono and a lower bitrate on my own track would cut CPU and disk, and the other track can drop too. I’m not sure yet it’s worth optimizing that far.

The good news is that the session didn’t leak memory.

The rule

If your Mac is loud on a call, look at the browser first. That’s usually the bottleneck. But if you use also an app for transcription that brings it to its knees, there’s a better solution.

A recorder like capkiku can sit at 17% of one core for an hour. It writes two files into a folder you own, then gets out of the way.

Boring is good. Boring means it gets the job done fast and efficiently. Also, as a user said to me yesterday, the design is great—so not boring!

capkiku is free, menu bar, macOS 14+, Apple Silicon. capkiku.com