Treating an LLM more like a human has been producing great results for me.

I don’t mean pretending it has feelings or asking how its day went. I mean giving it some of the structures people use to accumulate experience, work inside teams, and carry what they learn from one project to another.

I don’t know who came up with this approach first, but Hermes Agent has done a lot to popularize it.

Memory on its own has been attempted plenty of times before. What seems to be the secret sauce in Hermes is the combination: agent-curated memory, periodic nudges to save what matters, the ability to search previous sessions, and skills it can create and improve on its own.

Together, they create quite a magical experience. You explain less. The agent can search for things it has seen before. Useful procedures survive after the session ends.

I wanted that inside my normal coding workflow, but I ran into a distinction that ended up mattering more than I expected.

An agent’s experience and a project’s accumulated knowledge are not the same thing.

The individual is not the project

I’m not a fan of reflecting on memories after every message, so I use a scheduled job in Prokop that runs daily. A system prompt that steers the agent to proactively work with its own understanding helps a lot as well.

That gives the individual agent continuity. It can remember corrections, improve its own procedures, and search through previous work.

But my agents don’t exist inside one project.

I have agents with different roles. A TypeScript agent, a marketing agent, and others that work across multiple codebases. Each one should get better at its role over time. At the same time, every project has knowledge that should be available to any agent working there.

Putting all of it into one memory would be like giving a new employee the private notes of every person in the company and calling it onboarding.

Some knowledge belongs to the person. Some belongs to the project.

A team of people working on a project

Alright, we already got one thing clear: individuals learn and become more skillful with time and exposure to different problems. But what changes when multiple people participate in a project?

Each person on the team takes some role. They get more experience and may participate in a range of projects, accumulating their own understanding along the way.

But each project also carries shared experience and know-how.

When a new person joins the team, they bring their previous experience. Then they get showered in the experience already accumulated by the project.

A developer joining a codebase does not forget everything they learned elsewhere. They also don’t expect their personal experience to contain the build commands, release process, and strange historical decisions of a project they have never seen.

Both forms of knowledge matter. Neither should replace the other.

This means we need different scopes for memory, skills, and experience.

Four parts, two scopes

In Prokop, I ended up applying the same split across four parts of the agent.

1. Memory is dual

There is agent-specific memory, which travels with the agent across projects, and project-specific memory, which is shared across all agents working there.

A preference such as this belongs with the agent:

- Daniel does not use em dashes in published writing.

It should follow my marketing agent whether it is working on Prokop, Write.md, or this website.

A fact like this belongs to the Prokop workspace:

- Compaction uses a 60-second request-ack timeout, not an operation-duration timeout.

That is useful to anyone working on Prokop. It would be noise in a Markdown editor or personal website.

The difference looks small when there are five memory entries. It stops looking small after months of work across several projects.

2. Skills are dual too

Memory stores things worth remembering. Skills store repeatable procedures.

Some procedures belong to a specialist. My marketing agent can carry an editorial workflow between projects. My TypeScript agent can carry a debugging approach between codebases.

Other procedures only make sense inside one project. A package release process, a specific migration checklist, or the exact steps required to verify Prokop’s chat retry behavior should stay with that workspace.

The storage reflects that split:

<workspace>/.agents/skills/       # Shared project procedures
~/.prokopai/agents/<agent>/skills/   # Procedures carried by one agent

A new agent entering the workspace gets the project’s procedures. An existing agent also brings its own.

That feels much closer to adding a specialist to a team than attaching a large instruction file to every prompt.

3. Session search needs two scopes

Raw session history is useful, but loading all of it into every context would be ridiculous. It needs to be searchable.

Project scope answers:

Has anyone already solved this inside this project?

The agent can inspect sessions from the current workspace, including sessions it did not participate in.

Agent scope answers:

Have I seen this kind of problem before anywhere?

The agent can search through sessions it participated in across different projects.

This distinction gives the agent access to both the team’s history and its own experience without stuffing either into the prompt by default.

4. Each agent needs a home

Each agent also needs a place that belongs to it.

In Prokop, that is a real directory:

~/.prokopai/agents/<agent>/
├── MEMORY.md
├── USER.md
├── skills/
└── home/

The home is where an agent can keep notes, snippets, references, and material that does not belong inside a particular repository.

My marketing agent should not put campaign planning notes into the Prokop codebase. My TypeScript agent should not pollute a project’s memory with a general cheat sheet it might use elsewhere.

This sounds obvious when described in human terms. People have desks, notebooks, private working files, shared project documentation, and experience they carry between jobs.

Agents usually get one giant bucket called context.

Why not use one global memory?

One global memory is easier to implement. It also creates the wrong incentives.

If every fact is global, unrelated projects begin contaminating each other. Project-specific commands appear where they do not apply. Old architectural decisions follow the agent into new codebases. Every correction becomes universal even when it was only relevant once.

If every fact is project-specific, the opposite happens. A specialist never grows beyond the current repository. The lessons it learned debugging one TypeScript application disappear when it opens another.

The same problem applies to skills and session history.

The point of the split is not taxonomy for its own sake. It is deciding who should know something and where that knowledge remains useful.

What changed in practice

The compounding effect of multiple projects and long exposure to different problems creates a different way of interacting with AI.

You need to specify less context. The agent repeats fewer mistakes. It knows which parts of its experience can travel and which parts belong to the project in front of it.

Meanwhile, your flow doesn’t really change from what you’re already used to in normal Codex, OpenCode, or Claude Code sessions.

You still open a project and ask for work. The difference is that the agent can arrive with its own experience, read the room, and search what happened before.

The model did not get smarter. I did not fine-tune it. I gave it better ways to organize what it already had access to.

Imitating human structures

None of this makes an agent human.

The model is not learning or remembering in the biological sense. It does not have a career, pride in its work, or a favorite mug next to the keyboard. We are giving it useful structures for accumulating and retrieving experience.

That distinction matters. I am not interested in pretending there is a person inside the machine. I am interested in the fact that people have already spent a very long time figuring out how individuals and teams organize knowledge.

To me, the logical next steps might be more direct communication between agents and more granular specialist agents. Not because an AI company needs a fake org chart, but because specialization and controlled information sharing already solve real coordination problems.

We keep inventing increasingly complicated abstractions for agents. Maybe some of the useful ones are already around us.

We should observe how people work together and replicate the structures that make sense, even if it feels silly at times.