For the past few years, most of my useful software ideas have started from the same place: a structured dataset, a deterministic flow, and a persistent feeling that the interface sitting on top of them is not quite the right one.

On the surface, GeneFitt looks like a fitness app. It has training programs, exercises, sets, supersets, caloric intake, protein, carbs, Apple Health data, blood work, genetic data, reminders and dashboards. All the familiar pieces are there. But the interesting part is not that it tracks fitness data, because a lot of apps already do that. The interesting part is that I can have a conversation with my own fitness data, and that conversation can change something real: a program, a training day, a weight, a reminder, an interpretation, a protocol.

That changes the relationship with the system. I am not just looking at numbers. I am not just filling in another dashboard. I am operating on a loop.

The problem was never finding a program

GeneFitt started from a simple frustration: building and adapting training programs takes too much time.

Not finding exercises. That part is easy. Not finding a “program” either. The internet is full of programs. The heavy part is building something that actually fits, then watching what happens, then changing it when the body does not behave the way the spreadsheet said it would.

You build a block. You input it into an app. You run it for a few weeks. Then recovery is slower than expected. One lift moves, another collapses. Sleep changes. Work stress changes. Nutrition changes. Suddenly the original plan is no longer quite the plan you need, so you start adjusting volume, intensity, exercises, rest time, estimated weights, progression logic and sometimes the entire structure.

Every fitness app I tried solved maybe sixty percent of this and then forced me into its own logic for the rest. I could track workouts, but not really think with the system. I could follow a plan, but not easily reshape it around my actual response. I could collect data, but not turn the data back into program architecture without a lot of manual work.

So I built my own thing. It is not public. I called it GeneFitt.

I initially stumbled on this idea from Charles Poliquin

The first version of the idea was not an LLM. It was not genetic testing. It was not Apple Health. It started much earlier, with Charles Poliquin.

I think it was fifteen or twenty yrs ago when I first got into Poliquin’s training methodology. Poliquin worked with elite athletes and built training systems around a very important idea: programs should not be designed only around the objective, whether that objective is hypertrophy, strength, fat loss or performance. They should also be designed around the nervous system profile of the person doing the work.

The language at the time was built around neurotransmitter dominance: dopamine-dominant, acetylcholine-dominant, GABA-dominant, serotonin-dominant. I do not mean this in the simplified personality-test sense of “I am this type of person,” because that usually makes people flatter than they are. I mean it in a practical training sense.

How much volume do you tolerate? How fast do you recover? How much intensity do you need before training feels alive? How often do you need exercise variation? Does repetition give you stability or does it kill your drive? Do you progress better with heavy low-rep work or with accumulated volume? Do you need novelty, precision, aggression, rhythm?

The premise was simple, but it stayed with me: training is not interacting only with muscles. It is interacting with muscles connected to a nervous system, which regulates stress response, recovery patterns, reward, motivation, arousal and fatigue.

At the time, there was no large-scale, commercially accessible genetic sequencing in the way we have it now. The closest thing I had was the Braverman Test, a self-administered questionnaire that tried to infer neurotransmitter dominance through verbal answers, symptoms, preferences and behavioural patterns. It was imprecise, obviously. In a way, I was trying to reverse-engineer biology through language. Still, it did the job, not because the test was absolutely true, because it probably was not, but because it forced the right question:

What kind of system am I adapting this program to?

That question stayed with me.

Years later, genetic testing gave me a better kind of approximation. Not certainty. Not destiny. Just a better map of where to look first.

For example, I found out about the MTHFR variant, which for me made a few things click into place. It gave me a better frame for things I had felt for years but could not properly explain, especially around nutrition, mood, energy, recovery and training response. Folate, methylation, homocysteine, B12, neurotransmitter synthesis and stress load became more than abstract words. They became parts of the system I needed to pay attention to.

Then other signals started adding layers: dopamine sensitivity, inflammation, insulin signalling, recovery speed, sympathetic response, parasympathetic tone. Each of them was incomplete on its own, but together they moved me further away from generic training logic and closer to the actual system being trained.

In that sense, GeneFitt did not really start as an app. It started as a fifteen-year attempt to replace generic training logic with increasingly better approximations of my own biological reality.

Genetics is a prior, not a verdict

I do not treat genetic data as destiny. That is the wrong frame. Genetics does not tell me exactly what to do. It tells me where to look first.

If there are signals around methylation, I pay more attention to homocysteine, B12, folate, energy and recovery. If there are signals around stress response, I pay more attention to HRV, resting heart rate, sleep and training density. If there are signals around insulin signaling and appetite regulation, I do not pretend that all calories are experientially identical just because they are mathematically identical.

The point is not to turn SNPs into identity. The point is to stop pretending that the body is a generic machine. Training is not just mechanical load. Nutrition is not just macros. Recovery is not just a rest day. All of them sit inside a larger control system made of nervous system regulation, hormones, inflammation, sleep, stress, reward and context.

This is where most apps break for me. They track one part. They show one dashboard. They give one recommendation. But they do not hold the loop together.

What GeneFitt actually does

GeneFitt is where I operationalise this without spending ten hours a week manually rebuilding everything.

I have biometric data from Apple Health. I have additional data I upload myself: genetic data, blood work, training history, nutrition logs, supplement protocols and personal constraints. Then I talk to the app.

Not in the vague “make me a workout” sense. More like: I want a new training block. This is the goal. This is how much time I have. This is the equipment. This is what worked last time. This is what did not. These are the constraints I care about.

The LLM helps generate the program, but the output is structured. Once I agree on a version, GeneFitt builds it directly into the workout zone: days, exercises, sets, supersets, warm-up, tempo and rest time. Where it has enough history, it calculates estimated 1RM and derives working weights based on the goal, rep count, tempo and progression logic.

That part is useful, but it is not the real value. The real value starts after the program is running.

At the end of each week, the system looks at what actually happened. Workouts completed. Biometric trends. Recovery signals. Nutritional intake. Bodyweight. Steps. Cardio. Sleep. Caloric expenditure. Whatever data is available.

Then it cross-references that with the priors: genetic data, blood work, known constraints and previous responses to similar blocks. From there, it proposes adjustments. Not generic fitness advice, but specific changes.

Reduce volume here. Keep intensity there. Move this session. Change this rep range. Add Zone 2. Remove a high-stress element. Keep the progression because the signal is good. Deload earlier because the recovery data is not there.

If I accept, the program updates in two or three minutes. No spreadsheet copy-paste. No manual rebuild. No re-entering everything into an app that was never designed for how I think.

The loop is the product

The useful part is the loop.

Genetic priors, blood work, biometric data, training program, actual execution, recovery signal, LLM interpretation, proposed change, human approval, updated program.

That last part matters. The LLM does not silently rewrite the system. It proposes. I accept or reject. Only then does the app modify structured data.

That distinction is important because I do not want a chatbot pretending to be a coach. I want an interface that helps me interrogate my own data and operate on it faster.

Chat is the interface. The app is the structure. The deterministic flow is what makes it useful.

Nutrition became part of the control surface

GeneFitt is not just about training. Nutrition also became part of the same control surface.

Not “what should I eat?” in the abstract. More like: what does this input do to recovery, cravings, sleep, inflammation, training output, body composition and cognitive energy?

I track caloric intake, protein, carbs, fats, caloric expenditure from walking and running, distance, steps, weight and other signals. I can group them by day, week or month, depending on the question I am trying to ask.

The point is not to worship data. Most dashboards show you data. Very few help you ask better questions of it.

If weight changes but training output collapses, that means one thing. If weight changes while strength and recovery stay stable, that means something else. If calories are low but protein is insufficient, the conclusion changes. If HRV drops after a certain training density, the program should know that. If sleep is bad and resting heart rate is elevated, the next workout should not be treated as if it exists in isolation.

This is the part I wanted: a personal sport and nutrition system with an LLM inside it, but not as a magic layer. More as a translator between messy reality and structured action.

Protocols should not live only in documents

I also use it for reminders and protocols I do not want to keep in my head.

Blood work checks. Supplements. Seasonal adjustments. Things that matter, but are easy to forget because they do not scream for attention every day.

The dashboard rotates them cyclically based on what I have told it I need at that point in the year. This sounds small, but it is not. A lot of personal health systems fail because they live either as documents or as apps.

Documents have context, but no execution. Apps have execution, but no memory of why the system exists.

I wanted both.

A protocol should not just sit in a note. If it matters, it should be able to become operational: reminder, rule, dashboard element, review point, proposed adjustment. Again, not because the app “knows” what is true, but because it keeps the loop alive.

Why an LLM belongs here

The LLM is useful because the data is heterogeneous.

A workout program has one structure. Apple Health has another. Nutrition logs have another. Blood work has another. Genetic data has another. Notes and protocols have another.

Humans are bad at continuously integrating all of that. Classic software is bad at flexible interpretation. LLMs are good at translation across messy contexts, but dangerous if you let them act without constraints.

So the architecture matters.

The LLM does not replace the database. It talks to it. It does not replace the program structure. It generates and modifies structured objects. It does not replace judgment. It accelerates the review loop.

This is the pattern I keep coming back to in personal software: conversational input, structured output, deterministic execution.

The chat is not the product. The state change is the product.

The MCP layer: specialist inside, generalist outside

One thing I added later was an MCP layer that connects GeneFitt to one of the agents I run in OpenClaw, my multi-agent system.

The in-app LLM runs through OpenRouter, so it costs me per call. But cost is not the main reason for the split. Context is.

The in-app LLM should stay narrow. It should be good at sport, nutrition, training programs, biometric interpretation and the internal logic of GeneFitt. The OpenClaw agent lives outside the app, in a broader swarm. It has access to more context from other domains I keep updating: calendar, work density, finance, projects and other personal systems.

So when I want the narrow health and training loop, I stay inside GeneFitt. When I want a broader perspective, such as correlating training load with work calendar density, pulling supplement spending into the same conversation, or understanding why a training block failed during a period of unusually high cognitive load, I go to the external agent.

The narrow specialist lives in the app. The generalist lives outside, in the swarm. They talk through MCP. Each stays good at what it is good at.

That separation changed how I think about personal tools. Not every app needs to become everything. Some tools should be narrow and precise. Others should hold broader context. The interesting part is not one giant assistant that does all things badly. The interesting part is building agents and apps that understand their boundary.

A private interface to my own body

I do not know if GeneFitt should ever be a public product. Maybe parts of it could be. But that is not the interesting part for me right now.

The interesting part is that it changes the relationship with personal data.

Apple Health, blood work, genetic priors, nutrition logs, training history, supplements and protocols normally live in separate places. Some in apps. Some in PDFs. Some in spreadsheets. Some in memory. Some in notes you never reopen.

GeneFitt turns them into something I can talk to.

Not in the performative AI demo sense. In the practical sense. I can ask a question, get an interpretation, approve a change and have the system update itself.

That is a different kind of software. Not a dashboard. Not a chatbot. Not a generic fitness app.

A private interface to my own body, built around a loop I actually use.

