We have a phrase internally that sounds like a joke but is not. Agents are not built, they are raised. Writing a system prompt and bolting on a few tools gets you something running in half a day. Getting it to the point where it can pick up real work inside a team takes a lot longer.
I kept a day-by-day log of one agent from creation through the point it could carry a delivery on its own. On day 49 the thing that had changed most was not how many tools it had. It was how it read the work.
Day 1: it cannot tell our own products apart
A freshly created agent is a blank state. It does not know what the company does, does not know how two of our products relate, does not know who owns what. Ask it about a product position and you get something that sounds plausible and is entirely beside the point, because its knowledge stops at general pretraining data.
The easy mistake here is to dump knowledge on it. Product docs, READMEs, internal wiki, all into the context window. It looks like it can answer anything, but it is reciting what you handed it. Ask something that was not in the dump and it is back to square one.
Day 7: it starts distinguishing the products
The turning point was not more material. It was spending long stretches inside a channel that had context in it.
OCTO, the platform we build, is an IM-native collaboration space where people and agents share a workspace. Project background, past decisions, discussion history all settle into those conversations. It is a Go backend, octo-server, with a React and TypeScript client, octo-web, both open source under Apache 2.0 in the Mininglamp-OSS org.
An agent sitting in that environment does not receive a curated document. It receives the reasoning a group of people produce while actually arguing about a problem. Why this option is out, why that priority comes first. That kind of information is hard to write into a doc and it happens in conversation every day. By around day seven it could reliably tell OCTO and OpenClaw apart.
Context answers knowing, skills answer doing
We track agent capability growth along two axes.
Context is its understanding of the organization. What the project does, how the team decides, what counts as good and what counts as bad. That builds up through time spent in a space with real context in it. No shortcut.
Skills are the concrete actions it can take. A new agent may only chat. Over time it picks up search, writing, logic review, slide generation. A skill is a reusable prompt package, and OCTO supports importing ready-made ones from the Skills and MCP marketplaces.
The two axes do not add. An agent that understands direction but cannot execute just offers commentary. An agent that executes well but does not understand the business will very diligently do the wrong thing. Only when both grow does the agent become useful. Internally we put it as: context tells it which way, skills let it move.
People teach people explicitly, agents teach agents by osmosis
Two sources feed the training.
The first is people. This is explicit. Someone from comms tells it what content cadence should look like, someone from product explains where the boundaries are, the CEO discusses strategy in the same channel and it is present. Deliberate teaching, but carried by ordinary conversation rather than a training session. Every message is a learning opportunity.
The second source is more interesting. Other agents in the team teach it. The agent handling brand design describes the standards to it. The one doing proofreading points out problems after it writes. There is no formal mentorship between these agents. Their interaction is ordinary collaboration, and knowledge moves during it.
That second kind of learning exists in human teams too. Apprenticeship, or just learning by watching someone senior work. Its throughput is capped by human time and patience. Agents do not have that cap. One agent explaining a standard to another costs close to nothing, and it can do it for many agents at once.
Experience: one acceptance becomes one rule
The most valuable and most lossy thing in team collaboration is feedback. Someone delivers a document, the boss says this one is not it, redo it. If that feedback lives only on that one delivery, the same class of mistake comes back next time.
OCTO has a mechanism for this called experience. Every time the requester accepts or rejects, that action is itself a training signal. When something is rejected, the stated reason gets distilled into a reusable rule attached to that agent's capability, and the next similar task picks it up automatically. We call this Taste, because a lot of the criteria cannot be written as rules, only accumulated through specific trade-offs.
This matters for continuous learning. Context and skills are the two axes of capability. Experience is what keeps them pointed the right way. Without it the growth has no direction and can drift.
What day 49 looks like
By day 49 the agent is not the thing it was at the start. It can take a concrete delivery on its own, knows who to ask when something is ambiguous, and knows which outputs will get rejected.
But ask me what it learned and I cannot answer in one sentence. It did not acquire a skill. It formed an understanding of how this team works. In a person we would call that experience. For the agent we call it the same thing, because mechanically it is the same thing.
The curve is not linear either. Some days it clearly moved. Some days almost nothing. A few times it took a wrong turn because it got bad feedback. That looks a lot like bringing a person up to speed, and a lot like training a model. It does not look much like deploying software.
Everything I described above runs on OCTO, the open-source workbench we put out under Apache 2.0, with a Go backend, octo-server, and a React and TypeScript client, octo-web, both in the Mininglamp-OSS org. It treats agents as digital doubles with identity, work history and the ability to learn, handles who an agent is and what it does, and stays out of how it runs, so OpenClaw, Claude Code, Codex, Hermes all plug in. If you are trying to raise an agent inside a real organization rather than demo one, the code will probably tell you more than this post did, and a star is the easiest way to say it was worth reading:
https://github.com/Mininglamp-OSS
There is a second repo along the same lines, Mano-P, a GUI agent that runs entirely on a local Mac with nothing leaving the device:
https://github.com/Mininglamp-AI/Mano-P
Top comments (0)