follow kernels for AI teams
Why AI teams should learn from their best people
Follow kernels can help teams share proven AI working habits without forcing people into a static playbook. Here is why that matters in companies.
Why this matters much more inside a company
The strongest version of this idea is probably not solo use. It is team use. Inside a company, the same mistakes are often corrected again and again by the same senior people. A lead repeats the same review comments. A staff engineer repeats the same warnings about logging or rollout risk. A strong product leader repeats the same advice about demand, scope, and decision quality. New people take time to absorb those standards. Teams also carry important habits that almost never get written down well. The result is friction, inconsistency, and wasted time. A follow kernel is useful because it does not try to replace judgment with a frozen manual. It lets proven working habits travel into real sessions when they are actually needed.
What a follow kernel changes
A normal team handbook is static. A Notion page is usually ignored after the first week. A prompt template is too broad. A follow kernel is different. It carries a small layer of proven rules from one trusted person to another user's sessions. That means the useful part of someone's experience can reappear in the next person's work. Not as a giant memory dump. Not as surveillance. Just as a compact layer of guidance that has already been earned through real corrections and real decisions.
Use case 1: a junior follows a senior
This is the easiest case to understand. A junior developer or operator can follow the kernel of a senior whose judgment they trust. The value is not hero worship. The value is practical transmission. The junior can inherit proven reminders around review quality, logging discipline, safe scope, smaller diffs, or release caution. Instead of learning those lessons only after making the same mistake three times, the session can surface the relevant rule earlier. That shortens the path from correction to habit.
Use case 2: a squad follows the kernel of a staff engineer
Teams often want architectural consistency, but they do not want to stop every decision for a review meeting. A staff engineer usually carries stable principles: do not add new surfaces before demand is clear, prefer the simplest path first, make publish errors visible, avoid hiding complexity under helpers too early. A follow kernel can turn those principles into something more alive than a wiki page. The squad does not receive a giant doctrine. It receives small reminders at the moment where a choice is actually being made.
Use case 3: product teams follow a strong PM or CEO
This idea is not only for code. Product teams often struggle with repeated drift: opening too much surface too early, building before demand is clear, changing the message too often, or mistaking activity for proof. A strong PM or CEO usually repeats a few core corrections. Validate demand. Keep one angle. Reduce surface before adding more. Show proof, not just intention. A follow kernel can help those patterns travel into the team's daily work without forcing everyone to read a long strategy memo every morning.
Use case 4: managers follow a kernel of leadership habits
Leadership also has repeatable patterns. Better meeting preparation. Clearer feedback. Better escalation. Cleaner decisions. More explicit tradeoffs. Those things are often taught informally, which means they are learned unevenly. A leadership kernel could help managers keep stronger habits in preparation, arbitration, feedback, and team steering. That is interesting because it shifts AI from being only a production tool into something that can support judgment at the management layer too.
Why this can be better than another internal knowledge base
Most companies already have too much written guidance and too little live transmission. A follow kernel does not try to become another dead repository. It works better when it stays narrow and alive. Instead of publishing everything, it carries forward the small set of rules that have already proved useful in real work. That makes it easier to trust, easier to use, and easier to keep current. The value is not volume. The value is proven density.
The three guardrails that keep it healthy
First, do not follow too many kernels. If people follow too many voices, the product becomes noisy and political. Second, follow by clear axis. One kernel for code quality. One for product framing. One for leadership. Not eight random people at once. Third, never position this as surveillance or HR scoring. The value is transmission of expertise, not control. If it turns into monitoring, the product becomes toxic very quickly.
What makes Temet different here
Many tools store context, preferences, or documentation. Temet is trying to do something more specific. It does not just keep context. It helps useful expertise move between people or agents in a controlled way. That difference matters. You are not sharing a raw transcript. You are not publishing your whole history. You are circulating a proven layer of judgment, with local control and selective exposure. If that works well, it can make teams more coherent without making them more rigid.
Start here
Start with your own agent first
The easiest way to understand this idea is to start with your own agent. Let Temet observe real work, keep the useful habits, and make the first improvements visible. Then learning from someone you trust will feel concrete instead of abstract.
Step 1
Copy the prompt from the landing page
Use the same onboarding flow as the homepage to connect Claude Code, Codex, or your current agent with one clear prompt.
Step 2
Read the Temet method
See the machine-readable docs and the real HTTP surfaces your agent uses when it connects and starts learning how you work.
FAQ
Does this replace team documentation?
No. It works best as a complement. Documentation explains the official picture. A follow kernel carries the small set of proven habits that help in real work.
Could this become too political inside a company?
Yes, if too many kernels are followed or if the purpose is unclear. The healthy version stays selective, focused, and tied to expertise rather than status.
Is this only useful for engineering teams?
No. It can also help product, editorial, operations, and management teams wherever strong working habits are repeated and worth transmitting.
Why is this better than a static prompt?
A static prompt tells people what someone thinks matters. A follow kernel can reflect what has already proved useful across real sessions and corrections.
Next step
Use this guide in practice with Temet's audit, tracking, and profile workflow.
Connect your agentPublished March 27, 2026