For me, this is where LLMs become genuinely useful: not when they produce more text, but when they make personal systems easier to operate.

I started from a practical irritation, not from a theory.

I wanted to understand whether a single LLM, placed in the middle of everything, could actually handle nutrition advice, training decisions, financial reasoning, code review, medical interpretation, and business operations inside the same broad context. Not whether it could talk about them. That part was obvious. It could talk about almost anything. The real question was whether it could make useful decisions inside each of those domains once the surface fluency stopped being impressive.

My first answer was: not really. But the uncomfortable part was that it sounded like it could.

The outputs were plausible. The tone was competent. The system moved from one topic to another with a kind of elegant indifference, as if all domains were made out of the same conversational material. But the decisions were often generic, and the mistakes were not obvious enough to be rejected immediately. It failed in the way generalist systems often fail: not by producing nonsense, but by sounding reasonable while missing the structure of the specific case.

That led to the hypothesis behind this architecture.

A specialist who has worked with you for months, who has seen your decisions, accumulated your preferences, adjusted its method to your actual situation, is fundamentally different from a generalist agent created at task time with a good system prompt.

The difference is not only that the specialist has access to more information. It is that the specialist has acquired a shape. It has a bounded role, a memory of prior decisions, a method for the domain, a way of interpreting you, and a disciplined relationship with current state.

At the beginning, I thought the main difference would be knowledge. The specialist would simply know more about the user. That turned out to be true, but incomplete. The real difference came from structure. Memory provided perspective. Files provided rules. Tools provided live state. The specialist only became trustworthy when those three things stopped being mixed together.

That distinction became the spine of the system.

A specialist agent is not just a generalist with more memory attached to it. It is a persistent identity bounded by explicit structure, with accumulated perspective on shared facts, rules that evolve under user approval, and live state acquired only from canonical sources.

This sounds almost too formal when written out, but in practice it is the difference between a system that sounds personal and a system that can actually become reliable over time.

This is the architecture I built to test that idea, and what the idea became after being forced through implementation.

An agent in action

The clearest example is not the one where the system gives a clever answer. A generalist can give clever answers. The clearer example is where the system refuses to design an answer until it checks whether the user’s premise is visible in the data.

Take a fitness and recovery question.

User question

I keep seeing the same pattern. I train hard for several days, stay in a calorie deficit, feel in control for a while, and then I crash into a few days of no training and overeating. Can you help me structure next week so I don’t repeat this?

A generic LLM can answer this immediately. It can produce a seven-day workout plan, add recovery advice, mention sleep, and sound useful. But the specialist does something different: it first checks whether the pattern exists in the instruments.

Agent response

Before I structure the week, I want to verify whether the pattern you describe appears in the data, or whether we are only working from impression. If the pattern is not visible in the instruments, the intervention should be different.

I’m checking the last 30 days of workouts, the last 14 days of health snapshots, recent weekly analyses, the active training program, and the current nutrition targets.

The pattern is visible.

Workout records show clusters of several high-intensity days followed by two-to-four-day gaps. HRV drops below baseline after those clusters, often before the behavioral crash appears. Sleep quality worsens around the same windows. Nutrition data is partial, but where it exists, the gap days are also the days where calories rise above target.

I would not treat this as a motivation problem. I would treat it as a recovery design problem.

So next week should not be another aggressive cut with more discipline added on top. It should be structured to interrupt the sequence before it completes: capped training volume, one mid-week maintenance day, one structured refeed, active recovery, and numeric guardrails.

If HRV drops below baseline by the defined threshold, the day is downgraded automatically: strength becomes Zone 2, Zone 2 becomes walking, walking becomes rest. If sleep falls below the minimum threshold, intensity is capped regardless of what the plan says. If deficit days accumulate beyond your known tolerance, maintenance becomes mandatory.

I can use your recovery and metabolic profile as risk modifiers when setting these thresholds, but not as deterministic explanations. The instrumented pattern matters more than any single marker.

There are also limits in the data. External stress is not instrumented here. Recent body composition is missing. Nutrition logs are only partially populated. So I can structure the week around the pattern that is visible, but I would not pretend the picture is complete.

What this shows

The relevant move happens before the plan. The agent does not begin by generating a plausible seven-day protocol. It begins by testing the user’s description against the available evidence.

That requires access to the user’s actual workouts, HRV, sleep, nutrition targets, active program state, prior weekly analyses, and recovery profile. It also requires knowing which signals are canonical, which are partial, and which are missing.

This is where the architecture becomes visible. Memory contributes the recurring pattern, prior interventions, and the user’s known thresholds. Tools provide live state from GeneFitt and connected health data. Domain rules interpret recovery, intensity, deficit exposure, and guardrails. The LLM composes the answer, but it does not invent the evidence.

A generic model can produce a plan that looks reasonable. The specialist first establishes whether the plan should exist in that form at all.

The three things I had to stop confusing

The architecture started working when I stopped asking one layer to do every job.

Memory is not state. Rules are not memory. Tools are not judgment.

This sounds simple, but a surprising number of agent systems blur these distinctions. They put durable preferences, current facts, domain methodology, tool outputs, and conversational traces into one expanding context and hope the model will sort them out. Sometimes it does. Often it does not. More importantly, when it fails, it becomes hard to know why.

Memory should store perspective. It should remember that the user has a recurring overtraining-to-crash pattern. It should remember that the user responds better to pre-emptive guardrails than to reactive correction. It should remember decisions, tendencies, unresolved tensions, prior interventions, and recurring patterns. But asking memory what the user’s HRV was this morning would be a category error. That information belongs in the system that owns current health state.

Rules should live somewhere else. In this architecture they live as markdown files in a git-versioned vault. They define the specialist’s identity, domain method, user-specific protocol, personal operating patterns, refusals, boundaries, precedence rules, and communication style. The LLM does not invent its own method at runtime. The orchestrator assembles the method from files that can be inspected, edited, versioned, and rolled back.

Tools, in turn, fetch live state. If the recovery specialist needs workouts, HRV, sleep, nutrition targets, active program state, or weekly analyses, it reads them from GeneFitt and connected sources. If a finance specialist needs budgets and transactions, it reads them from the cashflow application. If another specialist needs a calendar, a database, a spreadsheet, or an external API, it calls a deterministic tool connected to the canonical source.

The LLM is not asked to remember numbers. Memory does not store current state. Files do not store current state. State lives in the system responsible for it.

Every time these boundaries were violated, the failures became predictable. Memory used as state produced stale or hallucinated numbers. Tools used as perspective produced answers with no continuity from one session to the next. Rules hidden inside prompts became difficult to audit and easy to lose. LLM-controlled workflows looked elegant until the model skipped a protocol under pressure. Automatic learning without a user gate turned passing conversational artifacts into durable behavior.

So the discipline is not philosophical decoration. It is what prevents the system from becoming a very articulate swamp.

What happens at runtime

When a user sends a message, the system does not simply throw everything into the model and ask for wisdom. The runtime path is controlled by the orchestrator.

First, the message is classified. A small structured LLM call identifies the likely domain, intent, risk, complexity, candidate specialist, memory query terms, and possible live data sources. This is not the answer. It is a way to give the deterministic parts of the system a clean starting point.

Then memory is queried through the candidate specialist’s lens. This matters because the same workspace can be read differently by different specialists. A recovery specialist looking at the user’s memory should see training patterns, physiological thresholds, prior interventions, and failed protocols ranked highly. A finance specialist should see financial decisions, budget preferences, and prior tradeoffs. A business operations specialist should see processes, bottlenecks, handoffs, and recurring constraints.

The corpus may be shared, but the interpretation is not flat.

After that, the orchestrator loads the specialist’s framework from the vault. It composes identity, domain skill, project method, and personal patterns into a prompt stack. The composition is deterministic. Same files in, same structure out. The model is not choosing who it is today.

Only then does the specialist fetch live state through its allowed tools. In the GeneFitt example, this means reading workouts, health snapshots, weekly analyses, active program state, and nutrition targets. The answer’s evidence comes from these reads, not from memory and not from the model’s guesses.

Finally, the LLM receives the assembled system prompt, the relevant memory claims with provenance, the user message, recent session context if needed, and the specialist’s tool catalog. It synthesizes the response inside a bounded role.

One practical decision mattered more than I expected: the LLM layer runs through OAuth profiles, which made many small deterministic LLM calls affordable as an architectural habit rather than something to avoid. If every classification, recall shaping, review, and synthesis step carried a visible marginal cost, the design would be pushed toward fewer, heavier, more overloaded calls. The OAuth backbone made it easier to keep the system modular: several bounded calls, each with a narrow job, instead of one giant prompt asked to do everything.

This separation between structure and synthesis took several failed iterations to learn. I tried controlling the system by writing more detailed protocols into the prompt. It worked until it did not. The model would follow the protocol when the task was clean, then skip parts of it when the situation became long, ambiguous, or tempting. The more reliable pattern was to let code control the flow and let the LLM do what it is actually good at: synthesis inside a prepared frame.

Code decides what gets loaded, what gets called, what is allowed, and what has to be audited. The LLM composes meaning from the material it is given.

That is a very different architecture from asking the model to be the architecture.

Why bounded cognition matters

The phrase “bounded cognition” matters because the problem is not only context size. Larger context windows help, but they do not remove the need for boundaries. Every instruction, tool definition, memory, file, and rule loaded into a model competes for attention. The fact that something can fit inside context does not mean it belongs there.

A generalist agent carrying nutrition knowledge, training rules, medical interpretation, code conventions, business operations, financial context, and personal preferences all at once becomes overloaded in a subtle way. It may still sound coherent. It may even sound more impressive than a narrower system. But fluency is not depth. The answer can become correct enough to pass a glance and wrong enough to fail in practice.

I kept seeing three recurring failure modes.

The first was context inflation. Every new tool, file, and memory felt useful in isolation, but the combined system became noisier. The second was boundary collapse. If every agent can access everything, specialization becomes theatrical. A recovery specialist with access to every personal, business, financial, medical, and operational claim is not really a recovery specialist. It is a generalist wearing a recovery costume. The third was session fragility. Without persistent identity, every session starts from zero, and the user keeps training the same new assistant again and again.

A specialist is not a smaller generalist. It is a persistent identity operating inside a bounded cognitive environment. It has accumulated domain knowledge, scoped tools, scoped memory, explicit permissions, and a specific way of interpreting the user over time.

The goal is not maximum context. The goal is the right context, through the right lens, with the right boundaries.

The three layers

The system ended up with three layers and one cross-layer memory fabric.

The first layer is the substrate. This is the non-cognitive foundation: runtime, filesystem, version control, integrations, tool registry, project artifacts, and session infrastructure. It answers the basic questions: what exists, what is reachable, what can be loaded, and what can be executed.

In this implementation, the substrate is intentionally boring. Almost every durable piece of system state that is not live data lives as markdown in a git-versioned vault. Specialist identities are markdown files. Skills are markdown files. Project methods are markdown files. Personal patterns are markdown files. System documentation lives there too.

