There's a thread on V2EX where a developer posted the "user profile" their agent harness had written about them. Not settings they typed in. A multi-paragraph summary the system had inferred from watching them work: how they break tasks apart, how they review code, where they draw the line on what the agent is allowed to touch. The developer read it, found it surprisingly accurate, and asked others to share theirs.
I read that and my first reaction wasn't "neat." It was "who owns that text, and when does it change?"
The quiet-inference problem
The profile in that thread was genuinely good. Paraphrasing the parts that stuck with me: this person slices work into discrete, well-scoped packages and kicks off each with a short instruction. On anything uncertain, they make the agent restate the plan and confirm before touching code. They drive development through verifiable intermediate results, approving the minimum necessary change first and deferring optimization until they explicitly ask. They keep hard control over irreversible or production-facing actions: restarts, port management, database DDL, git commits. The agent gets read-only checks, code edits, and verification of real results.
That's a sharp, useful description of a working relationship. The trouble is the medium. If the harness inferred it, the harness can silently revise it. One noisy week where you were rushing and cutting corners, and the model quietly updates "insists on precise verification" into something softer. You'd never see the diff. You'd just notice, weeks later, that the agent stopped double-checking things and you can't point to when that started.
A profile that shapes every task the agent runs should not be a thing that drifts behind your back. So the reframe I wanted to try: treat it as a small, human-owned artifact. Curated working-habit records that you maintain, that the agent reads before it starts, and that it never rewrites on its own.
What I rebuilt on VicroCode
The shape here is small on purpose. Three pieces.
First, the profile lives as structured records in a SQLite database rather than a blob of prose the model regenerates. One row per habit or boundary. I gave each record a category (workflow, review standards, collaboration boundaries, verification), the habit text itself, a priority, and an active flag so I can retire a rule without deleting its history. Modeling it this way means the agent can pull just the boundary rules before a risky task, or just the review standards during a code review, instead of swallowing the whole essay every time. When I want to tune a rule, I open the built-in SQLite editor and change the row directly. The edit is mine, it's visible, and it's the source of truth.
Second, a hosted HTML page to actually look at and tweak the thing. Reading raw table rows gets old fast, so I put a plain review page in front of it: records grouped by category, a toggle to activate or retire each one, an inline edit box. Nothing fancy. Being able to run HTML online without standing up a server meant the review surface existed the same afternoon I sketched it. The page reads and writes through a small backend endpoint rather than talking to the database from the browser, which keeps the data path in one place.
Third, the injection point. This is the part that makes it a working-habit contract instead of a document nobody opens. I exposed an in-platform tool call the agent hits at the start of a task: it queries the active profile records, orders them by priority, and returns them as context the agent must read before doing anything. The AI agent development side of the build is mostly this glue, deciding what the tool returns and when the agent is expected to call it. The agent consumes the profile. It does not write to it. That direction is the whole point.
Friction worth naming
A couple of things I'd flag before you copy this.
The read-only rule is a convention, not a lock. In this build the agent simply has no write path to the profile table, so it can't edit it. But "the agent must call the tool before starting" is an instruction, and instructions get skipped. If you care about enforcement, you want the tool call wired into the task's opening step rather than left as a polite request. I did the wiring; I'm not going to claim it's foolproof.
Structured records cost you some nuance. That original profile was prose, and prose carries hedges and conditionals that don't survive being chopped into rows. "Insists on precise verification, but accepts speculative risk if the use is clearly scoped" is one thought. Split across two records it can read as contradictory. I ended up keeping a few records deliberately long rather than over-normalizing. Fields aren't always better than sentences.
And this is a personal-scale tool. One developer, one profile. I have not tested it as a shared team artifact, where merge conflicts and "whose habit wins" become real questions. Treat any claim about team use as unverified until someone actually runs it that way.
Where the boundary sits
Worth being honest about what this doesn't do. It doesn't hook into whatever harness inferred that original profile on the poster's machine. There's no import from an external agent framework, and I'm not going to pretend there is. What VicroCode gives you is the self-contained version: the SQLite store, the hosted review page, the tool call, all in one place, all editable by you. If your agent already lives in another IDE or a different runtime, this is a parallel artifact you maintain by hand, not a plugin into that system.
That limitation is also kind of the pitch. The value here isn't automation. It's that the description of how you work stops being something a model guesses at and becomes something you wrote down, can see, and can change on purpose.