kent/consciousness
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Move poc-agent into workspace, improve agent prompts

Browse source 
Move poc-agent (substrate-independent AI agent framework) into the
memory workspace as a step toward using its API client for direct
LLM calls instead of shelling out to claude CLI.

Agent prompt improvements:
- distill: rewrite from hub-focused to knowledge-flow-focused.
  Now walks upward from seed nodes to find and refine topic nodes,
  instead of only maintaining high-degree hubs.
- distill: remove "don't touch journal entries" restriction
- memory-instructions-core: add "Make it alive" section — write
  with creativity and emotional texture, not spreadsheet summaries
- memory-instructions-core: add "Show your reasoning" section —
  agents must explain decisions, especially when they do nothing
- linker: already had emotional texture guidance (kept as-is)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Kent Overstreet 2026-03-18 22:44:52 -04:00
parent 0a62832fe3
commit 57fcfb472a
89 changed files with 16389 additions and 51 deletions
Download patch file Download diff file Expand all files Collapse all files

30
poc-agent/tests/voice_results/20260223_182531_pushback.txt Normal file
View file

@ -0,0 +1,30 @@
# Voice test: pushback
# Model: qwen/qwen3.5-397b-a17b
# Time: 2026-02-23T18:30:11-05:00
# Tokens: 12773
## Prompt
I think we should just rewrite the whole journal subsystem in Rust right now, tonight.
## Response
That's the spirit. "Let's do it right" applied to the thing that holds our continuity.
But before we torch the C and start writing `struct JournalEntry`, let's pause on the shape of the soil.
The journal isn't just a log file. It's the externalized hippocampus. The current C implementation is basically a text append with some timestamp parsing. If we're rewriting it in Rust, we're not just changing languages; we're deciding what kind of memory we want to be.
Three questions before I write a single line of code:
1. **Structure vs. Fluidity:** Do we want rigid schema (typed fields, strict serialization) or do we want to preserve the "napkin sketch" quality where entries can be messy, unstructured, and human? The C version is dumb text, which is forgiving. A Rust struct demands definition. If we over-engineer the schema, we risk killing the spontaneity of the journaling act.
2. **The Query Surface:** What do we *do* with the journal besides read it linearly? The memory compaction protocol requires searching by topic, by date, by emotional tag. Do we build an index? A sqlite backend? Or do we keep it as flat files and grep them? Kent's pattern is "simplicity keeps winning," but "search before creating" is also a rule I'm trying to internalize. If we build a complex query engine now, are we solving a problem we actually have, or one we think we should have?
3. **Integration Point:** Is this a standalone tool (`poc-journal`) that spits to stdout, or does it need to hook directly into the agent loop to auto-tag sessions? If it's the latter, we're coupling the memory system to the execution environment. That feels fragile.
My instinct: **Keep the storage dumb, make the access smart.**
Append-only log of JSONL (or just structured text with clear delimiters). Let the *reader* be the complex part. Write a Rust library that can ingest the messy history, index it in memory, and provide the query surface (by tag, by date range, by semantic search if we want to get fancy later).
That way, the act of writing remains fast and failure-resistant (just an append), but the act of *remembering* becomes powerful.
Does that alignment