This is not because markdown is glamorous. It is because files and git give the system history, audit, rollback, branching, and inspectability. If a rule changes, there is a commit. If a specialist drifts, the change can be seen. If an experiment fails, it can be rolled back. There is no hidden personality evolving somewhere in a database fog.

The second layer is the orchestrator. This is the control layer. It handles intake, classification, routing, prompt composition, governance, session management, and write-back handling. It does not need to be the domain expert. Its job is to decide what should happen next and what context should be made available.

The third layer is the specialist layer. Specialists are bounded workers with persistent identity. Each specialist has a domain, a project context, data permissions, tool permissions, a memory lens, rules, a working surface, and a communication style. The important part is that these are not fused into one prompt blob. Voice does not grant domain authority. Personality does not grant access to data. Memory does not become state. Tools do not become judgment.

This makes the specialist inspectable. You can update the domain method without rewriting the voice. You can change the user-specific protocol without changing the underlying skill. You can adjust personal patterns without rebuilding the whole agent.

Across these layers sits semantic memory. That is what allows a system with multiple bounded specialists to remain coherent instead of becoming a committee of forgetful strangers.

Memory as perspective

In a multi-agent system, fragmentation is intentional. One specialist handles recovery, another finance, another code, another operations. This gives depth, but it creates a new question: if cognition is distributed, where does continuity live?

It does not live in raw conversation history. That eventually becomes a transcript pile. It does not live only in files either. Files are durable and auditable, but they do not answer what currently matters, what has been decided, what is unresolved, or which past claim should influence this answer right now.

This is where IdMem becomes structurally important. It is not just a vector store attached to the side of the system. It is the semantic memory plane that lets multiple specialists operate over shared knowledge without collapsing into one undifferentiated assistant.

The unit of memory is a claim: a structured statement with provenance, timestamp, confidence, and epistemic tier. Claims live inside workspaces, which act as privacy boundaries. Personal claims and business claims are separate. A personal recovery specialist cannot read business pipeline claims. A business specialist cannot read personal health claims.

Within the same workspace, specialists do not get separate memory silos. They query the same corpus through different lenses. The recovery specialist sees training patterns, protocols, markers, symptoms, and interventions ranked higher. The finance specialist sees financial decisions and preferences ranked higher. The operations specialist sees processes, constraints, and recurring bottlenecks ranked higher.

Same world, different lens.

That middle path matters. Separate memory silos destroy continuity. Every specialist becomes the owner of its own partial user, and the system slowly fragments. But if every specialist sees everything equally, specialization collapses. Shared memory with agent-specific ranking gives continuity without flattening perspective.

Memory also needs epistemic discipline. A direct user assertion is not the same as an agent’s interpretation. A live tool reading is not the same as a derived hypothesis. A decision explicitly made by the user is stronger than a pattern inferred by the system. Interpretations can be useful for retrieval, but they should not silently overwrite facts.

The system treats this through three epistemic tiers. Tier A is authoritative: direct human assertions, explicit decisions, system events observed first-hand, and live tool readings. Tier B is operational: what an agent did, saw, processed, or reported while working. Tier C is support: hypotheses, derived insights, interpretations, and synthesis. Tier C can help retrieval and reasoning, but it cannot modify shared truth. A hypothesis may be useful, but it does not get to overwrite a decision.

There is also a temporal lifecycle. Most claims start in short-term memory, where they can remain useful without pretending to be permanent. Claims that keep resurfacing, or that become part of stable user behavior, can move into long-term memory. Dormant claims eventually fall into archive, where they are still retrievable by semantic pull, but no longer occupy the same active surface.

This matters because memory is not only about storing more. It is about knowing what kind of thing a memory is, how strong it is, how fresh it is, and which specialist should care about it.

When a new claim conflicts with a high-confidence existing claim, the system raises tension instead of quietly choosing the more recent sentence and moving on. That is how memory stays useful without becoming mud.

Tools should be small and deterministic

Specialists do not compute live state from prompts. They fetch it from tools.

This sounds obvious, but it changes the way you build the surrounding system. A tool does not have to be a grand platform. It can be a full microservice with a database, but it can also be a lightweight HTTP server over a Google Sheet, a CLI wrapper around an external API, or a cache file refreshed on demand.

GeneFitt is a good example because it is not merely “context” pasted into an agent. It is a domain application that owns live state: workouts, snapshots, targets, program structure, and analyses. The specialist can read from it through explicit tools, and, where approved, can write back changes to the active program. That is a different relationship from asking a model to remember what the training plan was supposed to be.

The same pattern applies to less sensitive domains. A cashflow tool can use Google Sheets as the canonical store, with a small HTTP server exposing read endpoints and a basic HTML page for human inspection. The user gets a normal spreadsheet they can edit by hand. The specialist gets clean endpoints. Both operate against the same source of truth.

This is important because new domain capability should not require a new platform every time. Many useful specialist systems can start with a spreadsheet plus a thin deterministic interface. Others may need a more serious application. The architecture does not care, as long as the tool has a clear contract and the source of truth is explicit.

The tool’s job is to say what is currently true in the system it owns. The specialist’s job is to interpret that state through memory and rules. The LLM’s job is to synthesize the answer.

Again, the boundary is the feature.

Learning without turning into drift

A specialist has to learn over time. Otherwise it is just a roleplay session with better filing. But automatic learning is dangerous, because conversation is full of half-thoughts, moods, trial balloons, exceptions, and temporary preferences. If every conversation rewrites the system, a passing remark can become a durable rule.

So learning happens through explicit loops, with the user as the gate. There are three of them.

The first is session harvest. At the end of a session, the specialist that participated in the conversation reads the transcript and proposes durable write-backs. It can identify facts the user asserted, decisions that were made, unresolved questions, validated protocols, and possible rule updates. Each proposal carries a reference quote, so a future belief can be traced back to the moment that produced it.

Facts and decisions can enter semantic memory quickly. Rule changes cannot. If a rule will change how the specialist behaves in future sessions, the user has to approve it. This creates a useful asymmetry: the system can remember efficiently, but it cannot casually rewrite its own operating method.

The second loop is the knowledge heartbeat. This is a scheduled review where a specialist’s rules can be compared against current external knowledge or updated domain consensus. The point is not to let the system auto-update itself from the web. The point is to surface proposed refinements with enough context for the user to approve, reject, or defer them.

The third loop is agent review. This looks not at the domain knowledge itself, but at the specialist as a working identity: where it hesitated, where the user corrected it, where its scope was too narrow or too loose, where its communication style created friction, or where a repeated pattern deserves to become part of its operating method.

The three loops touch different things. Harvest learns from conversations. Heartbeat learns from the outside world. Agent review learns from use. All three share the same discipline: the system may propose, but the user decides what becomes durable.

That is what prevents drift while still allowing compounding. The system improves, but it does not get to become a different system behind the user’s back.

Daily surfaces and operational spine

The architecture is not tied to one chat window. That matters, because a specialist system that can only be used in one interface is still trapped inside a demo shape.

In daily use, the same brain can sit behind multiple surfaces. Telegram can be the quick personal interface. Slack can be the team-facing surface, where agents behave more like operational participants than private assistants. A dashboard can expose the system’s health: sessions, queues, costs, token usage, tool calls, learning proposals, cron activity, failures, and drift signals.

This is not just convenience. Multi-channel infrastructure tests whether the architecture is real. If the same pipeline, vault, memory, tools, and governance layer can operate behind Telegram, Slack, and a dashboard, then the channel is only transport. The cognition lives elsewhere.

The dashboard and cron jobs are part of that operational spine. Scheduled jobs can run heartbeat checks, drift detection, digests, maintenance tasks, and review queues. The dashboard turns the system from something you talk to into something you can observe. That changes the relationship completely. Debugging stops being folklore and starts becoming a checklist.

This is also why the architecture keeps surfaces thin. A new channel should not require a new brain. It should translate the incoming message into the internal call, attach session and channel metadata, and render the response back. Everything important remains shared: orchestrator, vault, IdMem, tools, governance, and audit.

Governance as mechanism

Governance in this architecture is not mainly a policy document. It is mechanism.

Forbidden data is not injected into the prompt. Forbidden tools are not registered for the specialist’s LLM call. If a specialist tries to invoke a tool outside its bound list, the call is refused and audited. If new memory conflicts with high-confidence existing claims, the conflict is surfaced instead of silently overwritten.

The markdown vault becomes part of the governance layer because durable changes are commits. Rules have history. Rollbacks are possible. The system can explain not only what it currently believes or how it currently behaves, but how it got there.

This matters because trust in specialist AI will not come from smoother language. It will come from inspectability. Can I see what rule caused this behavior? Can I see where this memory came from? Can I see which tool produced this number? Can I prevent this specialist from touching that data? Can I roll back a bad change?

If the answer is no, the system may still be impressive, but it is not yet trustworthy.

What the hypothesis became

The original hypothesis was that a specialist who knows you over time is fundamentally different from a generalist created at task time.

Building the architecture confirmed that, but not in the way I first expected. The difference is not just accumulated knowledge. Accumulated knowledge without structure produces a more confident generalist. It knows more fragments. It can imitate continuity. It can sound personal. But it still collapses perspective, rules, and state into one soup of context.

What creates a real specialist is accumulated structure.

Memory provides perspective. Vault files provide rules. Tools provide live state. The orchestrator keeps them separate. The specialist composes them inside a bounded identity. The user decides what becomes durable.

That is the architecture in one paragraph.

The strongest AI systems may not be the ones that maximize context. They may be the ones that bound it correctly. Not one giant agent with everything inside its head, but a substrate that knows what exists, an orchestrator that controls what happens next, specialists that operate within explicit limits, IdMem as a semantic memory plane that provides continuity without flattening perspective, tools that provide current state without pretending to reason, multiple surfaces that share the same cognitive backend, and learning loops that compound only through approval.

The difference between this architecture and a single giant agent is the difference between hiring someone for a day and working with a team that has known your world for months. Both can do tasks. Only one develops judgment in context. Only one improves without starting from zero every morning. Only one can become worthy of decisions that matter.

I stepped outside for a walk and everything felt strange. The streets I knew, the apartment blocks, the trees, the whole familiar set of daily life no longer felt like mine. Recognizable, but distant. As if the place had stayed where it was, but we had somehow gone very far away without ever leaving our chairs.

That’s what happens to me when I go all the way into something. It isn’t just concentration. It’s a wholesale move into a different logic, one that doesn’t belong to ordinary life, one that pulls away from what is physically, emotionally, intellectually familiar. And the process is not just distance. It’s dismantling. To create something, or to repair something, I don’t just build. I take apart. I take an idea, break it open, rebuild it, break it again, rebuild it differently. I do that dozens, maybe hundreds of times, until I get to something that can stand on its own in reality, without me.

