ai agents 101
-1 to 1 on agent maxxing!
—hiring—
browse the job posts, and if any look like a match for you, just reply to this and if relevant i’ll make an introduction. everyone is hiring for swe’s
supply chain and logistics platform connecting public and private schools to fresh breakfast and lunch for students, cooked and delivered by local chefs.
stealth - seed
ai operating system for the $150b home care industry.
—housekeeping—
recent stats show more than 40% of readers read the substack
but don’t subscribe?
why?
doesn’t make sense!
wrapper vs. agent
most people using ai right now are not using an agent.
they are using a wrapper.
and the difference matters more than almost anything else in this conversation.
a wrapper is a ui layer on top of an api.
you type something.
it responds.
the session ends.
there is no memory.
there is no autonomy.
there is no persistent understanding of who you are,
what you are building, or what happened yesterday.
a wrapper is a tool that forgets you the moment you close the tab.
an agent is fundamentally different.
an agent has memory. it has tools. it has context that persists across sessions.
it does not just respond to you.
it acts on your behalf
always within the constraints you define ,
with an understanding of your work that deepens over time.
the distinction is not semantic,
it determines whether ai is a novelty you interact with briefly,
or an extension of how you think and work.
elif5
strip everything down to the simplest version
an ai agent is a personal executive assistant that learns.
not a chatbot. not a search engine. not a fancy autocomplete.
it handles the repeatable.
the mechanical.
the administrative.
the drafting.
the scheduling.
the first pass on research. the boilerplate. the formatting. the sorting. the filing.
the things that consume hours and require no real judgment.
and it gets better over time because
it remembers what you told it,
learns your preferences,
and builds up an understanding of your work.
you do not need to be an engineer to start.
a good place to start:
install claude code.
write a claude.md.
describe what you do,
what you are working on,
what matters to you.
start using it for real work, not toy experiments.
let it learn.
go further: set up obsidian as your local knowledge base.
start building a personal wiki.
document your projects, your decisions, your patterns.
feed that into your agent’s context.
let it compound.
the complexity is what would personlize your agent for you.
the foundation is accessible to anyone willing to spend an afternoon setting it up.
the gap between people who do this and people who do not will compound faster than any previous technological advantage.
not because the tool is magic. but because leverage always compounds for the people who actually pick up the lever.
great resource to structuring obsidian and claude code
the death of “vibe coding”
karpathy coined the term “vibe coding”.
it captured the feeling of working with ai
less typing, more directing, trusting the model to fill in what you meant.
but the term has become a liability. “vibe coding” implies looseness.
imprecision.
aesthetic over rigor.
it makes the work sound casual.
what is actually happening is agentic engineering, and the difference is massive.
we have evolved through three distinct eras:
-prompt engineering (crafting individual prompts),
-context engineering (optimizing what goes into the context window through .md files),
-and now agent engineering (designing specialized, reusable, efficient ai agents).
there is no “official documentation” on this so this is my definition of it
it’s the discipline of designing systems around agents.
writing markdown specifications.
defining structure and guardrails.
sequencing tasks through orchestration layers.
reviewing outputs.
tightening the loop when agents drift.
making sure the final result reflects real product judgment.
the developers who get 100x more from agents are not writing better prompts.
they are building better systems around the agents.
“vibe coding” gives permission to be sloppy. “agentic engineering” demands rigor.
in practice, the work i do at lora looks like this nothing like vibes.
i write markdown specs,
define agent roles,
set up orchestration layers,
run multiple claude instances in parallel (until my poor m3 mac gives up),
review and tighten,
push to prod. the leverage is real. the work is hard. the output is 10x. but none of it is casual.
the harness
on march 31, 2026, a security researcher found that claude code’s entire source had leaked via a source map file in the npm registry.
512,000 lines of typescript. 1,900 files. the entire agent harness was public.
some people focused on the security failure. (well it was a big one)
the more useful reaction was studying what the harness actually looked like.
and the key revelation was this
roughly 40 percent of what makes claude code good is not the model.
it is the harness
the engineering layer between the model and the world.
parallelism systems.
permission management.
memory compaction.
a 4-type persistent memory architecture.
a 5-layer config hierarchy.
tools for filesystem access, git operations, web search, and shell execution.
a 7-stage bootstrap pipeline that initializes the agent before it writes a single line of code.
this is what most people miss when they evaluate ai tools.
they test the model. they rarely test the harness.
but the harness is what turns a language model into an agent.
without it, you have a very smart entity with no hands, no memory, and no idea where it is.
the leak was embarrassing for anthropic (again my opinion not theirs) from a security standpoint.
but it showed exactly what “agentic engineering” means in practice
not better prompts, but better infrastructure around the model.
read garry tan on the harness philosophy: “thin harness, fat skills.”
giving your agent a second brain
in early april , karpathy revealed a significant shift in how he uses llms.
he is spending less time generating code and more time building personal knowledge bases
structured, interlinked markdown wikis that an llm compiles and maintains.
the architecture is surprisingly simple.
three layers:
-raw sources (documents, notes, transcripts),
-llm-compiled markdown pages (cross-referenced wiki articles),
-and a schema file that maps the structure. instead of retrieving and re-synthesizing documents on every query like traditional RAG, the llm “compiles” them once into persistent wiki pages, then reads from the compiled layer at query time.
karpathy published the full architecture as a github gist. he calls it LLM Wiki.
the obsidian community adopted it immediately.
the underlying insight: ai does not replace thinking. it replaces forgetting.
karpathy’s shift reframes the llm as a librarian.
a compiler of knowledge. a system that takes the mess of your intellectual life
notes, documents, conversations, research and organizes it into something an agent can actually use.
obsidian is the natural substrate for this.
local-first, markdown-native, no vendor lock-in,
functions as both the human interface and the agent’s knowledge layer.
learn how to build your second brain
memory as infrastructure
if the second brain is the knowledge layer,
memory is the behavioral layer.
most ai tools have no memory.
every conversation starts from zero.
you explain who you are, what you are working on, what you tried yesterday,
what failed. then you close the tab and the slate is wiped clean.
this is the fundamental limitation of stateless ai.
it can be brilliant in the moment and useless over time.
honcho, by plastic labs, is the most serious attempt to solve this.
it is a memory engine for agents —
currently SOTA on LoCoMo, LongMem, and BEAM benchmarks. the fastest, cheapest, and most token-efficient memory solution currently available.
the key insight from honcho’s architecture is the difference between stuffing 100,000 tokens of raw history into context versus giving the agent 10,000 tokens that actually matter.
memory is not about storing everything.
it is about surfacing the right things at the right time.
continual learning, not infinite context.
when your agent has real memory, something changes.
it stops being a tool you use.
it becomes something closer to a partner that knows your patterns, your preferences, your history, your blind spots. the relationship compounds.
an agent with memory is categorically different from an agent without it,
in the same way a colleague who has worked with you for a year is different from a stranger you just met.
https://blog.plasticlabs.ai/blog/Memory-as-Reasoning
read plastic labs’ blog on memory as reasoning.
the practical stack
there are multiple ways to build an agent stack.
these are the most serious options right now
and more importantly, how to configure them.
if you are going to use one tool and nothing else,
make it claude code.
not cursor. not copilot. not a browser-based chat window.
claude code is the terminal-native agent that runs locally, has full filesystem access, understands your codebase,
and operates as an autonomous engineering partner rather than a suggestion engine.
the setup matters. more than the prompts, imo.
most people install it and start prompting immediately.
that is like hiring someone brilliant and giving them no context about the company, the codebase, the conventions, or the goals.
they will produce output.
the output will be mediocre.
and the user will conclude the tool is overhyped.
the real setup starts with claude.md.
it sits in your project root and tells the agent who it is working for, what the project is, what conventions matter, what to avoid, what the architecture looks like.
it is the single most important file in your entire development workflow and most people either skip it or write three lines and move on.
the config hierarchy matters too.
five layers
-global settings
-project-level claude.md,
-directory-level .claude files,
-session context,
- in-conversation instructions.
each layer scopes the agent’s behavior more tightly. when these are set up correctly, claude code does not need to be told the same thing twice.
it just knows.
a quick note on claude code vs claude cowork
this confuses people.
claude code is the local terminal agent.
it runs on your machine with full filesystem access and full autonomy within the permissions you set.
claude cowork is the cloud/async variant,
designed for teams and longer-running tasks you want to fire off and come back to.
both are powerful, but if you are a solo builder running the entire stack,
claude code is the one.
faster, more intimate with your codebase, tighter feedback loop.
the tooling landscape
beyond claude code, two other options deserve attention.
openclaw -hermes agent (-the better openclaw)
yes i said it (also take your pick)
it takes a fundamentally different approach.
it is open-source, multi-platform (telegram, discord, whatsapp, slack, signal, home assistant),
and built around persistent identity.
hermes has soul.md -for global agent identity,
hermes.md for project-level instructions,
a memories/ directory for persistent knowledge,
and a self-improving skills system that lets the agent write
and save its own reusable tools.
the core difference:
claude code is a coding agent with world-class harness.
hermes agent is a life agent with genuine multi-platform presence and evolving self-awareness.
hermes integrates with honcho for user modeling
it builds an evolving psychological profile of you and uses it to improve its behavior over time.
three tiers of memory. self-written skills. actual learning.
garry tan open-sourced gstack
his personal claude code configuration that hit 66,000+ github stars within weeks.
gstack packages 23 specialist skills and 8 power tools into slash commands.
it turns a single ai assistant into a virtual dev team
executive-level product thinking,
design system generation,
engineering management,
release management,
documentation,
QA.
the whole pipeline.
my preferred stack:
hermes agent for the persistent, multi-platform layer with honcho as memory.
gstack skills layered on top for development work. obsidian as the local knowledge base feeding into the second brain.
it sounds complex.
and the full version is.
but the entry point is simple (as mentioned above): install claude code, write a calude.md, start building context. everything else is progressive enhancement.
context engineering: how to build it
the people who win with agents are not the people with the best prompts.
they are the people who built the best context.
context engineering is a real skill.
and it is underrated because it is invisible.
start with claude.md in your project root.
describe the project, the architecture, the conventions,
the things the agent should always do
and never do.—this is important
be specific. “we use typescript with strict mode” is better than “follow best practices.”
add agents.md for multi-agent setups
define roles, handoff protocols, scope for each agent.
use directory-level .claude files for scoped context.
the frontend/ folder gets frontend conventions.
the api/ folder gets api conventions.
write markdown specifications for every non-trivial task before handing it to the agent.
the spec is the product of your thinking. the agent executes against the spec.
this is where judgment lives.
build self-improving context files.
let the agent update its own claude.md as it learns about the codebase.
and critically: build context about yourself.
your agent should know how you think, what you value, how you make decisions.
building your own brain
farza did something wild.
he took 2,500 entries from his diary, apple notes, and iMessage conversations,
fed them to an llm, and had it create a personal wikipedia.
400 detailed articles.
about his friends, his habits, his decisions, his history, his patterns.
he called it farzapedia.
if you think about it for more than a moment,
the thesis: everyone should be building context about themselves.
not for vanity. for leverage.
when your agent knows your history, your preferences, your patterns, your relationships, your communication style, your decision-making tendencies
it stops being a generic tool and starts being an extension of you.
the gap between “ai assistant” and “digital partner” is context.
and context comes from deliberate self-documentation.
soul.md is a tool designed for exactly this.
let claude code or another agent ingest your data and build your ai soul
a personality file that captures how you think, how you write, what you care about, what you avoid.
this connects karpathy’s knowledge base to farza’s personal wiki to the agent memory layer.
it is all the same thesis: context compounds.
the more your agent knows, the more useful it becomes,
and the more it feels less like a tool and more like a version of yourself that never forgets.
the sovereign future (i hope for)
your agent does not have to live on a macbook (or linux if you’re wild like me) tethered to an api.
the whole stack can go mobile.
it can go local.
it can go offline.
if your agent needs wifi and a laptop to function, it is still a desk tool.
it is not an extension of you.
extensions travel.
on the mobile side: termux plus llama.cpp on android gives you local inference on a phone with 4+ GB of RAM.
pocketpal runs offline llm on mobile. simple.
on the local side: ollama, llama.cpp, vLLM. running models on your own hardware means no api costs, no data leaving your machine, no dependency on any company staying online or staying friendly.
vitalik buterin published his full self-sovereign local llm setup
air-gapped, privacy-first, zero third-party trust required.
do i recommend going fully local yet? not quite. there are limitations.
but you have to assume the tech always gets better
better hardware and better open-source lightweight models.
on the extreme end: the cyberdeck. —attempting to build this for myself
a pelican case with a raspberry pi or mini pc. local llm. solar panel. mesh networking. offline wikipedia. no internet required.
portable offline knowledge, ai, and mesh communication platform.
this is not cosplay.
it is the logical conclusion of self-sovereign ai.
if you actually own your agent
if it has your memory, your context, your personal wiki, your communication history, your decision patterns
then running it locally is not paranoia.
it is architecture.
privacy becomes a moat.
not an inconvenience.
the whole stack —> hermes agent, honcho memory, gstack skills, obsidian vault, local model —> can be packed into something you carry. your second brain, literally in a bag.
if you want inspiration, check out the cyberdeck cafe.
some cool inspo, if this enticing
some light thinking
clark and chalmers argued that our minds extend into the external instruments we use. if the mind extends into tools, then a portable agent with your full context is a portable extension of cognition.
the cyberdeck is the physical manifestation of the extended mind thesis.
it sounds extreme until you consider the alternative: all of your context, your memory, your digital self, living on someone else’s server, subject to someone else’s terms of service, accessible only through someone else’s interface.
the sovereign version is harder to set up. is not harder to justify.
living in a world with agents
we are not just adding tools.
we are changing the relationship between a person and their work.
when your agent has memory, context, judgment scaffolding, and the ability to act
it is no longer a tool you pick up and put down.
it is a persistent collaborator that evolves alongside you.
this raises questions that no documentation answers.
what does it mean when your digital self remembers things you have forgotten?
what does it mean when the agent’s understanding of your work is more complete than your own, because it never loses context and you do?
what does identity look like when part of your cognition is externalized and persistent?
these are not future questions.
they are present ones.
if you have set up any of the systems described above, you are already living them.
the variance between people who build this infrastructure and people who do not will compound faster than any previous technological gap.
not because agents are magic.
but because the lever amplifies what is already there.
curiosity becomes exploration.
initiative becomes speed.
taste becomes prolificacy.
but passivity is amplified too. so is denial. so is fear dressed up as sophistication.
the same tool in two different hands becomes two different futures.
the question is not whether agents are real.
they are.
the question is what you build with them
while the rest of the world is still arguing about whether they work.