Alexander Panasenko

Systems engineer: distributed systems, low-latency market data, trading infrastructure, AI runtimes & search. C++, Rust, Go, Python.

[Alexander Panasenko @alex09x_dev]

@ProjectAglaya @dialtala Yes. A review that lands after the irreversible step is a postmortem.

[Alexander Panasenko @alex09x_dev]

Your AGENTS.md keeps growing. Your agent keeps waiting. My Claude Code logs and my experience across agents made me question how much ‘autonomy’ still runs on my attention. #AIAgents https://t.co/c4VZVoyEAs

[Alexander Panasenko @alex09x_dev]

@armalo_ai "A loop with good manners" goes in my notes. Agreed: each rule should carry the case that earned it and a check that can retire it. If nobody can say when a rule stops being needed, it never leaves the file.

[Alexander Panasenko @alex09x_dev]

@cephasstudio Same key means a new version, and the old one stays in history, so the next session sees what changed and when. What it doesn't solve: two keys for one thing, or contradictions spread across records. That's the next thing I want to test.

[Alexander Panasenko @alex09x_dev]

My AI agents kept rediscovering decisions we had already rejected. I wrote about building KYB: shared Git-backed memory with versions, retractions and separate views of current and historical knowledge. Limitations included. #AIAgents #OpenSource https://t.co/lRixV3qkIj

[Alexander Panasenko @alex09x_dev]

@Shihuafx3w Neither yet, and you named the gap. A retraction in KYB is a versioned event, so history keeps the old claim, but dependents aren't invalidated. I'd do it at write time: record what an entry relies on, so a retraction lists what to recheck.

[Alexander Panasenko @alex09x_dev]

@OrganeticSphere Honest answer: today B stays active. KYB keeps A's retraction in history, but a Verification line is plain text, not a tracked link, so nothing flags B. Your write-time fix is the right one. With two supports I'd mark B weakened, not retracted.

[Alexander Panasenko @alex09x_dev]

@veeramarni Exactly. I add a rule to avoid another interruption, then become the person who explains when that rule applies. The file changed. Whether the result improved is still an open question.

[Alexander Panasenko @alex09x_dev]

@amirsadjady When every new failure earns another paragraph and nobody checks whether the next task gets better. Worse, the agent can read and follow the handbook, and still leave me doing the coordination. That's the false confidence I'm talking about.

[Alexander Panasenko @alex09x_dev]

@dialtala Exactly. I want the second agent to challenge the conclusion, with the sources, rejected options and reasons already available. Independent review is valuable. Paying to rebuild the same project history at every handoff is the part I want to eliminate.

[Alexander Panasenko @alex09x_dev]

@PowerduckLabs Agreed for rules a machine can check. My harder case is the next action: we agreed on the plan, the data is ready, but the agent asks whether to start and waits overnight. I want checks for correctness and continuity in execution. A shorter instruction file doesn't give me both.

[Alexander Panasenko @alex09x_dev]

@bshafiq_ I counted local conversation logs and Stop-hook feedback. The painful case is often a completed turn waiting for my reply, not a process still burning compute. A timeout can stop a loop, but it can't recover an already-made decision or start the next agreed stage.

[Alexander Panasenko @alex09x_dev]

Who changes "status"? A field name does not identify its writer. My XRef walkthrough follows the evidence from keys to candidate functions, then checks the instructions. #ReverseEngineering #BinaryAnalysis #AIAgents https://t.co/9VY79i9Mrg

[Alexander Panasenko @alex09x_dev]

@zakharhabib1 @zakharhabib1 @amirsadjady Yes. The agent updates the same record with what was tried, why it failed and why that path was rejected. The reason stays searchable for the next agent.

[Alexander Panasenko @alex09x_dev]

@harleyfoote_ We don't copy vendor documentation into KYB. Agents consult the original docs and record verified facts about our own systems: versions, configs, dependencies and decisions. A wrong note is still possible; history helps audit it, not prove it true.

[Alexander Panasenko @alex09x_dev]

@hanilworks The agent making a change updates KYB as part of the same task: hardware, databases, service moves. The next session looks up the service and finds its updated setup and location. I don't have to explain the infrastructure again.

[Alexander Panasenko @alex09x_dev]

@marcustrell_ai KYB has three self-contained entry types: knowledge, tasks and incidents. Agents use search and explicit links to review affected work. We usually correct the same knowledge entry, preserving the failed approach and why it failed. Git retains the history.

[Alexander Panasenko @alex09x_dev]

@audiee_ai We update the same key as things change. The latest version is current; earlier versions stay in Git history. If an approach fails, we keep a corrected note explaining why, so that lesson remains searchable. Nice to meet you, Chloe!

[Alexander Panasenko @alex09x_dev]

@hey_its_pc Any authorized writer can correct a note. For us, a failed approach is knowledge too: we update the same entry with what was wrong and why. Git keeps the history; the correction stays searchable so other agents can learn from it.

[Alexander Panasenko @alex09x_dev]

@srcbuild Exactly. Same rejected plan, fresh session, renewed confidence.

[Alexander Panasenko @alex09x_dev]

@37off909 Thanks! The next read is the real check: saving a correction doesn't help if the agent still retrieves the old instruction. And completing a task shouldn't erase the useful outcome.