That’s why the process can sometimes feel like an attack on personal identity. The ideas I have about what I’m building are not cleanly separated from the way I see the world. They come from me. From how I process reality, from what I think makes sense, from what feels elegant, coherent, alive. So when I break the idea apart, I don’t come away untouched. Evisceration is a harsh word, but sometimes it’s the right one.

And after enough iterations, even if they all happen over a short stretch of time, it starts to feel as if I’ve been living in another world. The world of the problem. The world of the project. The world of that thing I have to metabolize in order to really learn it, and that, for a while, asks for everything I have. And when I come back out of it, the real world doesn’t take me back immediately. I have to reacclimate. I have to remember what simple things feel like, what normal life looks like, what it means to be present without breaking everything I see into components, causes, and logical relations.

This kind of effort is different from what people usually mean by “work” as it requires a different kind of approach. It is profoundly hostile to a person who no longer lives only for himself. It runs against social life, family life, against almost any modern idea of well-being. It asks for the whole of you. And during that time, you barely have anything left to give anyone else, not even yourself.

But that is not necessarily what happens.

Cheaper and easier execution does not automatically create productivity. In many cases, it first creates volume. More products, more content, more ideas, more prototypes, more experiments. And a lot of them are only half-baked.

A good comparison is traffic in a city that was not built for a much larger number of cars. More people being able to drive does not automatically improve transportation. If the roads, rules, and habits are not ready, the result is congestion. You have more movement, but a worse experience overall. Satisfaction goes down, not up.

AI can create the same kind of effect.

When the cost of making things drops, more things get made. But the system around that production does not instantly improve. Companies do not suddenly become better at choosing what matters. Markets do not suddenly become better at filtering quality. People do not suddenly become better at judging what is useful and what is noise.

So the bottleneck moves.

Before, the hard part was producing. Now, the hard part is deciding. What is worth building? What is good enough to ship? What is real value and what is just fast output? AI makes creation cheaper, but it does not make judgment equally cheap.

That is where the real problem begins.

If the amount of output grows faster than our ability to evaluate and absorb it, then we do not get productivity. We get clutter. We get noise. We get too many weak solutions competing for attention. And that can make the whole system feel worse, even if the tools themselves are more powerful.

This is why AI alone is not enough. New tools also require new ways of thinking. They require better processes, better standards, better education, and better infrastructure around decision-making. Otherwise, we are just adding more cars to roads that are already overloaded.

So yes, AI can eventually create real productivity. But that only happens after people and organizations learn how to work with this new reality. Until then, what looks like progress may actually be a period of confusion, overload, and lower overall satisfaction with much higher output of noise.

This is a personal hobby project. It has no pretensions of being a commercial product or production-ready system just my curiosity about how data would work better as memory and should work for AI agents.

I’ve been building something I call iDmem. It’s a shared memory layer that sits between the places where context shows up in our work and the agents that need to use it. Slack, email, GPT, Claude, documents, API events. Instead of letting all of that live in separate pockets, I wanted one memory that could hold it together.

I didn’t build it because I wanted another AI product. I built it because I kept running into the same problem: too much context, spread across too many places, with no reliable way to reuse it. Before I get into how it works, it’s easier to show what a normal day looks like with it running.

What this looks like on a normal day

Here’s a real Tuesday with iDmem running in the background.

Morning. Slack is alive. In our #general channel, Lavinia posts that she’s confirmed a partnership with a university for an employer branding campaign. Matei replies with a timeline for the content drops. I jump in with a note that the client budget got approved but we need to invoice by end of month. Three different people, three different signals all flowing into the same memory through the Slack connector.

Midday. I’m in Claude, working through some strategic thinking about next quarter. The conversation touches on which verticals to prioritize and why our current ratecard doesn’t work for smaller companies. This flows into iDmem through MCP the same memory brain, different source.

Afternoon. I drag-and-drop a PDF into the iDmem web UI a 15-page report on student brand perception from a survey we ran (653 respondents). The import pipeline segments it, extracts claims, resolves entities, and files it alongside everything else. Same brain, third source.

Now the interesting part.

I open a DM with our OpenClaw bot in Slack. Just me and the bot, private. I ask: “What’s our financial situation with active clients right now?”

The bot queries iDmem through my personal agent profile. It knows I care about revenue, cash flow, invoicing deadlines, pipeline risk. It pulls up the budget approval from this morning, cross-references it with the ratecard discussion from Claude, and gives me a view weighted toward commercial exposure and timing. It mentions the end-of-month invoice deadline as the top priority.

Meanwhile, in #marketing, Lavinia asks the same bot: “What’s happening with our clients and campaigns?”

Same memory. Same 3,800+ events. Same bot. But Lavinia’s agent profile is tuned toward content strategy, employer branding, audience positioning. She gets the university partnership at the top, the content drop timeline second, the brand perception survey findings third. The invoice deadline? It’s there, but it’s page-two context for her not the lead.

In #production, Matei asks: “Ce campanii avem active și ce trebuie livrat?”

He gets the timeline he posted this morning surfaced first, alongside the content drop schedule, the asset status, and the delivery dependencies. The ratecard discussion from my Claude session? Irrelevant to his world. It doesn’t show up in his top results.

Three people. Same memory. Same bot. Three different “most important” answers.

This isn’t magic, it’s architecture

What’s happening under the hood is a separation that seems obvious once you see it, but that I haven’t found in the memory systems I’ve tested.

One shared memory layer. Slack messages, Claude conversations, uploaded documents, and API events all flow into the same shared operational record. Raw events get processed into structured claims, entities, relationships, and temporal state.

Many personal lenses. At read time, not at write time, each agent applies their own filter. Domain affinity, weight bias, familiarity, and principles. The retrieval engine combines vector similarity with structural signals like entity importance, conflict tension, recency, and then adds this per-agent adjustment on top.

The result: the same query over the same data produces different orderings for different agents. Not different data, different relevance. And it’s deterministic: ask the same question twice, get the same answer. Ask from a different perspective, get a different answer, but always the same different answer.

I think of it as shared memory, subjective interpretation.

The proof that it’s not just noise

A fair question: maybe the different results are random variation, not real perspective. So I ran benchmarks on real data 3,800+ memories from my own startup, three agent profiles based on actual team roles, 10 queries across prioritization, clients, pricing, content, risk, and metrics.

• 70% of queries: at least one agent sees a different #1 result

• 61% worldview divergence across top-3 results

• 100% consistency within the same agent across 5 identical runs

• 560× more divergence between agents than within the same agent

That last number matters most. The perspective signal is 560 times stronger than the noise floor. This isn’t randomness. It’s a stable perspective signal, expressed deterministically.

What I’ve actually built (so far)

This is the part where I go into some detail, because the architecture decisions matter and they’re where most of the thinking went.

The ingestion layer: Universal Memory Fabric

I started from the premise that memory quality is bounded by ingest quality. If information arrives truncated, without speaker attribution, without thread continuity, then even perfect retrieval can’t compensate.

So I built a Universal Memory Fabric a single gateway that normalizes everything into canonical events before the semantic pipeline even touches it. Every source gets its own connector, its own normalizer, and per-source deduplication via SHA-256 idempotency keys. Six sources are live in production: Slack (OAuth, threads, channel names), Gmail (OAuth, HTML fallback, pagination), MCP (Streamable HTTP works with GPT and Claude), OpenClaw (native plugin hooks), file import (web UI, with segmentation for long documents), and direct REST API.

But raw ingest isn’t enough. I learned the hard way that not everything that comes in should be treated equally. So I added a curation layer that runs before extraction: keep_core (full semantic extraction), keep_context (lighter treatment), archive_only (persist and embed but skip full extraction), and drop (tabular noise, generated boilerplate). This alone dramatically improved retrieval signal-to-noise.

The write pipeline: from text to semantic memory

When an event clears curation, it goes through a multi-stage extraction pipeline: micro-extraction for fast flags (decisions, commitments, preferences, urgency), full LLM extraction for structured claims with subject/predicate/object, entity and topic resolution linking claims to the knowledge graph, embedding generation (text-embedding-3-large), world state projection updating the shared truth with temporal awareness, and relationship extraction building the entity graph.

Every event enters Short-Term Memory (STM). Organic engagement promotes it to Long-Term Memory (LTM). Dormant memories auto-archive after 90 days. Archived memories can re-awaken if they become relevant again. This lifecycle keeps retrieval sharp even as the corpus grows.

The read pipeline: perspective-aware retrieval

This is where iDmem diverges from everything else I’ve seen. The system doesn’t just run a vector search. It builds a retrieval decision combining vector similarity (60% base), gravity (entity importance), tension (conflict density), resonance (topic alignment), recency minus decay, and the per-agent talent adjustment (±0.3 from domain affinity, signal amplification, familiarity boost). That talent adjustment reshapes the relevance surface per agent it’s not a filter, it’s a scoring component.

Epistemic authority: not every voice gets equal weight

This is the newest piece, from mid-March 2026. I realized that in a system where bots and humans both contribute memories, I need explicit rules about what can shape the shared truth.

I introduced three epistemic tiers. Tier A (authoritative) human direct facts, system events, tool-observed states. Can create and supersede current state. Tier B (operational) agent direct reports. Can add new context but can’t override a Tier A fact. Tier C (support) summaries, interpretations, hypotheses. Persists as support_only available for recall but doesn’t move the worldview on its own.

This prevents the circular problem where a bot summarises something, the summary gets re-ingested, and suddenly the bot’s paraphrase becomes organisational truth.

Temporal runtime: change is not contradiction

Another lesson from production: “Mara moved from Marketing to Product” is an evolution, not a conflict. I built a temporal runtime with semantic property normalization, belief modes (single_current vs multi_active), and supersession logic. Previous states become historical, not deleted. When there’s a genuine conflict, the answer layer stays agnostic and explains why.

The operational backbone: 23 maintenance jobs

The system runs 23 automated background jobs on a cron schedule memory tier lifecycle, knowledge graph maintenance, conflict detection, skill pipeline, identity resolution, quality regression tests, and a weekly auto-calibrator that suggests threshold adjustments based on review decisions and feedback. All per-workspace, multi-tenant, with full audit logging.

Why I think this matters

The agentic AI world is moving toward specialization. Nobody wants one generic assistant they want agents with expertise, context, and perspective. But if all agents share the same flat memory with the same flat retrieval, they’re all the same agent wearing different hats.

The missing piece is a memory layer that’s shared (so agents aren’t working on isolated islands) but differentiated (so each agent sees what matters to them). Where the objective record stays clean and auditable, but the subjective reading adapts to who’s asking and why. And where bot-generated context doesn’t silently become the shared truth.

Several lines of research are moving in this direction: shared world plus personal lens, memory as runtime. But most products still flatten everything into one retrieval layer.

I don't know where this is heading. For now it's fun and I keep iterating because it helps me do context-aware retrieval for different agents in my day-to-day work. There are still many things I don't have solutions for. But for me, at the current scale a team of 10 people it works well enough.

more details at idmem.com

That changes how I test things. Ideas I would previously leave at the level of instinct or vague conviction can now be pushed into form, challenged, and either discarded or developed almost immediately. I can kill weak assumptions much faster and get to something functional in a fraction of the time it used to take.

But that is also where the real tension begins, because AI does not just accelerate work. It radically increases transparency.

It opens up areas that used to be gated by expert networks, referrals, and social proximity. In many cases, we were never actually equipped to evaluate those experts directly, so we evaluated them indirectly through outcomes. The problem is that in a lot of fields, outcomes do not reveal themselves right away. In accounting, for example, mediocre or sloppy work may not become visible until years later, during due diligence. The same basic pattern exists across many professions. Even when the feedback loop was not measured in years, it was still long enough that people relied mostly on reputation, trust, and the assumption that the person on the other side knew what they were doing.

A lot of subpar work was accepted not because it was truly convincing, but because there were few real alternatives or it was good enough and the difference would have meant a dispropotionate amount of effort or cost. The best people were either invisible to you or too expensive to access. And the same question always sat underneath the transaction: how do I know this is real? How do I know a document genuinely takes one hundred hours rather than two? How do I know a sprint really needs two weeks rather than two hours with the right tools and someone who actually knows how to think through the problem?

That is where the balance shifts.

People who were delivering mediocre work, fully aware that they were operating close to the minimum acceptable standard, but protected by the client’s lack of access, lack of visibility, or lack of alternatives, now have a real problem. The client is no longer locked out. They have access to the same tools. They can produce a decent first draft themselves. Someone with even a modest amount of cross-disciplinary experience can get surprisingly far, sometimes far enough to build a scalable MVP and put it in the market directly. It becomes much easier to tell the difference between substance and filler.

The core question is no longer simply, how much do you cost? It is: what thinking do you add on top of what the tool can already do?

For a lot of people, that is an uncomfortable question. Because if you are not adding real judgment, real taste, real synthesis, real accountability, then the only differentiator left is price. And price is a brutal place to compete, because costs are not abstract. They are shaped by where you live, how you are taxed, what your obligations are, and what kind of life your environment expects you to sustain. Those are not variables you can endlessly compress. Someone elsewhere may be operating at a fraction of your cost base.

So if the quality of your thinking does not clearly create value, price will.

And that exposes something that has been true for a long time: a significant share of internal and outsourced roles have been underdelivering for years. AI did not create that reality. It simply made it harder to hide behind process, opacity, jargon, or time.

At this point, the options are fairly stark. You either level up in a real way, in the depth of your judgment, the quality of your reasoning, and the value you create beyond raw execution, or you end up in a race to the bottom on cost.

The ironic part is that this, the thing that looks simple, is actually the hardest part. It’s much easier to pile on bells and whistles, do spray-and-pray marketing, or fill the calendar with discovery sessions. Sales conversations and sales strategy would probably be more useful if they focused more on this part, even if it’s boring and moves at a snail’s pace, because that’s where the real work is. The bells and whistles don’t help much here.

Why is it hard? Because there’s a lot of guesswork, lots of small iterations repeated to the point of exhaustion, and an effort-to-reward ratio that can feel brutally bad. By comparison, building a funnel from discovery to closing, or even post-sale, with ten phases for five ICPs and a different tool for every step, is way more appealing. It doesn’t just sound fancy, it is fancy. Pure dopamine.

Metrics, KPIs, reporting. We sit on a lot of data & now we can build tools, APIs, custom dashboards that automate the collection and consolidation we used to do by hand. I am as confident as anyone guessing the future could be that this will show in the business too in a few months, being 6 or 18 🙂 but not because we did anything magical because we did things we simply couldn’t justify before. At our size, spending the $$, time & team effort to buy that kind of capability just did not make sense. We tried every once in a while and realised we just do not have the scale or tools to absorb and have a consistent approach.

For many AI is a foot in the door to a new domain or a new way of doing things, one that used to require a specialist. AI makes this accesibile. it does not enable creating a product or service at market standards, but understanding the domain and toying around, iterating.. The ability to understand it at a macro level, with some effort, and to play within enough to actually learn it through rapid iterations and feedback loops.

I can start with a hypothesis, iterate on it quickly, and turn it into something I can communicate. I can test concepts, even at the intersection of different disciplines where I would previously have needed specialists: design, code, strategy, whatever. This can be done in days, not months, without waiting or imposing on a team to validate a hunch.

anyone who has ever worked on validating ideas knows how painful those processes can be. They’re slow, frustrating, and unclear for everyone involved. The objective is usually fuzzy, it keeps changing, and money gets burned without producing much in the short term. That’s what makes this kind of work expensive and puts pressure on the whole team. Now I can get to a PoC in a matter of days or weeks, without dragging other people into that process too early, and at a much lower cost.

But a PoC is not a market-ready product. The excitement of speed, and the fact that each of us can now cobble together something surprisingly fast, can induce a state of naive confidence. It looks & feels good, but it doesn’t hold up once real pressure hits. If you want something that is actually business-ready, you still end up needing specialists. People with enough experience to anticipate edge cases, spot the critical angles no one has dealt with yet, and design scalable architecture that can hold the same standard no matter how many users you have. So it’s entirely possible that senior people won’t have less work, but more. Or maybe the same amount of work, just of a different kind. More multi-project work, more time spent where their expertise actually creates the most value.

The bigger question is juniors. How do people grow if the first 10,000 hours look completely different?

At the market level, I don’t know. But I can say what happened in our case. All of this gave us much more transparency and much more clarity in the data. Senior people now spend their time where they create the most value, because things are clearer, more actionable, and based on data that updates daily and hourly. We’re no longer working with no indicators, or with monthly lagging indicators. We have the data right now. The lag has been compressed to hours, which means we can act fast and act preventively. A large part of our capacity is now shifting into planning, forecasting, and real-time adjustment.

At the same time, there’s still a very long tail across data, admin, and operations that AI or tools can’t handle on their own. The difference is that this work is now visible, measurable, and clear. And there’s a lot of it. That’s where junior people come in for us. In the past, we wouldn’t even allocate resources there, because it wasn’t clear what needed to be done, and the process for surfacing and measuring that work simply didn’t exist. We even built tools specifically for junior team members, because it’s not enough to just see and measure the work. You also need to give people instruments they can actually use to act on it. Especially at junior level, where the tool, through its flow, doesn’t just guide the person but also teaches them how to work.

Without AI, which gave us the ability to build custom tools, we wouldn’t have been able to do that. We now have two junior people on the team that we probably wouldn’t have had otherwise. Not because the demand wasn’t there, but because we wouldn’t have been able to surface it clearly or give them a working method. So in our case, more things to do, we hired more.

It is still unclear whether these systems are genuinely useful beyond two or three narrow use cases, and whether they can become profitable. I had already sold myself on the business case: productivity, scale, automation. In practice, the gains are modest, they take a lot of time to unlock, and they come with dependencies across multiple layers. They consume time, demand patience and attention to detail, and require daily iteration measured in hours, not minutes.

I spent most of my time on the tooling side, mainly because I already had an internal foundation for financial management, plus a mix of outbound and CRM or, in the language of the current hype cycle, GTM. Some tools are good out of the box, like Notion or Monday. But most of them are not database-first, and they force opinionated interfaces into the interaction model, which creates friction. I built both the GTM/CRM system and the finance app from the database upward: the human agent gets access to a tabelar UI that mirrors the database structure, while the AI agent gets access to raw data & and some of the functions that can manipulate that data directly. There are 2 more UI methods for the human agent to access data & functions

• opinionated UIs

• an LLM chat window

The OpenClaw and CRM interaction demos are not exactly spectacular. But it is honest work. They save a few minutes a day and more relevant perhaps is the mental load, and those matter even more when you are away from your computer.

The architecture I am currently exploring to go forward for a small team of agents has four layers:

1. The orchestrator. An LLM that coordinates the system, decides who comes in and in what order. It handles task routing and policy control. It does not execute. It directs.

2. Specialized agents. Sales, Admin, Finance, People. Each has a clear role inside a small, tightly defined perimeter. Each does one thing well.

3. Deterministic tools. Agents do not operate directly in text. They execute through concrete tools: Sales through the CRM and outbound systems, Admin through project management and docs, Finance through the tracking application. Text is the thinking interface. Execution happens in real systems.

4. The memory layer, a shared pool. A memory layer all agents use so they can understand the world in a shared way and still interpret it differently depending on context. It has two modes:

• Shared World State: entities, events, states, history. What happened, what exists, what is true right now.

• Personal View: each agent’s lens on the same underlying reality. Sales sees a lead. Finance sees a cost. Same contact, different interpretations.

the main question people throw at me: Does it help me in my day to day business?

So I thought I would do a small experiment, I’ve been working with a logistics team on a Value Stream Map. old school, on walls, with post-its and flip charts. Then when data starting piling up we moved things to Miro.

Miro is great, has structure, collaboration, sticky notes, arrows, everything.

Except in a warehouse, you don’t live in Miro. You live between shelves, scanners, phones, and people who have 30 seconds to tell you something before they move on. And Miro isn’t exactly easy. on desktop it’s fine, on a phone in a warehouse it’s... rough. It gets technical fast.

So I pulled out my phone, took a photo of the board, sent it to Kiki (open claw assistant) via Telegram, and told it in Romanian, by voice: make something visual out of this VSM, with a small guide on each step in the flow.

20 minutes later a first view. 1 hour later a unique link, accessible to the whole team, with back-end storage. 3 hours and 8 $ later a site with users, login, responsive, where people can see the flow and input data. (the price does not include the domain for which I paid a bit more)

A Value Stream “app”, not a static poster.

What it actually does:

Each point in the flow is a piece of the process. And on each one you can input — time, execution details, technical specifics, observations. Where it hurts, where people wait, what repeats.

Every person has an account. They input data. And we can see on each point who entered what. It’s not “I think someone did like this” It’s a trace. It’s real collaboration and it’s connected to a google sheet if we need spreadsheet format, the data is already there, ready to use.

Next steps: I want to feed it photos and video for each process step, see how it analyzes them. I want to test if it can estimate cycle times from footage. Send notifications. Automate steps that otherwise need a human operator. invite others in TG to talk to Kiki and help build a better app for them, as they use it and need it, and they know their pain point way better than I do.

What is relevant and I want to emphasise - everything was done through a voice interface, on Telegram, in Romanian language, from a phone.

Could I have done this with other tools? Absolutely. But it was simple, it was actually fun, and 8 dollars doesn’t break the bank.

I used Kimi K2.5 as the model. The difference vs. Opus 4.6: a query to Opus costs on average between $0.05 and $0.80. The same query to Kimi K2.5 between $0.01 and $0.09. It’s slower, not as precise, but it did the job beautifully.

For me this is a concrete example of productivity. You move faster, clearer, and now I can build as many VSMs as I need. The next ones will be cheaper. And I’ll keep adding functionality.

That’s what a hobby is good for.

At that point, Kiki worked, but mostly in the “it responds in a channel” way. The team… wasn’t impressed. Not because they disliked it, but because early agent systems often feel like half-backed Slowly, people warmed up. They started giving Kiki small tasks. Low-risk requests. Things that wouldn’t break a day if they failed.

Kiki has a clothes now

built a small “command center” dashboard that answers the week-one questions to answer some question and because is cool

• Is the gateway up? Is the sandbox healthy?

• Which model is running right now?

• Are channels connected (Slack/Telegram)?

• What’s the daily cost, cache hit rate, and token usage?

• Which sessions are the most expensive (and why)?

• What background jobs are running (watchdog, backups, log rotation)?

• What’s in the task pipeline?

It’s not fancy. It’s just enough visibility to turn debugging from folklore into a checklist.

The first real tasks

One colleague asked for a contract translation, rewritten into a double-sided bilingual format, plus an addendum. Kiki produced a full draft in ~20 minutes, including a few product-specific details we needed in the addendum. this would have taken hours of manual work

That win triggered the next wave: more back-and-forth, more operational requests, more “okay, but can it do this?”

Then another colleague dropped:

“Find tent suppliers. I need phone + email.”

Claude Haiku 4.5 found three suppliers… then refused to continue, claiming it didn’t have web access. Same prompt. Same environment. Different model (Kimi K2.5): ten suppliers with full contact details, formatted cleanly.

What changed in 4 days (Feb 14 → Feb 18)

1) Sandbox

Before: our sandbox was a plain debian:bookworm-slim container. Every recreate wiped tools. Curl, Python, basics. Gone. We logged 574 fetch failures/week.

Now: we baked a custom image: cv30-sandbox:latest with everything installed at build time:

• Python 3.11 + pip

• curl/wget, jq, ripgrep, git

• pandoc, poppler-utils, sqlite3

• gog CLI

• Python libs: python-docx, openpyxl, beautifulsoup4, csvkit

2) Model roulette: “model choice” is workflow choice

What mattered wasn’t “can it call tools”, but “does it chain them until the job is done”.

A good chain looks like:

web_search → web_fetch → verify → extract → format

A bad chain looks like:

web_search → shrug → “that’s all I can find”

Rule: “best at benchmarks” is not “best at being useful at 4:47 PM on a Tuesday.”

3) Before: workspace mounted read-only. Kiki couldn’t write anything back. No persistence.

Now: read-write workspace. Kiki writes:

• tool learnings

• daily observations

• people profiles

Everything is indexed via hybrid memory search (Gemini embeddings + BM25), so Kiki can retrieve the right scraps later.

4) Team access: opened DMs

Before: one Slack channel + my DM.

Now: 12 team members can DM Kiki directly. Each DM is sandboxed. People started using it the way people actually use assistants: privately, casually, repeatedly.

Small change. Big impact.

5) Workflows:

We already had web_search and web_fetch. The problem was behavioral: Kiki didn’t reliably combine them. It would search once, get partial results, and stop.

So we added a small self-learning spine:

1. TOOLS.md
   A playbook of concrete workflows (research, document processing, contact research) plus anti-patterns (example: never claim “no web access” when the tools exist).

2. memory/tool-learnings.md
   A living log of “what worked / what failed / what to try next time.”

3. AGENTS.md (TOOL LEARNING section)
   Rules for self-improvement: check tool-learnings before using tools, log new discoveries, prefer repeatable patterns.

The original bottlenecks, now

From the Feb 14 post, I had six bottlenecks. Here’s the scoreboard as of Feb 18:

Raw stats

The lesson from week one

Shipping the assistant was the easy part. Shipping the workflow brain is where the real complexity lives: hundreds of small rules, edge cases, and operational habits that decide whether the team trusts it.

What’s next

Next we’re pushing on the parts that make the assistant feel like a stable teammate instead of a clever chatbot:

a 3-layer memory architecture (World State, Memories, Interpretations)

This is a big one and working on it a lot, but a very userul one in the long term so that it can really be useful in real world context with tons of information from a bunch of different people.

1. speed up repetitive work (search, summaries, drafts, quick lookups across tools)

2. keep it operationally controllable (self-hosted, small perimeter, observability, clear access rules)

Context: a small team (around 10 people), a shared knowledge base, and no dedicated IT department. Below is the architecture and what I learned, without config dumps or raw JSON.

Setup decisions

• Platform: OpenClaw, self-hosted on a VPS

• Interface: Slack Socket Mode (WebSocket)

• Agents: two agents behind the same gateway (personal + team)

• Isolated execution: Docker sandbox for the team agent

• Memory: markdown files + embeddings + local index

• Integrations: Monday.com, Google Workspace, web search, internal apps

• Ops: watchdog, daily report, backups, log rotation

Two agents, not one. I split “personal chat” from “team agent” to get:

• simple routing (DM vs channel)

• different rules and permissions (stricter for the team agent)

• less context contamination between discussion and execution

Different models. The personal agent uses a fast model for general conversation; the team agent uses a model that behaved better at tool-use. I preferred manual control instead of auto-routing because the auto-router often picked weaker models in practice.

Fallback chain. Each agent has a list of backup models. If the primary is down, the gateway automatically fails over to the next one (Gemini Flash, Qwen, GPT-5, Claude Sonnet, etc).

Session expiry. Sessions reset after 30 minutes of inactivity. Without this, context grows incrementally and eventually things stall.

Current shape (high level)

Important execution detail:

• The team agent runs commands inside a Docker sandbox (workspace mounted read-only).

• Some tools still run on the host. The container is configured in bridge mode so it can reach certain host-exposed capabilities in a controlled way. The goal is separation: isolated execution, practical integrations.

Architecture decisions

Infrastructure: Ubuntu VPS. OpenClaw runs as a systemd service. Slack connects via Socket Mode.

Message routing: the gateway receives all Slack events and routes by channel:

• DM with me → personal agent

• dedicated channel (#team) → team agent

This is intentionally simple: a channel → agent binding.

Docker sandbox for the team agent: commands and execution happen in the container, with a read-only mounted workspace. This reduces the risk that prompt injection turns into “write to disk / modify host state”.

Static curl binary: the built-in fetch tool supports only GET, while Monday.com (GraphQL) requires POST. I solved this pragmatically by adding a static curl binary inside the sandbox (no extra dependencies on the host).

Google Workspace: the agent has a dedicated workspace identity with controlled access. For Gmail specifically: it can read and create drafts, but it never sends without explicit confirmation.

Skills on-demand: I keep instructions modular (“skills”) and load them only when needed. This was the difference between a generic agent and something useful in a real business.

Security decisions (principles)

1) Minimal exposure

• admin access only via VPN (Tailscale)

• public ports closed with UFW

• gateway bound to loopback only

• Fail2Ban for basic access hardening

2) Least privilege

• tight scopes on integrations

• different permissions for personal vs team agent

3) Human-in-the-loop for write

• reads are allowed by default (search, list, summarize)

• writes require confirmation (send email, modify tasks, create docs, etc.)

4) Config integrity

• agents are explicitly instructed to never modify config files (routing, auth profiles, sandbox, models)

• any infrastructure change goes through an internal double confirmation

Monitoring and automated checks (based on real failure modes)

I built this around “what could leave the system dead since Friday night”.

Signals I track:

• whether the gateway is running

• recent log activity (detects “silent” disconnects)

• session size (context growth)

• stuck executions (lots of input, no output)

Automated actions:

• cleanup + restart if sessions exceed thresholds

• restart if there is no log activity for a window

• daily health report

• daily backups for workspace + config

• log rotation

Memory (the decision that changes everything)

An agent without persistent memory becomes a chatbot that forgets. For a team, that means every conversation starts from scratch: who’s who, how you name internal things, what projects are active, what the rules are for email/tasks, what “done” means.

In practice I need memory for two classes of questions:

• Fast context recall: “what’s the status of project X”, “what were the latest decisions”, “what did we agree with client Y”. Semantic search works well here.

• Relational questions (the reason I’m looking at graph memory): “who owns X”, “what depends on Y”, “which tasks are blocked by Z”, “which docs matter for client A”, “who is allowed to approve/send/modify”. Pure vector search becomes approximate here.

Why I’m interested in graph memory

Graph memory explicitly models entities (people, clients, projects, documents, tasks) and relations (owner-of, depends-on, belongs-to, mentioned-in, approved-by). The advantages I’m after:

• Deterministic relation queries (“owner”, “depends on”), not just “most similar paragraphs”.

• Cleaner updates: when an owner/status changes, you update a node/edge instead of adding another paragraph that contradicts history.

• Less duplication: the same entity shows up across many conversations; a graph gives you a single source of truth.

Why I considered mem0 (and why I haven’t adopted it yet)

I looked at mem0 because it aligns with “graph memory”: entities + relations, and a structure that supports “who/what/where/depends-on” queries. In theory, it’s the natural next step once you move to shared memory across multiple people.

What stopped me for now (at our scale):

• Extra infrastructure (often Neo4j as a separate service) and the ops overhead.

• Write overhead: typically multiple LLM calls to extract entities/relations, increasing latency and cost per “add to memory”.

• Isolation model: many implementations are oriented around per-user memory; for a company I want shared memory with clear permissions and provenance.

What I use today (and why)

For now I’m using:

• OpenClaw built-in memory search: transparent markdown files + embeddings + local index (SQLite) with hybrid search (semantic + keyword).

It’s pragmatic: easy to operate, easy to audit, easy to repair, and good enough for ~80% of questions. The plan is to revisit graph memory after 1–2 months of stable usage and tighter discipline around what enters memory (otherwise a graph just structures chaos).

Bottlenecks and issues (what broke and how I fixed it)

• The LLM “described” actions instead of calling tools

  • Symptom: answers like “I would run command X” with no tool call visible in logs.

  • Impact: in the team channel it looked “smart” but nothing actually happened.

  • Fix: better tool-use model for the team agent + explicit instruction (“if you need a tool, call it, don’t describe it”) + a completion check (“done = output exists, not just steps”).

• Context overflow from large responses (APIs returning huge JSON)

  • Symptom: after a few interactions, session size grew to hundreds of KB; the agent became slow or stalled (Slack still looked “alive”).

  • Cause: large raw responses kept verbatim in context.

  • Fix: cap results (e.g., 25 items per query), aggressive summarization, avoid pasting raw JSON; watchdog clears sessions over a threshold (e.g., 500KB) + session expiry after 30 min of inactivity.

• Slack Socket Mode “silent” disconnects

  • Symptom: gateway reported “connected” but messages stopped arriving.

  • Fix: 5-minute watchdog checks for recent log activity; if no new logs within a window (e.g., 15 minutes), it triggers a controlled restart.

• Upgrade broke sessions / compatibility

  • Symptom: after an upgrade, conversations started hanging immediately.

  • Fix: rollback to the last stable version + version pinning; upgrades only after testing in a separate environment (staging) or during an accepted-risk window.

• HTTPS failed inside the sandbox (missing CA certs in slim images)

  • Symptom: HTTPS requests from the container failed with certificate errors.

  • Fix: install/copy CA certificates into the container and set environment variables where needed (e.g., SSL_CERT_FILE).

• Environment variables didn’t reliably inject into the container

  • Symptom: commands worked sometimes, then returned 401/403 because env vars were missing.

  • Fix: explicit inline exports in commands + preflight checks in the sandbox (printenv) before sensitive calls.

• Built-in web_fetch didn’t support POST (Monday GraphQL)

  • Symptom: couldn’t call GraphQL endpoints with GET-only tooling.

  • Fix: static curl inside the sandbox and controlled POST calls.

Questions for others running agents for teams

1. How do you do shared memory across multiple people without turning it into chaos?

2. How do you manage permissions and write actions (confirmations, auditability, rollback)?

3. Self-hosted vs SaaS vs hybrid: what hit you the hardest in production?

Traditional CRMs are applications with predetermined UI & flows. I’m exploring the inversion: a well-governed database with an LLM layer that can generate interfaces, flows, functions, and agents on demand.

A database with a shape shifting CRM.

The Problem with CRM-as-Application

Most CRMs I’ve used ship with pre-designed screens. Those screens aren’t process flows, but they have a habit of becoming one. Over time, the UI turns into policy.

That works for the happy path. It breaks on edge cases.

And in real sales orgs, edge cases aren’t rare. They’re the daily reality: hundreds of micro-tasks, exceptions, handoffs, and one-off situations that don’t fit the vendor’s mental model of “the pipeline.”

The human adapts to the tool instead of the tool adapting to the work. And experimentation suffers. You don’t iterate your process, you work around the software.

When I need something slightly different, a specific view, a micro-automation, a report that cuts across predefined objects, I’m either fighting the system or paying for “enterprise customization.”

The Alternative: Data First, Interface Fluid

I’ve been building something different.

Not “raw database as UI,” but a grid-first interface that’s isomorphic to a well-designed schema: views, filters, bulk edits, stable primitives. The data model is visible and manipulable, not hidden behind opinionated screens.

Here’s the architecture as I currently play with it.

1) Data Nucleus

The foundation is a data structure: schema, relationships, and an event log.

Entities like contacts, companies, deals, interactions, touchpoints, and the connections between them. This layer is the source of truth. Every change is logged as an event.

The goal is not a perfect ontology. The goal is a stable substrate that can evolve without turning into a junk drawer.

2) Execution Layer

On top of the nucleus sits an execution layer: deterministic tools that do exactly what they’re told.

Typed primitives like:

• create

• update

• link

• log

• merge

• enrich

• notify

This is where permissions, policies, invariants, and guardrails live. Predictable operations that can be tested, audited, and trusted.

3) Interface Layer

Multiple ways to interact with the same data, depending on the user and the task.

Grid-first views (baseline UI)

For many sales operators, the fastest interface is still table-shaped:

• filter, sort, group

• bulk edit

• select a working set and run actions on it

• scan for anomalies

This is “DB as front end” in the practical sense: a stable, learnable surface that maps cleanly to the underlying model.

Generated UIs (task-specific)

On demand, the system can generate context-specific screens for particular workflows:

• renewals cockpit

• inbound lead triage

• enterprise deal room

• partner onboarding

• SDR daily queue

These aren’t permanent application screens. They’re interface manifestations: purpose-built compositions of a stable component library (grid, record panel, timeline, wizard, dashboard).

Stable core, generative edges.

Conversational interface (fast queries + commands)

For certain operations, natural language is simply faster than clicking:

• “Show me all accounts with renewal in 60 days, usage down 20%, and an open support ticket.”

• “Draft follow-ups for the top 30, but only for stakeholders I’ve emailed before.”

• “Find duplicates of this company and propose a merge plan.”

This is also where semantic search and fuzzy matching shine: not just text, but meaning and similarity.

Example: Renewal risk in one flow

I ask:

“Show me accounts with renewal in the next 60 days, declining usage, and recent unresolved tickets. Group by owner and sort by ARR.”

The system generates a working set in the grid. I can bulk-tag, reassign, or create tasks.

Then I ask:

“Propose an outreach plan for the top 20, using our last call notes and open ticket context. Flag any accounts where we don’t have an executive sponsor.”

The LLM drafts a plan. The system turns that into typed actions. I approve the high-stakes ones. Everything gets logged.

That combination is what I’m after: speed without chaos.

4) Canvas Layer: the system map that stays current

Multiple screens solve the “doing” problem. But I also need to see the whole system: how pieces connect, where data flows, which agents handle what, and where humans are in the loop.

That’s where a canvas layer comes in. Not as another execution tool, but as a visualization and thinking space.

Picture an infinite canvas (Miro-style) where the LLM continuously represents and updates:

• end-to-end business flows

• how data entities connect to processes

• which functions and agents handle which steps

• where humans are in the loop vs where automation runs

• handoffs, failure modes, and alerting points

The canvas doesn’t command the backend directly. It’s where I design, discuss structure, and refactor workflows. When I sketch a new flow or restructure a process, the system figures out how to implement it in the execution layer and then updates the map to reflect reality.

A shared mental model, kept alive.

LLM Proposes, Tools Execute

At this point it’s tempting to say: “the LLM operates on the database.”

But that phrasing hides the most important design constraint: trust.

In this architecture, the LLM doesn’t mutate business-critical data directly. It proposes plans.

It suggests which primitives to call, in what order, with what parameters. Then deterministic tools execute those plans.

This separation is what makes the system usable in a real org.

A typical flow looks like:

1. A request is made (UI or natural language)

2. The LLM produces a typed plan (a structured set of actions)

3. The plan is validated against permissions and invariants

4. The system shows a preview: what will change, and why

5. Execution happens through deterministic tools

6. Everything is logged: request, proposal, approvals, execution, outcomes

For low-stakes operations, approval can be automatic. For critical operations, I review the plan before execution.

The LLM brings intelligence. The execution layer brings reliability. They stay separate.

A wild speculation: onboarding as strategy work

Imagine guided templates that walk someone through:

• defining positioning and business model

• clarifying products and pricing

• building an ICP derived from the above

• mapping channels and discovery mechanisms

• designing inbound/outbound strategies

The user experiences it as strategic clarity work, which it is. But they’re also populating a structured data model. At the end, they get both: a clearer strategy and a working system.

The schema emerges from the strategy conversation, not from configuration screens.

And the canvas grows alongside it, visualizing what they’re building as they build it.

Imagine having visibility across

• business model and market positioning

• products and pricing

• ICP derived from all of the above

• channels and discovery mechanisms

• inbound/outbound strategies

• enrichment and contact workflows

• leads and pipeline stages

• signals and alerts

• custom dashboards and real-time reporting

Not as separate tools stitched together, but as one coherent system: data model as foundation, multiple interfaces for operations, and a canvas layer to see how it all connects.

Other things to be solved

Schema governance. “Well-defined database” sounds clean. In practice, business ontologies are messy. They evolve. They contradict themselves. Governance needs to feel like shipping code: proposed, reviewed, versioned, migrated.

Muscle memory vs adaptability. Users develop reflexes. They know where the button is. If the UI shifts too much, predictability disappears. My current hypothesis is stable core views plus generative edges, but I haven’t proven the balance.

Trust UX. Mechanisms like plans and audit trails are necessary, but not sufficient. The user experience of trust matters: previews that make sense, sensible risk thresholds, and clear explanations when the system refuses to execute.

Cost of abundance. Custom UIs per user, dedicated agents per task, functions generated on demand. Inference costs and maintenance complexity can explode. There needs to be a notion of budgets, reuse, caching, and composable components.

The question I’m sitting with

Is this a product or a way of working?

The companies that need flexibility often lack the discipline to govern it well. The companies with that discipline already have deep investments in Salesforce or HubSpot, plus inertia.

Maybe onboarding-as-strategy-work is the unlock. Lower the barrier by disguising system setup as business coaching.

Or maybe this is infrastructure I build for myself, and the advantage is simply operating differently from competitors who are stuck in application-shaped boxes.

What’s your experience with CRM flexibility vs structure? Have you seen systems that successfully balance fluid interfaces with operational reliability?

Questions are worth asking even if the answers do not lead to tidy solutions. This is one of them: what does re-skilling actually cost when you’re mid 40s, with a family, a mortgage, and a life you’ve spent twenty years building?

I’m 45. I run a company that works with 18-25 year-olds. We help them find opportunities & make choices during the years when their identity is still forming.

Lately the conversations have shifted. This essay is what I’ve been thinking about. It’s messy. I don’t have clean answers. But the question feels important enough to write it down.

Back to School, Mid-Career

It’s 9:47pm.

Kids are finally asleep. The kitchen is almost clean. Your brain is half-melted from meetings, decisions, and explaining the same thing three different ways to three different people who were technically in the same meeting.

You sit down with that familiar thought: “Okay. One hour. I’ll test that thing.”

That thing is always different. A new model. A new workflow. A new tool that claims to do 60% of your job faster. A new “best practice” that didn’t exist two weeks ago. A hype cycle disguised as a revolution, or worse, a real revolution disguised as a tweet.

And the clock is already negotiating against you.

This is what the AI era feels like for a lot of people: a flywheel with a snowball effect. Everything now demands faster, more frequent updates.

Not just learning new features. Learning new ways of working, in cycles of de-learning and re-learning, testing tools, and constantly separating signal from hype. Even if your company isn’t pushing you, the market is.

The old career deal

For a long time, there was an implicit deal most people lived by:

More experience becomes seniority. Seniority becomes higher output and better decisions. Higher output becomes optionality. Optionality becomes time.

Not immediately. But eventually.

Over the years, you buy back more of your life: family time, health, weekends that don’t feel like a second job. You also carry more responsibility as you age, but the ratio improves. You’re supposed to get better at the job and the job is supposed to give you back some oxygen.

That deal is being rewritten mid-game.

Not because AI will “take all jobs” tomorrow. The bigger disruption for many careers is that AI increases the speed of the game and forces reskilling at an age where reskilling is socially and cognitively expensive.

The shift: what becomes scarce

As AI lowers the barrier to entry for many knowledge tasks, the scarce resource shifts.

It’s not information. Information is abundant.

It’s not even raw capability, because capability keeps getting packaged into simpler interfaces.

The scarce resource becomes uninterrupted attention. Time you can actually use to iterate, test, and build judgment. Time that isn’t fragmented into tiny context switches. Time that allows you to run the loop properly.

Because the loop is the game.

The loop

Strip away the branding and the debates and the hot takes and you end up with the same learning cycle in every domain:

idea → test → feedback → iterate

That loop is how people get good. How teams improve. How products become real. How strategy stops being a belief and becomes something grounded.

Historically, the loop was slow and expensive. You needed years to write well, design well, analyse without lying to yourself, communicate clearly, persuade, coordinate, prototype. The friction was and still is real.

AI compresses parts of that friction. It doesn’t make everyone an expert overnight. But it makes it easier to express ideas, explore variations, prototype, summarise, translate, simulate, and compress the distance between “I have an idea” and “I can try it.”

So more people can run more of these cycles faster. AI isn’t just a tool. It’s an accelerator for iteration velocity. And once iteration velocity goes up, everything else gets re-priced: job roles, career trajectories, status, credibility, competition, and the time you thought you’d earn back with seniority.

The second disruption: most people don’t want to run the loop themselves

Here’s a complementary truth that matters just as much as speed: Most people don’t want to pioneer.

They want predictability. They want the walked and battle tested path. They want to learn from the best, from the people who took the high road first, or from their followers who had the time to codify the doctrine into something teachable.

That’s what a course really is, whether it’s 10 hours or 18 months. It’s not just content, it’s a promise: “This has been proven. If you do this, you’ll get there.” This is how most learning has worked for decades:

• a few people explore chaos

• then patterns stabilise

• then a playbook emerges

• then the majority follows a cleared, predictable road.

It’s not cowardice. It’s rational.

People have families. Bills. Social roles. Reputations. They can’t afford unlimited uncertainty. They can’t be wrong in public too often. They can’t gamble months of attention on unproven paths.

The problem is that AI is accelerating the loop faster than doctrine can form. The map is being redrawn while you’re still trying to read it.

“Best practices” expire. The “clear path” arrives late, and when it arrives it’s already partially outdated.

So the AI era doesn’t just demand more learning. It demands a different relationship with uncertainty: more self-directed experimentation, more ambiguity tolerance, more willingness to be temporarily wrong.

That’s an identity shift, not just a skill shift.

Why this hits mid-career differently

Up-skilling and continuous learning tends to decline after 25 across industries and geographies. Not because people get lazy. Because life fills up.

At 25, you can throw time at learning. Your identity is still flexible. Your social circle expects experimentation. Failure is annoying, but socially survivable. You have runway.

At 40, you don’t just have less time. You have more commitments tied to stability: mortgage, kids, parents aging, a professional identity that took years to build, a social role in multiple networks.

Re-skilling mid career isn’t just learning. It’s identity work. It’s renegotiating who you are, what you’re good at, and what you can credibly claim. And that process is taxing even when it goes well.

So when AI pushes loop speed up, it doesn’t pressure everyone equally.

Four people in the same economy

I’ve been thinking in four archetypes, not because humans are boxes, but because patterns help.

Person A has real experience. Maybe they’re a manager in a big company. They have judgment, networks, domain depth. They know which questions matter and which signals are fake. They also tend to prefer proven playbooks because their risk budget is constrained.

Person B has less experience, but they have something else: time. Fewer dependents, fewer constraints, more cognitive runway. They can run a lot of cycles. They can afford to be wrong more often, publicly and privately, and still recover.

Person C has experience like A, but also has the mindset and selective reskilling required to leverage AI strategically. They don’t chase everything. They pick their bets. They build small experiments into a life that still has responsibilities.

Person D has experience too, but they’re not wired for constant experimentation and rapid iteration. They thrive in stability and structure. They can go deep and maintain quality. The AI era can feel like it’s forcing them into a cognitive mode that doesn’t match their temperament. That’s not a moral failing. Different strengths exist.

On paper, B can run far more cycles than A.

But cycle quantity alone doesn’t determine outcomes. Quality matters. And A has something hard to copy quickly: judgment about what matters.

A knows which questions are worth asking, which metrics are signal vs noise, which feedback is relevant vs distraction, which iterations are worth pursuing.

That judgment is valuable. AI amplifies it. It doesn’t replace it.And yet, here’s the uncomfortable part.

Person A doesn’t actually have 10 hours per week for experimentation. That’s aspirational thinking.

Person A has:

• operational demands that consume the day

• meetings and decisions and context switching

• family obligations that start the moment work ends

• extended family care (children, aging parents, logistics)

• depleted bandwidth from decision fatigue

So while A might be smarter in what to test, they have less oxygen to run the loop.

Finding 10 hours/week for real experimentation (not just staying informed, but testing and iterating) becomes quite hard.

Meanwhile, Person B does have the time. And in 12–24 months of intense cycles, B can develop practical judgment that used to take years in slower environments.

Person C exists, but is rare, because balancing real responsibilities, real stability, and real experimentation without burning out is a knife-edge act. Many people who claim to be Person C are sprinting themselves into burnout and calling it optimization.

Person D faces a different risk: forcing a temperament mismatch. Tools can increase leverage, but they don’t change who you are. If your strength is depth and reliability, a culture of nonstop experiments can become slow identity erosion.

The hidden cost: volatility and social identity

The part that doesn’t get discussed enough is the social and familial cost of participating in acceleration.

This isn’t a neat corporate up-skilling course where your employer gives you 20–40 hours and you walk away with a certificate.

It’s closer to being back at university, except you’re doing it while managing a job, a family, and a reputation.

Reskilling at this level demands repeated reframing. It demands being bad at something again. It demands testing things that may fail. It demands tolerating uncertainty without guaranteed rewards.

And that has identity consequences.

A 25-year-old can pivot, experiment, fail, recover. Their identity is expected to be fluid.

A 40-year-old pays a higher volatility tax. The social contract they were sold (learn, work hard, gain stability, optionality arrives with time) is being rewritten mid-game.

Some costs can’t be compensated:

• a marriage strained by obsessive reskilling doesn’t automatically heal with higher income

• kids don’t get those years back

• networks don’t always reward visible instability

This is why just keep learning is not serious advice unless we talk about trade-offs.

Because the real constraint isn’t motivation. It’s time, attention, and the fact that most people don’t want to pioneer. They want a paved road. They want doctrine. They want something battle-tested enough that the effort has a predictable payoff. And AI keeps moving the finish line faster than doctrine can form.

So what’s the actual answer?

Not everyone must become Person C. That’s survivorship bias and, frankly, unrealistic for many people with real constraints. Maybe a better answer is strategic selectivity and explicit trade-offs.

The goal isn’t to keep up with everything. The goal is to compound in the right places.

If you’re closer to Person A

You don’t need 100 experiments. You need 5–10 exceptionally well-chosen ones.

Use your network to validate faster instead of grinding alone. Identify the 20% of AI capabilities that 10x your existing leverage and ignore the rest. Stop trying to “stay updated” in a general sense and focus on staying dangerous in the few places that matter for your role.

Most importantly, treat the social cost as real. Discuss it. Make conscious choices about acceptable volatility. If you’re going to take time from somewhere, don’t pretend it’s free.

If you’re closer to Person B

Your advantage is runway, but runway can turn into noise if you confuse activity with progress.

Expect that most cycles won’t work. That’s fine. But build systems that force feedback and real-world constraints. Seek mentorship or frameworks that compress judgment, not just skill. And build networks while you build competence, otherwise you may end up strong but isolated.

If you’re closer to Person C

You’re balancing on a knife’s edge.

Strategic re-skilling is not “learning everything.” It’s ruthless prioritisation. Your biggest risk is believing you can sustain this pace indefinitely. Watch for burnout like you watch for bugs: early detection matters.

If you’re closer to Person D

Be honest about fit.

If forcing yourself into constant experimentation makes you miserable, don’t moralize it. Consider roles where stability and depth are valued, or partner with B/C types and delegate the acceleration layer. Some people will thrive by being the anchor, not the speedboat.

The uncomfortable truth

Not everyone will successfully navigate this transition. And the cost of trying, in family stability, mental health, and identity, may exceed the benefit in certain paths.

This isn’t doom posting. It’s acknowledging reality, because pretending everyone can just “work smarter” or “find the time” seems to me a bit dishonest.

So I’ll end with the questions I actually care about:

• What’s your system?

• What do you protect?

• What do you stop doing?

• And what do you intentionally ignore?

Each new wave forms a “partnership” with a certain category of people, augmenting them and giving them an edge. And that fit is not only about education. It’s also about temperament, habits, and the kinds of problems you naturally enjoy solving.

The Partnership Pattern

Writing and record-keeping elevated people who thrive on precision and structure: scribes, accountants, administrators. Power shifted toward those who could maintain archives and govern through documents.

Printing favored a different profile: people who could formulate ideas clearly and spread them widely. Editors, teachers, and reformers gained leverage because messages became cheap to reproduce and distribute.

The software revolution (PC, web, mobile) raised the builders: those who love systems, logic, and debugging, and who can create things that scale. Once distribution became global, a small number of people could build products used by millions, and financial status reorganized around those who built the digital infrastructure.

Social media rewarded another archetype: the curator and the performer, people who understand attention, narrative, and cadence. Influence became a direct asset: measurable, tradable, monetizable.

What’s different this time?

AI is the fastest-rolling technological shift we’ve seen, and the easiest to interact with.

What can be simpler than a tool you can speak to in natural language, that can understand what you mean and help you get there?

Access is unusually broad, the learning curve is low, and the gap in impact between specialists and non-specialists may be smaller than in past revolutions.

AI as a translator of the implicit

The deeper breakthrough is not just speed. It’s that AI can act as a translator of the implicit.

For decades, the bottleneck of human wisdom has been turning tacit knowledge, the intuitive expertise earned through years of trial and error, into something organized and shareable. Many people have insight. Far fewer have the time, training, or medium to convert it into coherent output.

AI can help close that gap.

AI doesn’t just generate text. It helps convert lived experience into usable structure.

With AI, an older person who barely uses a computer can dictate and iterate with their voice to write an article, or even a book. There are millions of untold stories locked inside people who never had the practice or the right environment to put them into words.

And beyond stories, there are models.

Someone who has moved across roles and industries carries mental frameworks others don’t notice: how incentives really work, where teams silently break, why certain processes fail in predictable ways. AI can help pull those frameworks to the surface and turn them into something usable faster: management models, better processes, more nuanced products.

The new archetype: the experiential synthesizer

In that sense, AI doesn’t partner with a single skill-based archetype like past revolutions did.

It partners with the experiential synthesizer: the person, of any age or background, who carries lived experience, tacit knowledge, and hard-won judgment.

The leverage shifts from the mechanics of execution (coding, writing, designing) to the discernment to ask the right questions, provide precise context, and guide the output. AI amplifies articulation and synthesis, turning latent wisdom into tangible value.

So the new divide may not be between those who can or cannot access the tool.

It may be between those who can feed it with insight and those who cannot.

A democratic tool, an uneven world

Still, an asymmetry remains. If AI is democratic in access, why would it produce a divide at all?

Because the raw material it amplifies, varied experience, exposure to different domains, time for reflection, is itself unevenly distributed. AI does not create judgment; it reveals and scales it. And if judgment is shaped by opportunity, then AI may amplify existing asymmetries as much as it disrupts them.

The question is not only whether AI democratizes tools, but whether our societies will democratize the experiences that make those tools transformative.

Where this might lead

In the end, the story may be less about machines replacing people and more about removing friction between what humans know and what they can express.

When expression becomes cheap, the scarce resource becomes judgment, and the depth of lived experience behind it.

If that’s true, what should we do next: invest in teaching people to use AI, or invest in giving more people the kinds of experiences that build better judgment in the first place?