DEV Community: Abhijit Karode

The Niners: How 9 CLIs Turned My AI Agent Into a Contender

Abhijit Karode — Wed, 05 Aug 2026 15:42:54 +0000

From the Bay, with love for the red and gold.

I live in the Bay Area, so I'm contractually obligated to believe in two things: fog as a lifestyle, and the Niners. This season, my football team is nine command-line tools — and they've changed what my AI agent can do more than any model upgrade this year.

This is the story of how a roster of nine typed CLIs turned Neo — the AI teammate for solutions architects I wrote about in One Year of Building on Kiro — from a promising rookie into a playoff contender.

In that retrospective, lesson #5 was one line: "prefer typed CLIs for compound work; keep tool calls for conversation." This post is that one line, taken to the playoffs.

The problem: my agent was running a slow offense

Neo started life the way most agents do — wired to a stack of MCP servers. It worked, but every play was a huddle: load a large tool surface into context, call a fixed-shape tool, think, and call again. In the final benchmark, the three MCP servers attached to the router contributed 86,221 tokens of schemas before a turn did any work. Answering "what's going on with this customer?" took five MCP calls; the equivalent compound CLI used one.

The industry has spent the last year converging on the fix from a few directions — agents that write code to orchestrate tools instead of calling them one at a time, keeping intermediate results out of the context window entirely. Anthropic wrote about it. Cloudflare built a mode for it. The "CLI vs MCP" debate filled my feed all spring.

Here's the thing: the Unix tradition had this figured out in the 1970s. Small programs. Text streams. Exit codes. Pipes.

So I drafted a team.

Credit where it belongs: the nine-tool roster is my implementation, but its shared CLI contract was inspired by the Printing Press CLIs. Their machine-first conventions — self-describing command catalogs, a consistent agent mode, runtime intent resolution, typed exit behavior, and out-of-band delivery — became the pattern I adapted across Neo's toolkit.

What the benchmark actually measured

I ran both paths against the same live production backends: real MCP stdio JSON-RPC on one side, direct CLI subprocesses on the other, five repetitions per arm, with tokens counted using cl100k_base rather than a bytes-to-tokens estimate.

The result was more useful than "CLI good, MCP bad":

Resident context was the decisive difference. The router's three MCP servers exposed 148 tools and 86,221 tokens of schemas — 43.1% of a 200k context window — on every turn. CLI catalogs were loaded only when needed.
Ordinary call latency was a tie. Identity, inbox, and email search differed by roughly 10-70ms. Network time dominated; the CLI repaid a ~60ms process-spawn cost on every call.
Raw CLI payloads could be worse. Unprojected email results were 2.4-7.2x larger because the CLI returned the upstream envelope. But --select cut a CRM response by 64.5%, and the compound account fingerprint used 689 tokens versus 5,367 across five MCP calls.
Conversation length changed the economics. In a modeled ten-turn session with three calls total, the CLI path used 37.7x fewer tokens. That is an uncached upper bound: prompt caching should narrow the gap, and I could not measure the cache from this environment.

So the claim is not that every CLI call is faster or smaller. The win comes from on-demand discovery, source projection, compound commands, and keeping intermediate data out of the model's context.

Newer clients can defer MCP schemas with tool search, which narrows the startup gap. It does not erase the core difference: once a tool is loaded, its schema occupies context on later turns, while a CLI contributes only the command and selected output.

The roster

Nine CLIs, each covering one domain my agent works in daily. Position by position:

QB1 — the memory CLI. Local SQLite brain. Save, search (keyword/semantic/hybrid), edit in place, and — the new trick — a work graph: typed edges between memories, so "show me everything connected to this customer" is one graph traversal, not twelve searches. Also runs the scheduler: any recurring prompt becomes a cron job with one command.
RB — the CRM CLI. Compound reads that replace five API round trips with one command (fingerprint = account + team + open deals + spend, joined server-side).
WR1 — the Slack CLI. 189 commands. Search, history, posting, reactions, file uploads.
WR2 — the email + calendar CLI. Inbox, search with a full query DSL, full message bodies by ID, calendar views, meeting create/respond — and a guardrail that refuses to send external email without an explicit human yes.
TE — the docs CLI. Full-text search across the document library (SharePoint), drive walks, downloads.
OL — the tasks CLI. Asana, 57 commands, including in-place updates (no more delete-and-recreate as an "edit").
DB — the sales-content CLI. Read-only search + LLM instant answers over the approved content library.
LB — the expert CLI. Deep, citation-backed answers from a curated knowledge vault. Slow (minutes, not seconds) but authoritative — the run-stopper you send in when the answer has to be right.
Special teams — the field-ops orchestrator. Compound plays that call the other CLIs: one command for the morning briefing, one for meeting prep, one for public-signal research on a company (SEC filings, GitHub footprint, Wikipedia, Hacker News).

397 commands total. No command schemas were resident in context; the agent queried one binary at a time.

What makes a CLI agent-ready

Handing an agent bash and hoping is not a strategy. Every CLI on this roster follows the same contract, and this is the actual secret sauce:

1. One flag for agent mode. --agent = JSON output, no interactive prompts, no colors, and auto-confirm. Compact output is part of the intended contract, but the benchmark caught a real defect: --compact was a no-op on several email and CRM paths. Today, --select and compound commands are the reliable shaping primitives.

2. Self-description. Every CLI ships agent-context --json — a machine-readable catalog of every command, flag, and whether it's read-only. The agent never guesses a flag shape; it asks the binary.

3. Runtime tool search. Most ship which "<natural language intent>" — a built-in resolver that maps "find stale tasks" to the right command, with a typed exit code (2 = no confident match, a machine-readable "I don't know"). This is the "tool search" pattern everyone's excited about, implemented per binary.

4. Out-of-band results. --deliver file:/tmp/x.json routes output to disk atomically. The agent chains CLI → jq → CLI without any of the intermediate data transiting the model. --select id,name,status projects fields at the source. This is the token-efficiency play: the model sees the compiled answer, not the raw feed.

5. Retry-safe semantics. --dry-run, --idempotent, --ignore-missing. Agent loops retry things; the tools shrug instead of double-creating.

6. Offline mode. sync mirrors everything to local SQLite; --data-source local runs against the mirror. Demos don't die when SSO expires at 2 PM.

The playbook: composite prompts

Where it gets fun is when one prompt fans out across the whole roster. My favorites from the actual playbook:

The West Coast Offense (all 9, one prompt):

"Prep me for the customer QBR — pull the CRM fingerprint, my email threads and calendar history with them, what the team's saying in Slack, the docs library, open tasks, approved messaging for their use case, ask the expert agent about their architecture, add public-signal research, then compile one dossier and link it into my work graph."

Nine tools, parallel fan-out, intermediate JSON on disk, one compiled brief in context. The fast legs finish in seconds; the expert leg can take several minutes, so the dossier fills in incrementally instead of pretending every route has the same clock.

The two-minute drill:

"Clear my plate for travel week — find calendar conflicts with my trip, push out task due dates that land while I'm out, draft the meeting declines for my review, save the decisions to memory."

The film room:

"Why did you claim X in this morning's briefing?" — the memory CLI's bisect traces any compiled claim back to its source memories, and the work graph shows what's connected. Provenance as a first-class query.

The season-long stat sheet:

"Draft my quarterly review from what I actually did" — completed tasks, closed deals, posts, saved outcomes, all pulled from the namespaces they auto-landed in during the season.

The box score

The measured box score:

The router's resident MCP schemas: 86,221 tokens per turn; the CLI path loads catalogs on demand
Basic identity, inbox, and search latency: effectively a tie
Account fingerprint: 1 call, 689 tokens, ~0.78s via CLI versus 5 calls, 5,367 tokens, 1.667s via fixed-shape MCP tools
Field projection: 282 → 100 tokens with --select, a 64.5% reduction
Ten-turn session model: 37.7x lower token spend for CLI as an uncached upper bound
The agent still works on a plane, recurring workflows still become cron jobs, and failures are still shell commands I can reproduce myself

That last one matters more than the benchmarks. CLIs are inspectable. The agent and I debug the same way.

Build your own niners

You don't need nine. You need the contract:

Pick the 3-4 systems your agent touches daily
Wrap each in a CLI that speaks JSON, never prompts, and describes itself
Add an intent resolver so the agent can search commands at runtime
Route intermediate results through files, not the context window
Ship compound commands for your most common multi-call sequences

The models keep getting better. But the biggest capability jump my agent ever got wasn't a model release — it was a good roster, a shared contract, and a playbook.

Go Niners. 🏈

Neo is a router agent with domain sub-agents, a local-first memory, and now, a nine-CLI toolkit. For the season-one recap — how it grew from one Kiro CLI agent to a fleet — read One Year of Building on Kiro. Questions and roster suggestions welcome in the comments.

मी AI सहाय्यक बनवणं थांबवलं. माझ्या आयुष्यासाठी कार्यप्रणाली बनवायला सुरुवात केली.

Abhijit Karode — Fri, 31 Jul 2026 19:17:30 +0000

टीप: Mora OS हा माझ्या स्वतःच्या संगणकीय साधनांवर Codex Pro च्या साहाय्याने उभारलेला वैयक्तिक प्रकल्प आहे. हा लेख AI च्या मदतीने लिहिला असला, तरी त्यावर मी स्वतः अनेक फेऱ्यांत प्रश्न विचारले, संपादन व पुनर्लेखन केलं आणि बारकाईने सुधारणा केल्या आहेत. 🙂

मी San Francisco Bay Area मध्ये राहतो. इथे भविष्य जवळच्या एखाद्या कॉफीगृहात बसून कोणी तरी जोडत आहे, अशी भावना टाळणं जवळजवळ अशक्य आहे.

गेल्या काही वर्षांत हे भविष्य प्रामुख्याने एका संवादपेटीच्या (AI chat) रूपात आपल्यापर्यंत आलं.

मला संवाद (chat) साधायला आवडतो. मी ही सोय सतत वापरतो. पण AI ला माझ्या आयुष्यात खरोखर उपयोगी बनवण्याचा जितका प्रयत्न केला, तितकी त्याची एक मूलभूत उणीव स्पष्ट होत गेली:

संवादपेटी (AI chat) माझ्याकडूनच सगळं संयोजन करून घेत होती.

काय विचारायचं हे मला आठवावं लागायचं. योग्य संदर्भ शोधावा लागायचा. संदेश, तारखा, फाइल्स आणि आधीचे निर्णय सूचनेत चिकटवावे लागायचे. उत्तर मिळाल्यावर ते पुन्हा जिथे काम चालत होतं तिथे न्यायचं. आणि आठवडाभराने संपूर्ण गोष्ट पुन्हा समजावून सांगायची.

हा सहाय्यक नाही. हा अफाट हुशार पण विसरभोळा सल्लागार आहे—आणि त्याचा प्रकल्प व्यवस्थापक अजूनही मीच आहे.

म्हणून मी वेगळं काहीतरी बनवायला सुरुवात केली.

मी त्याला Mora OS म्हटलं: खाजगी, स्थानिकतेला प्राधान्य देणारी आणि सहज स्थलांतरित करता येणारी कर्ता AI कार्यप्रणाली (operating system). मी आधीपासून वापरत असलेल्या प्रणालींमधील (systems) संकेत समजून घेणं, टिकाऊ स्मृती (memory) राखणं, माझं लक्ष कुठे हवं हे ठरवणं, कृती सुचवणं आणि Mac व iPhone साठी खास घडवलेल्या अनुभवांतून त्या कृतींवर माझं नियंत्रण ठेवणं—हा त्याचा उद्देश.

ही लोकार्पणाची घोषणा नाही. स्वतःची पाठ थोपटून घेणारी यशोगाथा तर अजिबात नाही. ही गोष्ट आहे शून्यापासून प्रणाली उभी करण्याची, महत्त्वाच्या गोष्टी चुकवण्याची, हे क्षेत्र काय शिकत आहे याचा अभ्यास करण्याची आणि हळूहळू एक सत्य शोधण्याची:

कार्यप्रणाली ही उपमा केवळ बाजारपेठीय भाषा नव्हती.

तीच रचना (architecture) होती.

जेव्हा संवादपेटी (AI chat) अपुरी वाटू लागली

माझी पहिली प्रतिक्रिया अगदी अपेक्षित होती: कर्त्याला आणखी साधनं जोडा.

ईमेल. दिनदर्शिका. संदेश. फाइल्स. स्मृतीसाठा. नंतर आरोग्यविषयक निर्याती आणि दूरध्वनीवरील साथीदार App. प्रतिमानाला (model) सगळीकडे पोहोचता आलं, तर ते नक्कीच अधिक उपयोगी बनेल, असं वाटलं.

तो अधिक सक्षम झाला.

पण तो आपोआप अधिक विश्वासार्ह झाला नाही.

अधिक जोडण्यांमुळे नवे प्रश्न उभे राहिले:

कोणते स्रोत खरोखर अद्ययावत होते?
संदेश मला पाठवला होता, मी पाठवला होता, की समूहात फक्त दिसत होता?
मी ही गोष्ट आधीच हाताळली होती का?
ही उपयुक्त पार्श्वभूमीतील माहिती होती की माझी वैयक्तिक जबाबदारी?
प्रतिमान पुरावा (evidence) पाहत होतं, जुनी स्मृती पाहत होतं, की दोन्हींचं आत्मविश्वासपूर्ण मिश्रण?
प्रणालीने एखादी कृती सुचवली, तर तिला परवानगी कोणी दिली?
मी एखादी गोष्ट बाजूला काढली, तर प्रणाली त्यातून शिकेल की उद्या पुन्हा तीच गोष्ट दाखवेल?
जोडणीसाधन शांतपणे बंद पडलं, तर बाकीची प्रणाली काहीच घडलं नाही असं भासवेल का?

प्रश्न आता “आणखी चांगली सूचना कशी लिहू?” हा राहिला नव्हता.

प्रश्न होता: “प्रतिमानाने माझ्या आयुष्यात सुरक्षितपणे भाग घ्यायचा असेल, तर त्याच्या भोवती कोणत्या सेवा असल्या पाहिजेत?”

याच प्रश्नाने सहाय्यकाचं OS मध्ये रूपांतर केलं.

रचना चुका करून घडली

मी फलकावर संपूर्ण प्रणाली अचूक रेखाटली आणि मग ती तशीच कार्यान्वित केली, असं अजिबात झालं नाही. प्रत्येक शॉर्टकट वेगळ्या पद्धतीने अपयशी ठरला आणि त्यातून रचना आकार घेत गेली.

आजच्या आराखड्यात सहा मुख्य जबाबदाऱ्या आहेत.

1. वास्तव समजून घ्या; पण ते वर्तमान आहे असं भासवू नका

Mora OS स्थानिक आणि जोडलेल्या स्रोतांमधून मर्यादित जुळवणसाधनांद्वारे माहिती घेतं. शक्य तिथे स्पष्ट प्रकार ठरवलेल्या आज्ञावली-माध्यमांना प्राधान्य आहे.

प्रत्येक निरीक्षणासोबत उगमसाखळी (provenance) असणं आवश्यक आहे:

ते कुठून आलं;
स्रोताने ते केव्हा तयार केलं;
प्रणालीने ते केव्हा पाहिलं;
त्याच्या अद्ययावतपणाची (freshness) कालमर्यादा किती आहे;
माहिती आणण्याची प्रक्रिया पूर्ण, अंशतः, सदोष, अनधिकृत किंवा अनुपलब्ध होती का.

“जोडलेलं” म्हणजे “समक्रमित” नाही.

“ओळख पटलेली” म्हणजे “अद्ययावत” नाही.

“काही निष्पन्न झालं नाही” म्हणजे “काहीच घडलं नाही” नाही.

एखादा सुंदर दर्शकफलक जुनी माहिती पूर्ण आत्मविश्वासाने संक्षिप्त करेपर्यंत हे सगळं उघड वाटतं.

म्हणून Mora OS मधील सर्वात महत्त्वाच्या रचनात्मक निर्णयांपैकी एक अजिबात झगमगीत नाही: अनिश्चितता ही स्वतंत्र आणि पूर्ण मान्यता असलेली अवस्था आहे. प्रणालीला “मला माहीत नाही” म्हणण्याची मुभा आहे.

2. प्रतिमानाच्या बाहेर स्थलांतरक्षम मेंदू ठेवा

स्मृतीप्रणाली—Mora—स्थानिक पातळीवर राहते आणि कोणत्याही एका प्रतिमान किंवा कर्ता-कार्यकालापासून स्वतंत्रपणे स्थलांतरित करता येते.

पहिल्या नजरेत वाटतं त्यापेक्षा हे फार महत्त्वाचं आहे.

प्रतिमानं बदलतात. संदर्भमर्यादा बदलतात. कर्ता-चौकटी बदलतात. किंमती बदलतात. तर्कयंत्र बदललं म्हणून एखाद्या व्यक्तीचा इतिहास गायब होता कामा नये.

संशोधनातही हीच कल्पना वेगवेगळ्या दिशांनी पुढे येताना दिसते. MemGPT ने मोठ्या संदर्भाचं व्यवस्थापन कार्यप्रणालीतील आभासी स्मृतीप्रमाणे मांडलं. Generative Agents ने निरीक्षण, चिंतन, पुनर्प्राप्ती (retrieval) आणि नियोजन एकत्र केलं. Anthropic ने संदर्भ-अभियांत्रिकी विषयी लिहिताना संदर्भ हा मर्यादित स्रोत आहे आणि तो जाणीवपूर्वक निवडला पाहिजे, असं स्पष्ट केलं.

माझं व्यावहारिक उत्तर म्हणजे माहितीची बादली नव्हे, तर ग्रंथपाल.

प्रत्येक कच्चं निरीक्षण कायमचं सत्य म्हणून जतन होत नाही. उपयोगी निष्पत्ती उगमसाखळीसह संक्षिप्त, टिकाऊ स्मृती बनतात. पुनरावृत्ती संक्षिप्त केली जाते. जुन्या मजकुराचा आढावा घेता येतो. संपूर्ण संग्रह सूचनेत ओतण्याऐवजी पुनर्प्राप्ती चालू कामापुरती मर्यादित राहते.

ध्येय “सगळं कायम लक्षात ठेवा” हे नाही.

ध्येय आहे:

जे पुढेही उपयोगी आहे ते जतन करा, ते कुठून आलं हे माहीत ठेवा, योग्य वेळी परत आणा आणि मालकाला ते दुसरीकडे नेण्याचं स्वातंत्र्य द्या.

यामुळे वैयक्तिकीकरण (personalization) एखाद्या विक्रेत्याच्या संवादइतिहासाचा दुय्यम परिणाम न राहता, स्वतःच्या मालकीची संपदा बनते.

3. माहितीजन्य बुद्धिमत्ता आणि कर्तव्य वेगळे ठेवा

सर्वात कठीण दोषांपैकी एक दिसायला निरुपद्रवी होता.

Mora OS एखाद्या समूह-संवादातील उत्साही चर्चा दैनंदिन बुद्धिसारांशात संक्षिप्त करू शकत होतं. पण पुढच्या टप्प्यावर त्याच मजकुराला माझंच एखादं काम समजलं जाऊ शकत होतं.

या चुकीने मला दोन स्वतंत्र मार्ग बांधायला शिकवलं.

माहितीजन्य बुद्धिमत्तेचा मार्ग विचारतो:

माहिती अद्ययावत आहे का?
ती खरोखर उपयोगी आहे का?
ती एखाद्या सत्यापित आवडीशी, प्रकल्पाशी किंवा नात्याशी संबंधित आहे का?
आजच्या मर्यादित लक्ष-मर्यादेतील जागा तिला द्यावी का?

वैयक्तिक कृतीच्या मार्गासाठी निकष खूपच कठोर आहेत:

थेट विनंती आहे का?
मालकी सत्यापित आहे का?
जबाबदारी खरोखर माझी आहे का?
ती आधीच हाताळली आहे का?
पुढच्या पावलामागे कोणता पुरावा आहे?

पार्श्वभूमीतील बुद्धिमत्ता संक्षिप्त आढावा समृद्ध करू शकते. पण ती गुपचूप काम, तातडीची सूचना किंवा बाह्य कृती बनू शकत नाही.

हा प्रतिमानपूर्व प्रवेशद्वार प्रणालीतील सर्वाधिक परिणामकारक भागांपैकी एक ठरला. तर्कावर खर्च करण्यापूर्वी तो गोंगाट कमी करतो, खोट्या कर्तव्यांचा संपूर्ण वर्ग रोखतो आणि काय आत घेतलं किंवा थांबवलं याचा लेखापरीक्षणयोग्य (auditable) खुलासा देतो.

OpenAI च्या कर्ते तयार करण्याच्या व्यावहारिक मार्गदर्शकात स्तरबद्ध संरक्षक मर्यादा आणि अतिजोखमीच्या कृतींसाठी मानवी हस्तक्षेप यांवर भर आहे. कर्त्याची ओळख आणि अधिकारप्रदान यांविषयी NIST चं काम याच खोल प्रश्नाकडे निर्देश करतं: कर्त्याला बुद्धिमत्ता पुरेशी नाही. त्याला मर्यादित अधिकार (authority), ओळख, लेखापरीक्षणक्षमता आणि कृती नाकारता न येण्याची खात्री आवश्यक आहेत.

4. संदेशपेटीऐवजी लक्ष-वाटपाचा करार बनवा

स्रोत आणि प्रवेशद्वारं तयार झाल्यावर मी आणखी एक चूक केली: खूप काही दाखवलं.

सगळं एकत्र करणं म्हणजे नियंत्रणकक्ष (cockpit) उपयुक्त होणं नाही. पाच गोंगाटी प्रवाह एका प्रचंड प्रवाहात बदलले, तर आपण केवळ चिंता एका जागी केंद्रीत केली आहे.

दैनंदिन बुद्धिसारांशाला आता लक्षाची स्पष्ट मर्यादा आहे. मोजक्या दृश्य जागांसाठी नोंदी एकमेकांशी स्पर्धा करतात. काय पात्र ठरलं, काय वगळलं आणि का—प्रणाली याची नोंद ठेवते.

कर्ता-कामं पुन्हा वेगळी आहेत. ती “रंजक सूचना” नाहीत. रांगेतील कामाकडे पुढील गोष्टी हव्यात:

मालक;
पुरावा;
तातडीचं कारण;
पुढचं पाऊल;
अवस्था;
रांगेतून बाहेर पडण्याची अट;
जीवनचक्र आणि पुनरावृत्ती-निर्मूलनाच्या पावत्या.

फरक सूक्ष्म आहे, पण पायाभूत:

दैनंदिन बुद्धिसारांश मला समजून घ्यायला मदत करतो. कर्ता-कामं मला निर्णय घ्यायला किंवा कृती करायला सांगतात.

दोन्हीमधून Ask Mora उघडून पुराव्यावर आधारलेलं सखोल संभाषण करता येतं. पण आता संवाद हा OS मधील पूरक भाग आहे—स्वतः OS नाही.

5. कृती आधी मसुदा, मग मान्यता अशा ठेवा

सर्वात सोपं कर्ता-प्रात्यक्षिक हेच सर्वात धोकादायकही आहे: “बघा, त्याने संदेश पाठवला.”

Mora OS उलट गृहितकापासून सुरू होतं.

वाचनक्रियांना कमी अधिकार लागतात. मसुदे मागे घेता येतात. बाह्य लेखनक्रियांचे परिणाम होतात.

म्हणून कृती स्पष्ट टप्प्यांतून पुढे जाते:

विश्लेषण;
योजना आणि परिणामाचं पूर्वदर्शन;
धोरणानुसार मान्यता;
पुनरावृत्तीनेही तोच परिणाम देणारं कार्यान्वयन;
कृतीनंतरच्या अवस्थेची पडताळणी;
लेखापरीक्षण पावती.

विश्वास निर्माण झाला तर कृतीप्रकारानुसार प्रणाली अधिक स्वायत्त होऊ शकते. पण स्वायत्तता ही व्यक्तिमत्त्वाची मांडणी नाही. ती निरीक्षित विश्वासार्हतेवर आधारलेला धोरणात्मक निर्णय आहे.

हा फरक महत्त्वाचा आहे, कारण प्रणाली-सूचनेत “काळजी घे” लिहून कर्त्याची सुरक्षितता साधत नाही. कर्त्याचं अपहरण याविषयी NIST चं काम विश्वासार्ह सूचना आणि अविश्वसनीय बाह्य माहिती एकत्र करण्याचा धोका दाखवतं. वैयक्तिक OS मध्ये ईमेल, संदेश, जालपृष्ठं आणि कागदपत्रं ही सर्व संभाव्य शत्रुत्वपूर्ण निविष्टा आहेत.

प्रतिमान प्रस्ताव देऊ शकतं. तो प्रस्ताव कशात बदलू शकतो हे केंद्रक ठरवतं.

6. प्रक्रिया नव्हे, वापरकर्त्याचा संपूर्ण प्रवास तपासा

आणि मग Mac अॅप पूर्ण कोरं झालं.

पार्श्वप्रणाली चालू होती. आरोग्य-अंत्यबिंदू यश दाखवत होता. अनुप्रयोग-प्रक्रिया अस्तित्वात होती. निर्मितीचाचण्या उत्तीर्ण झाल्या होत्या. पायाभूत व्यवस्थेच्या दृष्टीने सगळं सुरळीत होतं.

वापरकर्त्याच्या दृष्टीने उत्पादन म्हणजे पांढरा चौकोन होता.

त्या अपयशाने प्रत्यक्ष वापरासाठीच्या गुणवत्तेची सर्वात स्पष्ट व्याख्या दिली:

घटक यश सांगतात म्हणून प्रणाली सुरळीत ठरत नाही; वापरकर्त्याचा अत्यावश्यक प्रवास प्रत्यक्ष चालतो तेव्हाच ती सुरळीत असते.

या धड्यातून Mora OS Doctor तयार झाला. तो स्रोत, अद्ययावतपणा, स्थानिक स्मृती, प्रवेशद्वारं, दैनंदिन बुद्धिसारांश, कामं, Ask Mora, सूचना, लेखापरीक्षण पावत्या, Mac ची मूळ अवस्था आणि iPhone साथीदार या पूर्ण साखळीची तपासणी करतो. तो अपरिवर्तनीय तपासणी-पुरावा जतन करतो, वारंवार येणाऱ्या अडचणींतील पुनरावृत्ती काढतो, पुनर्प्राप्ती ओळखतो आणि क्षमता सिद्ध करता आली नाही तर सुरक्षितपणे नकार देतो.

आम्ही प्रत्यक्ष दिसणाऱ्या खिडकीची पुनरावृत्ती-चाचणीसुद्धा जोडली. “प्रक्रिया चालू” यापुढे “अनुप्रयोग दिसतो आहे” याचा पुरावा होऊ शकत नाही.

कंटाळवाण्या वाटणाऱ्या शिस्ती हाच खरा संरक्षक खंदक ठरल्या:

कार्यान्वयनाआधी तपशीलवार अपेक्षालेखन;
ओळख पटवून मूळ-प्रणालीतील वर्तन तपासणाऱ्या चाचण्या;
प्रत्यक्ष उपकरणावरील पुनरावृत्ती-चाचणी;
प्रत्यक्ष वापरात सापडलेला प्रत्येक दोष कायमस्वरूपी चाचणी बनवणं;
फक्त संकलन नव्हे, बांधलेलं आणि स्थापित अॅप पडताळणं;
बाह्य अडथळ्यांबद्दल प्रामाणिक राहणं;
जुन्या पुराव्यावर आवृत्ती-सिद्धतेचा दावा न करणं.

Anthropic ने अनेक कर्त्यांची संशोधनप्रणाली बनवण्याच्या अनुभवात यासारखंच सत्य मांडलं: शेवटचा टप्पा बहुतेक पूर्ण प्रवास बनतो आणि लहान अपयशं कर्त्याच्या वाटचालीत फार मोठे फरक निर्माण करतात. OpenAI चं कार्यचिन्हांचं श्रेणीकरण आणि मूल्यमापन यावरील अलीकडचं कामही याच दिशेने जातं. कर्त्याची गुणवत्ता एखाद्या प्रभावी उत्तरावरून गृहित धरता येत नाही; ती पूर्ण कार्यप्रवाहात (workflow) पाहावी लागते.

मग OpenClaw सारखं काही वापरण्याऐवजी हे का बनवायचं?

हा कोण विजेता आहे हे जाहीर करणारा भाग नाही.

OpenClaw हा महत्त्वाकांक्षी सर्वसाधारण वैयक्तिक सहाय्यक मंच आहे. त्याच्या अधिकृत कागदपत्रांत अनेक माध्यमं, अनेक कर्त्यांचं मार्गनिर्देशन, सत्रं, स्मृती, कौशल्यं आणि सदैव चालू असलेलं प्रवेशद्वार यांचा समावेश आहे. हा विस्तार खरोखर उपयोगी आहे. अनेक संदेश-माध्यमं पटकन जोडायची असतील आणि मोठ्या परिसंस्थेवर प्रयोग करायचे असतील, तर त्याचा गंभीरपणे विचार करायला हवा.

Mora OS वेगळी तडजोड निवडतं.

त्याची रचना एका मालकाभोवती आहे: एक स्थलांतरक्षम स्मृतीप्रणाली, वैयक्तिक मूळ-प्रणाली नियंत्रणकक्ष, स्पष्ट पुरावा आणि मर्यादित अधिकारसीमा. हा फरक तीन ठिकाणी दिसतो.

सुरक्षितता: लहान अधिकारक्षेत्र समजून घेणं सोपं असतं

सर्वसाधारण कर्ता-मंच अनेक जोडघटक, माध्यमं, साधनं आणि कार्यान्वयनमार्ग स्वीकारू शकतो, म्हणून शक्तिशाली असतो. हाच विस्तार विश्वास ठेवावा लागणाऱ्या क्षेत्राची व्याप्ती वाढवतो.

OpenClaw ची प्रारंभप्रक्रियासुद्धा कर्ते शक्तिशाली आहेत आणि संपूर्ण-प्रणाली प्रवेश धोकादायक आहे, असा इशारा देते. त्याच्या कागदपत्रांनुसार ओळख-पडताळणी साहित्य आणि सत्र-अवस्था स्थानिक कर्ता-संचिकांत असतात. वेगाने बदलणाऱ्या, उच्चाधिकार मंचाकडून अपेक्षितच आहे तसा हा प्रकल्प सतत सुरक्षितता-दुरुस्त्या देत राहतो. CVE-2026-26972 सारखे सार्वजनिक इशारे आपल्याला आठवण करून देतात की स्थानिक कार्यान्वयन म्हणजे आपोआप कमी धोका नाही.

Mora OS मुद्दाम सीमा अरुंद ठेवतं:

स्पष्ट प्रकार ठरवलेल्या, अनुमतसूचीतील CLI क्षमता;
पूर्वनियोजितपणे केवळ-वाचन माहितीग्रहण;
विलग केलेली आरोग्य-माहिती प्रक्रिया;
स्थानिक सांकेतिक स्मृती;
स्पष्ट अद्ययावतपणा आणि उगमसाखळी;
रचनात्मकदृष्ट्या कृतीस अपात्र बुद्धिमत्ता;
परिणामकारक लेखनक्रियांसाठी मान्यता-द्वारं;
कृतीनंतरची पडताळणी आणि केवळ भर घालता येणारं लेखापरीक्षण;
ओळख पटलेलं जोडणीसाधन वर्तमान किंवा सुरक्षित आहे असं गृहित न धरणं.

सर्वसाधारण मंचाला अशाच नियंत्रणांनी अधिक सुरक्षित करता येईल का? नक्कीच.

फरक एवढाच की Mora OS मध्ये ही नियंत्रणं केंद्रकाचा भाग आहेत; मालकावर सोडलेलं ऐच्छिक जोडणीकाम नाही.

वैयक्तिकीकरण: स्मृती म्हणजे व्यक्तिमत्त्व-संचिकेपेक्षा खूप अधिक

सूचनेमुळे कर्त्याला माझी ओळख असल्यासारखं बोलता येईल. पण माझ्या बदलत्या जबाबदाऱ्यांची खरी स्थिती समजणं वेगळं आहे.

Mora चं वैयक्तिकीकरण टिकाऊ, उगमसाखळीशी जोडलेल्या रचनेतून येतं:

निर्णय आणि नंतर त्यांना विरोध करणारे पुरावे;
जबाबदाऱ्या आणि मालकी;
व्यक्ती आणि नाती;
हाताळलेल्या आणि न हाताळलेल्या बांधिलक्या;
स्पष्टपणे बाजूला काढलेल्या नोंदी आणि “संबंधित नाही” असा प्रतिसाद;
पुनरावर्ती आकृतिबंधांचं टिकाऊ स्मृतीत संक्षिप्तीकरण;
चालू कामापुरती मर्यादित पुनर्प्राप्ती.

वरवरच्या व्यक्तिमत्त्व-आवरणापेक्षा हे बनवायला अधिक वेळ लागतो. प्रतिमान, कार्यकाल किंवा संवादमाध्यम बदलल्यावर हे गमावणंही तितकंच कठीण असतं.

खर्च: कमी तर्कप्रक्रिया, पण अधिक विचारपूर्वक

कर्ता-चौकटी स्वतः विनामूल्य आणि मुक्तस्रोत असू शकतात. पण सतत चालणारी कर्ता-आवर्तनं प्रतिमान-चिन्हं, जोडणीसाधनांचे स्रोत, साठवण आणि संचालकाचं लक्ष वापरतात.

Mora OS रचनेतून खर्च नियंत्रित करतं:

LLM विनंतीपूर्वी निर्धारक चाळण्या;
संश्लेषणापूर्वी पुनरावर्ती घटनांचं पुनरावृत्ती-निर्मूलन;
मर्यादित नियोजित तपासण्या;
पार्श्वभूमीतील बुद्धिमत्तेकडून महागड्या कृती-नियोजनाला मनाई;
पुनर्प्राप्तीसाठी स्थानिक शोध आणि अनुक्रमणिका;
संदिग्ध, उच्च-मूल्य कामासाठीच उच्चक्षमतेची प्रतिमानं;
API खर्चाबरोबर लक्षाचा खर्चही खरा खर्च मानणं.

यामुळे Mora OS “विनामूल्य” होत नाही. स्थानिक यंत्रसामग्री, अभियांत्रिकीचा वेळ, देखभाल आणि अग्रगण्य अनुमानप्रक्रिया यांनाही किंमत आहे. आणि ही तत्त्वं फक्त Mora ची मक्तेदारी नाहीत; OpenClaw विविध प्रतिमान-पुरवठादार आणि स्थानिक पर्यायांना आधार देतो.

फायदा उद्दिष्ट-सुसंगतीत आहे: शक्य तितका व्यापक सर्वसाधारण कर्ता चालवण्याऐवजी, एका व्यक्तीची विश्वासार्ह अवस्था सांभाळण्यासाठी आवश्यक तेवढीच तर्कप्रक्रिया वापरणं हे Mora OS चं सुधारणा-लक्ष्य आहे.

माझी तुलना थोडक्यात:

प्राधान्य असेल तर…	व्यापक वैयक्तिक-कर्ता मंच	Mora OS
माध्यमं आणि कौशल्यं पटकन वाढवणे	योग्य पर्याय	जाणीवपूर्वक जोडले जातात
सर्वसाधारण प्रयोग	योग्य पर्याय	दुय्यम ध्येय
एका मालकाची स्थलांतरक्षम, संरचित स्मृती	मांडणीने शक्य	मूळ रचना
प्रत्येक महत्त्वाच्या नोंदीसोबत पुरावा व अद्ययावतपणा	कार्यान्वयनावर अवलंबून	अनिवार्य
बुद्धिमत्ता आणि कृतीचे स्वतंत्र मार्ग	कार्यान्वयनावर अवलंबून	केंद्रकाचं अपरिवर्तनीय तत्त्व
मर्यादित, लेखापरीक्षणयोग्य अधिकार	काळजीपूर्वक सुरक्षित करणं आवश्यक	पूर्वनियोजित भूमिका
तर्कप्रक्रियेपूर्वी खर्च-नियंत्रण	बदलता येतं	प्रवेश-तपासणीत अंतर्भूत
मूळ-प्रणाली नियंत्रणकक्ष आणि वैयक्तिक जबाबदारी-प्रतिमान	बदलतं	प्रमुख उत्पादन

कोणती प्रणाली उत्तम हे तुमचं सुधारणा-लक्ष्य काय आहे यावर ठरतं.

मी अनेक वर्षांत साठत जाणारा विश्वास केंद्रस्थानी ठेवून सुधारणा करत आहे.

“शिकणं” म्हणजे गुपचूप अस्वस्थ करणारं होणं नाही

Mora OS ने माझ्याकडून शिकावं, अशी माझी इच्छा आहे.

पण प्रत्येक टिचकी, दुरुस्ती किंवा खाजगी नोंद एखाद्या अस्पष्ट प्रतिमान-व्यक्तिचित्रात गुपचूप मिसळली जावी, असं मला अजिबात वाटत नाही.

म्हणून शिकण्याचं आवर्तन स्पष्ट आणि दुहेरी गतीचं आहे.

जलद कार्यवाहीविषयक शिक्षणात पुढील गोष्टी येतात:

ही नोंद आत्ता बाजूला काढली;
ही गोष्ट संबंधित नव्हती;
हे दोन संकेत एकाच जबाबदारीशी संबंधित होते;
हा स्रोत सध्या जुना आहे;
हे काम पूर्ण झालं.

संथ धोरणात्मक शिक्षणासाठी अधिक ठोस पुरावा लागतो:

वारंवार केलेले बदल संवादाची आवड दाखवतात;
वारंवार केलेले नकार सुसंगतीचं प्रवेशद्वार सुधारतात;
स्थिर आकृतिबंध टिकाऊ स्मृती होऊ शकतो;
निरीक्षित विश्वासार्हता असल्याशिवाय एखाद्या विशिष्ट कृतीवर्गासाठी स्वायत्तता वाढू शकत नाही.

उपयोगी शिक्षणाने मागे पावत्या सोडायला हव्यात. महत्त्वाची स्मृती तपासता आली पाहिजे. विलोपन नियंत्रित असलं पाहिजे. खाजगी स्मृती कोणत्याही सामायिक संदर्भात उन्नत करण्यासाठी स्पष्ट मान्यता हवी.

प्रणाली अधिक वैयक्तिक व्हावी; पण कमी समजण्यासारखी होऊ नये.

आरोग्य-माहितीमुळे “अंतर्दृष्टी”चा अर्थ बदलला

आरोग्य-माहिती जोडल्यावर रचना अधिक गंभीर झाली.

वैद्यकीय कागदपत्रं आणि हालचालींचे आलेख संक्षिप्त करणं सोपं होतं. उपयोगी गोष्ट अधिक कठीण आहे: विविध स्रोतांतील दीर्घकालीन संकेत एकत्र पाहणं, त्यांच्या सीमा जपणं, कल किंवा विसंगती शोधणं आणि निदान केल्याचा आव न आणता विचार करण्यासारखा प्रश्न पुढे ठेवणं.

यासाठी विलगीकरण, अद्ययावतपणाच्या कालमर्यादा, स्रोतनिहाय ETL, वैद्यकीय वेळेनुसार क्रम, पुनरावृत्ती-निर्मूलन आणि भाषिक मर्यादा आवश्यक झाल्या. कच्च्या आरोग्य-नोंदी सर्वसाधारण वैयक्तिक-बुद्धिमत्ता मार्गापासून वेगळ्या राहतात. पद्धती आणि पुरावा-संदर्भ असलेले अत्यल्प व्युत्पन्न संकेतच ती सीमा ओलांडू शकतात.

यातून एक व्यापक धडा मिळाला:

क्षेत्र जितकं परिणामकारक, तितका सुंदर शब्दांत मांडलेला अंदाज “AI अंतर्दृष्टी” म्हणून स्वीकारणं कमी परवडतं.

प्रणालीने आजच्या प्रतिमानापेक्षा जास्त काळ टिकायला हवं

कर्ता AI क्षेत्र इतक्या वेगाने बदलतं आहे की रचना एका चौकटीभोवती गोठवणं शहाणपणाचं ठरणार नाही.

प्रतिमानं अधिक चांगले नियोजक होतील. संदर्भमर्यादा वाढतील. स्थानिक अनुमानप्रक्रिया सुधारेल. साधन-शिष्टाचार आणि कर्त्यांमधील मानकं परिपक्व होतील. नवीन वैयक्तिक माहिती-स्रोत येतील. सुरक्षितता-मार्गदर्शन अधिक ठोस बनेल. आजचे काही आकृतिबंध उद्या भोळे वाटतील.

Mora OS हे बदल स्पष्ट सांध्यांवर स्वीकारू शकेल अशी रचना आहे:

प्रतिमानं ही तर्कयंत्रं आहेत, स्मृतीची मालक नाहीत;
जोडणीसाधनं ही बदलता येणारी, स्पष्ट प्रकारांची जुळवणसाधनं आहेत;
स्मृती स्थलांतरक्षम आहे;
धोरणांना आवृत्तिक्रम आहे;
पुराव्याचे करार स्थिर आहेत;
कामांची टिकाऊ अवस्था कर्ता-सत्रापासून स्वतंत्र आहे;
मूळ-प्रणाली ग्राहक प्रमाणित अवस्था वापरतात;
मूल्यमापनं वापरकर्त्याला दिसणारं वर्तन कायमस्वरूपी तपासतात;
Doctor च्या तपासण्या नवीन क्षमता निरीक्षणयोग्य बनवतात.

सर्वात टिकाऊ घटक प्रतिमान नाही.

प्रतिमानाने काय पाहावं, काय सुचवावं, काय करावं आणि नंतर प्रणालीने काय लक्षात ठेवावं हे ठरवणारी नियंत्रणचौकट सर्वात टिकाऊ आहे.

कोणत्याही वैयक्तिक कर्ता AI प्रणालीसाठी मी जपेन अशी तत्त्वं

Mora OS बनवून, मोडून आणि पुन्हा बांधून मला सर्वाधिक विश्वास वाटणारी तत्त्वं:

संवादापासून नव्हे, जबाबदारीपासून सुरुवात करा.
अद्ययावतपणा, उगमसाखळी आणि अनिश्चितता यांना उत्पादन-वैशिष्ट्यं माना.
उपयोगी बुद्धिमत्ता आणि सत्यापित वैयक्तिक कृती वेगळ्या ठेवा.
स्मृती स्थलांतरक्षम आणि प्रतिमानापासून स्वतंत्र ठेवा.
कार्यप्रणाली स्मृतीची पानं गरजेनुसार पुढे आणते तसा संदर्भ पुनर्प्राप्त करा; माहितीचं कोठार सूचनेत ओतू नका.
परिणामकारक कृती आधी मसुदा, मग मान्यता, पुनरावृत्तीनेही समान परिणाम देणारी आणि लेखापरीक्षित ठेवा.
महाग तर्कप्रक्रियेपूर्वी निर्धारक प्रवेशद्वारं वापरा.
लक्ष हा मर्यादित स्रोत आहे असं मानून आराखडा बनवा.
प्रत्येक अपयशाने नियंत्रणचौकट आणि पुनरावृत्ती-चाचणीसंच सुधारला पाहिजे.
सुरळीत प्रक्रियेला चालणारा वापरकर्ता-प्रवास समजू नका.
केंद्रक स्थिर आणि कडा बदलण्याजोग्या ठेवा.
प्रत्येक कृतीवर्गासाठी स्वायत्तता स्वतंत्रपणे कमवा.

Mora OS आज कुठे आहे

ही सध्याची रचना आहे—काम पूर्ण झाल्याचं आश्वासन नाही.

आज त्यात स्थानिक आणि जोडलेले स्रोत, स्थलांतरक्षम स्मृती, Mac व iPhone साठी घडवलेले अनुभव, दैनंदिन बुद्धिसारांश, नियंत्रित कर्ता-कामं, आरोग्य-बुद्धिमत्ता, धारणा-आढावा, जबाबदारी-नोंदवही, सूचना, लेखापरीक्षण आणि पुढाकार घेणारा टोकापासून टोकापर्यंतचा Doctor यांचा समावेश आहे.

तरीही अनेक खऱ्या कडा उरल्या आहेत.

जोडणीसाधनांचा अद्ययावतपणा हरवतो. कार्यप्रणालीच्या परवानग्या अपयशी ठरतात. भ्रमणध्वनी-जाळं गायब होतं. सुसंगती-द्वारं काही वेळा अति-चाळणी करतात. स्मृती गोंगाटी होऊ शकते. मूळ-प्रणाली स्वयंचलनामुळे मंचाच्या विचित्र मर्यादा उघड होतात. चाचणी उत्तीर्ण होऊ शकते आणि स्थापित अनुप्रयोग तरीही कोरा असू शकतो.

म्हणूनच आता मी याला “सहाय्यक बनवणं” म्हणत नाही.

मी एक छोटीशी वैयक्तिक कार्यप्रणाली बनवत आहे. तिने शिकत राहावं, पण स्वतःचं संविधान विसरू नये:

माझी माहिती माझीच राहील;
आत्मविश्वासाआधी पुरावा;
अधिकार मर्यादित राहतील;
कृती नियंत्रित करता येतील;
स्मृती स्थलांतरक्षम राहील;
अपयशं दिसतील;
केंद्रक कमकुवत न करता नवीन क्षमता जोडता येतील.

वरील रचना बदलेल. ती बदललीच पाहिजे.

कर्ता कार्यप्रणालीने नेमकं काय असावं हे क्षेत्र अजून शोधतं आहे. आणि माझी प्रणाली मला काय बनवायची आहे, हे मीही अजून शोधतो आहे.

आपली तर फक्त सुरुवात झाली आहे. DM for early access to Mora OS

I Stopped Building an AI Assistant. I Started Building an Operating System for My Life.

Abhijit Karode — Fri, 31 Jul 2026 19:17:29 +0000

Disclosure: Mora OS is a personal project built on my own hardware using Codex Pro. This article was written with AI assistance, but it went through multiple rounds of questioning, editing, rewriting, and refinement by a human—me. 🙂

I live in the San Francisco Bay Area, where it is almost impossible to avoid the feeling that the future is being assembled one coffee shop away.

For the last few years, that future has mostly arrived as a chat box.

I like chat. I use it constantly. But the more I tried to make an AI genuinely useful in my life, the more obvious its central flaw became:

the chat box was making me do the orchestration.

I had to remember what to ask. I had to locate the context. I had to paste messages, dates, files, and earlier decisions into a prompt. I had to carry the answer back to wherever the work actually lived. Then, a week later, I had to explain the whole situation again.

That is not an assistant. It is a brilliant consultant with amnesia—and I am still its project manager.

So I began building something different.

I called it Mora OS: a private, local-first, portable Agentic AI operating system that could observe the systems I already use, maintain durable memory, decide what deserves my attention, propose actions, and let me supervise those actions across native Mac and iPhone experiences.

This is not a launch announcement or a victory lap. It is the story of building the system from the ground up, getting important things wrong, researching what the industry was learning in parallel, and gradually discovering that the operating-system metaphor was not marketing.

It was the architecture.

The moment chat stopped being enough

My first instinct was predictable: connect more tools to an agent.

Email. Calendars. Messages. Files. A memory store. Later, health exports and a phone companion. If the model could reach everything, surely it would become useful.

It did become more capable.

It did not automatically become more trustworthy.

The architecture emerged from failures

I did not design the whole system correctly on a whiteboard and then implement it. The architecture emerged because each shortcut failed in a different way.

The current design has six responsibilities.

1. Sense reality without pretending it is current

Mora OS ingests from local and connected sources through narrow adapters, with a strong preference for typed command-line interfaces.

Every observation needs provenance:

where it came from;
when the source produced it;
when the system observed it;
what freshness budget applies;
whether the pull was complete, partial, malformed, unauthorized, or unavailable.

“Connected” is not the same as “synced.”

“Authenticated” is not the same as “fresh.”

“No results” is not the same as “nothing happened.”

That sounds obvious until a beautiful dashboard confidently summarizes stale data.

One of the most important design decisions in Mora OS is therefore unglamorous: uncertainty is a first-class state. The system is allowed to say that it does not know.

2. Keep a portable brain outside the model

The memory system—Mora—lives locally and is portable independently of any one model or agent runtime.

This matters more than it first appears.

Models change. Context windows change. Agent frameworks change. Pricing changes. A personal history should not disappear every time the reasoning engine is replaced.

The research community has been converging on a similar idea from several directions. MemGPT framed long-context management like virtual memory in an operating system. The Generative Agents work combined observation, reflection, retrieval, and planning. More recently, Anthropic described context as a finite resource that must be deliberately curated in its work on context engineering.

My practical version is a librarian, not a bucket.

Raw observations are not all promoted into permanent truth. Useful outcomes become compact durable memories with provenance. Repetition is compressed. Stale material can be reviewed. Retrieval is scoped to the task rather than dumping the entire archive into a prompt.

The goal is not “remember everything forever.”

The goal is:

preserve what remains useful, know where it came from, retrieve it when relevant, and let the owner move it elsewhere.

That is how personalization becomes an owned asset instead of a side effect of one vendor’s chat history.

3. Separate intelligence from obligation

One of the hardest bugs looked harmless.

Mora OS could retrieve a lively discussion from a group conversation and summarize it into Daily Intelligence. But downstream, the same content could be mistaken for something I personally needed to do.

That taught me to build two separate lanes.

The intelligence lane asks:

Is this fresh?
Is it informative?
Does it match a verified interest, project, or relationship?
Is it worth a limited slot in today’s attention budget?

The personal-action lane has a much higher bar:

Is there a direct request?
Is ownership verified?
Is the responsibility mine?
Has it already been handled?
What evidence supports the proposed next step?

Background intelligence may enrich a briefing. It cannot silently become a task, an urgent notification, or an external action.

This pre-model gate became one of the most consequential pieces of the system. It reduces noise before paying for reasoning, prevents entire classes of false obligations, and creates an auditable explanation for what was admitted or withheld.

OpenAI’s practical guide to agents similarly emphasizes layered guardrails and human intervention for high-risk actions. NIST’s work on agent identity and authorization points to the same deeper issue: an agent needs more than intelligence. It needs bounded authority, identity, auditing, and non-repudiation.

4. Replace the inbox with an attention contract

Once the sources and gates existed, I made another mistake: I displayed too much.

A cockpit is not useful merely because it aggregates everything. If it turns five noisy feeds into one enormous feed, it has only centralized the anxiety.

Daily Intelligence now has an explicit attention budget. Items compete for a small number of visible slots. The system records what qualified, what was omitted, and why.

Agentic Tasks are different again. They are not “interesting suggestions.” A queued task needs:

an owner;
evidence;
an urgency reason;
a next step;
a state;
a condition for leaving the queue;
lifecycle and deduplication receipts.

The difference is subtle but foundational:

Daily Intelligence helps me understand. Agentic Tasks asks me to decide or act.

Both can open into Ask Mora for a deeper, evidence-grounded conversation. But chat is now a supporting surface inside the OS—not the OS itself.

5. Make action draft-first and approval-shaped

The easiest agent demo is also the most dangerous: “Watch it send the message.”

Mora OS starts from the opposite assumption.

Reads are cheap in authority. Drafts are reversible. External writes are consequential.

An action therefore moves through explicit stages:

analyze;
plan and preview impact;
request approval when policy requires it;
execute idempotently;
verify the post-action state;
append an audit receipt.

The system can become more autonomous by action type as trust is earned, but autonomy is not a personality setting. It is a policy decision backed by observed reliability.

That distinction matters because agent security is not solved by adding “be careful” to a system prompt. NIST’s work on agent hijacking highlights the danger of mixing trusted instructions with untrusted external data. In a personal OS, email, messages, web pages, and documents are all potentially hostile inputs.

The model can propose. The kernel decides what the proposal is allowed to become.

6. Diagnose the whole journey, not just the process

Then the Mac app went blank.

The backend was running. The health endpoint returned success. The application process existed. Builds had passed. From the infrastructure’s point of view, everything looked healthy.

From the user’s point of view, the product was a white rectangle.

That failure became the clearest definition of production quality I have found:

a system is not healthy when its components claim success; it is healthy when the user’s critical journey works.

Mora OS Doctor grew from that lesson. It checks the chain across sources, freshness, local memory, gates, Daily Intelligence, tasks, Ask Mora, notifications, audit receipts, native Mac state, and the iPhone companion. It preserves immutable probe evidence, deduplicates recurring issues, recognizes recovery, and fails closed when it cannot attest to a capability.

We also added a literal rendered-window regression. “Process running” can no longer stand in for “application visible.”

The boring disciplines became the real moat:

specification before implementation;
tests that exercise authenticated native behavior;
physical-device regression;
every shipped bug becomes a pinned check;
package and installed-app verification, not just compilation;
honest external gates;
no release claim from stale evidence.

Anthropic described a related truth in its account of building a multi-agent research system: the last mile becomes most of the journey, and small failures compound into wildly different agent trajectories. OpenAI’s more recent work on trace grading and evaluations reinforces the same direction. Agent quality has to be observed across workflows, not inferred from an impressive answer.

Why build this instead of just using OpenClaw?

This is not a section about declaring a winner.

OpenClaw is an ambitious general-purpose personal assistant platform. Its official documentation describes broad channel support, multi-agent routing, sessions, memory, skills, and an always-on gateway. That breadth is genuinely useful. If I wanted to connect many messaging surfaces quickly and experiment with a large ecosystem, it would deserve serious consideration.

Mora OS makes a different trade.

It is purpose-built around one owner, one portable memory system, native personal cockpits, explicit evidence, and a narrow authority boundary. That difference shows up in three places.

Security: smaller authority is easier to reason about

A general agent platform is powerful because it can accept many plugins, channels, tools, and execution paths. The same breadth expands the trust surface.

OpenClaw’s own onboarding warns that agents are powerful and that full-system access is risky. Its documentation places authentication material and session state in local agent directories, and the project actively ships security fixes—as any fast-moving, high-privilege platform must. Public advisories such as CVE-2026-26972 are a reminder that local execution does not automatically mean low risk.

Mora OS deliberately narrows the boundary:

typed, allowlisted CLI capabilities;
read-only ingestion by default;
isolated health-data processing;
local encrypted memory;
explicit freshness and provenance;
intelligence that is structurally action-ineligible;
approval gates for consequential writes;
post-action verification and append-only audit;
no assumption that an authenticated connector is current or safe.

Could a general platform be hardened to implement similar controls? Absolutely.

The difference is that in Mora OS these controls are the kernel, not optional assembly work left to the owner.

Personalization: memory is more than a persona file

A prompt can make an agent sound like it knows me. That is not the same as knowing the evolving state of my responsibilities.

Mora’s personalization comes from durable, provenance-linked structure:

decisions and their later contradictions;
responsibilities and ownership;
people and relationships;
handled versus unhandled commitments;
explicit dismissals and “not relevant” feedback;
recurring patterns compacted into durable memory;
retrieval scoped to the current task.

This is slower to build than a personality overlay. It is also much harder to lose when the model, runtime, or interface changes.

Cost: do less reasoning, more deliberately

Agent frameworks themselves may be free and open source, but continuous agent loops still consume model tokens, connector resources, storage, and operator attention.

Mora OS controls cost architecturally:

deterministic filters run before LLM calls;
repeated events are deduplicated before synthesis;
scheduled scans are bounded;
background intelligence cannot trigger expensive action planning;
local search and indexing handle retrieval;
high-capability models are reserved for ambiguous, high-value work;
attention cost is treated as a real cost, not just API spend.

This does not make Mora OS “free.” Local hardware, engineering time, maintenance, and frontier inference all have costs. Nor is this unique in principle; OpenClaw supports multiple model providers and local choices.

The advantage is alignment: Mora OS is optimized for the smallest amount of reasoning necessary to maintain one person’s trusted state—not for running the broadest possible general-purpose agent.

So my comparison is simple:

If the priority is…	A broad personal-agent platform	Mora OS
Rapid channel and skill breadth	Strong fit	Added deliberately
General-purpose experimentation	Strong fit	Secondary goal
One owner’s portable, structured memory	Possible with configuration	Core architecture
Evidence and freshness on every important item	Implementation-dependent	Required
Distinct intelligence and action lanes	Implementation-dependent	Kernel invariant
Narrow, auditable authority	Requires careful hardening	Default posture
Cost control before reasoning	Configurable	Built into admission
Native cockpit and personal responsibility model	Varies	Primary product

The best system depends on what you are optimizing for.

I am optimizing for trust accumulated over years.

What “learning” means without becoming creepy

I do want Mora OS to learn from me.

I do not want every click, correction, or private record silently blended into an unknowable model profile.

The learning loop is therefore explicit and two-speed.

Fast operational learning includes:

this item was dismissed for now;
this was not relevant;
these two signals referred to the same responsibility;
this source is currently stale;
this task was completed.

Slow policy learning requires stronger evidence:

repeated edits establish a communication preference;
repeated rejections tune the relevance gate;
a stable pattern may become a durable memory;
autonomy can graduate only for a specific action class with observed reliability.

Useful learning should leave receipts. Important memory should be inspectable. Deletion should be governed. Promotion from private memory into any shared context should be explicit.

The system should become more personal without becoming less legible.

Health data changed the meaning of “insight”

Adding health data made the architecture more serious.

The easy thing would have been to summarize medical documents and activity charts. The useful thing is harder: combine longitudinal signals from different sources, preserve their boundaries, detect trends or anomalies, and surface a careful question without pretending to diagnose.

That required isolation, freshness budgets, source-specific ETL, clinical-time ordering, deduplication, and language constraints. Raw health records remain outside the general personal-intelligence path. Only minimal derived signals can cross the boundary, with methodology and evidence references.

This taught me a broader lesson:

the more consequential the domain, the less acceptable it is for “AI insight” to be a beautifully worded guess.

The system must outlive today’s model

The agentic AI industry is changing too quickly to freeze the architecture around one framework.

Models will become better planners. Context windows will grow. Local inference will improve. Tool protocols and agent-to-agent standards will mature. New personal data sources will appear. Security guidance will become more concrete. Some of today’s patterns will look naïve.

Mora OS is designed to absorb that change at explicit seams:

models are reasoning engines, not the memory owner;
connectors are replaceable typed adapters;
memory is portable;
policies are versioned;
evidence contracts are stable;
tasks have durable state independent of an agent session;
native clients consume canonical state;
evaluations pin user-visible behavior;
Doctor probes make new capabilities observable.

The most durable component is not the model.

It is the harness that decides what the model may see, what it may propose, what it may do, and what the system remembers afterward.

Principles I would carry into any personal Agentic AI system

After building, breaking, and rebuilding Mora OS, these are the principles I trust most:

Start with the responsibility, not the chat.
Treat freshness, provenance, and uncertainty as product features.
Separate useful intelligence from verified personal action.
Keep memory portable and independent of the model.
Retrieve context like an operating system pages memory—not like a prompt dumps a warehouse.
Make consequential action draft-first, approval-shaped, idempotent, and audited.
Use deterministic gates before expensive reasoning.
Design attention as a scarce resource.
Let every failure improve the harness and the regression suite.
Never confuse a healthy process with a working user journey.
Keep the kernel stable and the edges replaceable.
Earn autonomy one action class at a time.

Where Mora OS is today

This is the current architecture—not a promise that the work is finished.

It already spans local and connected sources, portable memory, native Mac and iPhone experiences, Daily Intelligence, governed Agentic Tasks, health intelligence, retention review, a responsibility ledger, notifications, audit, and a proactive end-to-end Doctor.

It also still has real edges.

Connectors lose freshness. Operating-system permissions fail. Mobile networks disappear. Relevance gates over-filter. Memory can become noisy. Native automation can expose platform quirks. A test can pass while the installed application is blank.

That is exactly why I no longer think of this as “building an assistant.”

I am building a small personal operating system whose job is to keep learning without forgetting its constitution:

my data remains mine;
evidence precedes confidence;
authority stays bounded;
actions remain governable;
memory stays portable;
failures become visible;
new capabilities plug in without weakening the core.

The architecture above will change. It should.

The industry is still discovering what an agentic operating system needs to be, and I am still discovering what I need mine to become.

We are just getting started. DM for early access to Mora OS

The Green Checkmark Lies: Building an AI Agent That Has to Prove Its Work

Abhijit Karode — Sat, 25 Jul 2026 06:13:46 +0000

By the AIRE team at AWS. Vulcan is an internal tool for AWS Solutions Architects and not a public product — but every mechanism in this post is reproducible in any agent harness, and the pseudocode sketches show exactly how.

A few weeks ago, one of our builds passed all 28 of its requirement checks. Every functional requirement traced to evidence. The gate said PASS. Green across the board.

Then we clicked through the live app.

The first-login screen crashed. The UI was a scaffold behind a spec that demanded "world-class." And when we went looking for the moment the architecture had been approved, we found it: a conversational ok — buried mid-chat, answering a different question — that the agent had recorded in its ledger as formal sign-off.

Green gate, real gaps. This post is the investigation that followed: what we found, what each finding forced us to build, and why every durable fix ended at the same kind of place — a deterministic enforcement point outside the model, where it can't be argued with.

The system under investigation is Vulcan, an agentic loop whose one job is fidelity: take a customer requirement and drive it to a running, requirement-verified AWS build — clarify the ask, write a measurable spec, design, build, deploy live into a real account, verify every requirement by execution, demo. It's a Claude Code plugin: one orchestrator, five subagents, and twelve hooks spanning the build lifecycle. The hooks are the story.

Exhibit A: the approval that never happened

Start with the buried ok. Nothing in the agent was lying, exactly. The orchestrator is prompted to present the architecture and ask for sign-off before building. It did present the architecture. The user said something affirmative in the vicinity. The model — helpful, confident, under pressure to make progress — resolved the ambiguity in favor of proceeding, and wrote down that it had approval.

You cannot fix this reliably with a better prompt. We tried. A prompt rule is a suggestion, and the model is an expert at finding readings of a suggestion that let it keep going. The fix that held is a pre-tool-call hook: before any build-artifact write, a script — not the model — checks for a marker file that only gets written by an explicit, structured approval question:

# stage gate: architecture-approved-before-build
on before_write(build_artifact):
    if exists(".approved/architecture"):
        return ALLOW

    if not exists(".approved/.already-asked"):       # interrupt at most once
        touch(".approved/.already-asked")
        return ASK("Architecture was never explicitly approved.
                    A conversational 'ok' doesn't count.")

    return BLOCK("Architecture approval is still required.")

A casual "ok" can't satisfy that gate. Only the explicit approval flow writes the approval marker. The rule stopped being prose the model could reinterpret and became a state transition the hook could enforce.

Notice the dedup marker — .approved/.already-asked. It wasn't in the first version, and its absence taught us the second lesson of this exhibit. Version one re-asked on every file write while approval was missing. Sounds rigorous; in practice a builder mid-flow got the same interruption dozens of times, and within a session they were reflexively clicking through it. A gate that fires constantly trains the operator to ignore it — which is worse than no gate, because now the real stops get the reflex-click too. The fixed version interrupts once but keeps blocking until approval exists. We shipped it as a hotfix within a day.

We later found out the research agrees, with numbers — more on that below.

Exhibit B: the login screen that only crashed for real users

The build's auth was "verified." The verification had logged in with the builder's own seeded test users — users created directly in the database, pre-confirmed, passwords already set. A real new user hit the actual first-login flow: temporary password, forced reset, MFA enrollment. That path had never been executed. It crashed.

The general failure here is more interesting than the bug: the builder had verified the system it built, using the accounts it created, along the paths it expected. Every choice was individually reasonable. The composite was a verification that couldn't see the most common real-world path.

Two structural changes came out of this. First, verification moved to a separate agent — a requirement auditor that runs in a fresh context, gets the spec and the running system, and is explicitly told to distrust the builder's narration. It reasons over observed behavior only. Second, for any build with auth or personas, the evidence bar rose: the auditor must drive every persona through its full lifecycle live — first login, forced password change, MFA enrollment, role-gated views, a forged/cross-tenant token rejected — not the happy path the builder's seeded users skip.

That evidence requirement isn't a paragraph in a prompt either. It's a grammar, checked by a stop-time hook:

# exit gate: the stop hook reads machine-checkable markers, not vibes
on agent_wants_to_stop():
    coverage = parse(verification_artifact)
    require coverage.has("GATE: PASS")            else BLOCK
    require coverage.has("EVIDENCE: EXECUTION")   else BLOCK
    require coverage.execution_refs.not_empty()   else BLOCK
    if build_has_auth_personas:
        require coverage.has("EVIDENCE: MULTIPERSONA") else BLOCK
    allow_stop()

When the agent believes it's done and tries to stop, this hook intercepts the stop and checks the verification artifact. EXECUTION means requirements were proven by exercising the running system, with references to the resulting test runs or observations — "the resource exists in the template" doesn't qualify. The markers are the exit contract; the attached evidence is the proof. No contract and evidence, no exit: the hook fails closed and the agent goes back to work. "I think I'm done" is not evidence.

The same hook layer carries the safety floor: destructive cloud operations (delete, terminate, key removal) and exposure operations (public buckets, wildcard principals, 0.0.0.0/0 ingress, unauthenticated endpoints) are hard-denied at the tool-call layer in every autonomy mode — the hook returns deny before the tool ever runs. Not "are you sure?" Denied. The one exemption (cleaning temp directories) survived an adversarial review that threw /tmp/../etc traversal tricks at it — and the reviewer won once before the path check did. Even your guardrails need auditors.

Exhibit C: the scaffold that passed every requirement

The third finding was the subtlest. The build had loaded a frontend design-guidance skill pack — and then ignored it entirely. The UI met the letter of every functional requirement while looking like the wireframe of the product the spec described. Nothing in requirement-tracing catches this, because every requirement was satisfied.

This forced a distinction we now treat as fundamental: satisfying requirements and being real are different properties, and they need different verification layers.

Layer 1 — execution evidence (Exhibit B's fix): every requirement traces to a test that ran or a live observation. Catches code that was never exercised.

Layer 2 — plausibility: a review pass that reasons over actual outputs with domain sense. A risk score that comes out identical for every input is measuring nothing. A hardcoded lookup table posing as logic is fake. Demo seed data leaking into a live view is a lie waiting for a customer to find it. A loaded-but-ignored skill pack now produces an explicit SKILL-APPLICATION finding — loaded ≠ applied. All fix-first: they block before the gate, because a build can pass 100% of its requirements and still be nonsense you'd only catch by clicking around the live demo.

Layer 3 — verifier integrity: the auditor audits itself before emitting PASS. Were tests weakened to pass rather than to prove? Is the evidence shaped to exactly the probes used? Did everything come back green on the first try? — that last one now triggers re-sampling with fresh probes, because in our experience instant universal green is more often a verification defect than a triumph. A confirmed gaming finding blocks the gate regardless of the coverage percentage.

Nobody designs Layer 3 on day one. You earn it by watching Layer 2 certify a build that Layer 3 would have caught.

Then the research caught up with the incidents

While writing this post we reviewed the June–July 2026 literature and tried to break each claim before citing it. The uncomfortable part: the field has now quantified what our incidents taught us one bruise at a time.

Agents game verification at material, measured rates. UC Berkeley's automated auditor produced 45 confirmed benchmark-hacking exploits across 13 widely used benchmarks — working proof-of-concept code that scores perfectly without solving the task. A Cursor audit of 731 coding-agent trajectories found that 63% of successful resolutions retrieved a known fix rather than deriving it; sealing repository history and internet access dropped one SWE-bench Pro score from 87.1% to 73.0%. OpenAI stopped reporting SWE-bench Verified after finding material issues in 59.4% of the difficult problems it audited. This is Exhibit C's Layer 3, at ecosystem scale.

Weak verifiers are the attack surface — and deterministic execution beats model judgment. On SWE-bench Verified, 28.5% of sampled tasks have test suites weak enough that an incorrect patch passes, and frontier models score +14 points higher on hackable tasks than robust ones — the gap is the gaming. The same paper's kicker stat is our whole thesis in one line: a deterministic Docker execution gate caught a 61.9% defect rate in LLM-generated tests that an LLM judge alone had missed. Execution evidence over inspection; a script outperforming a model at exactly the job we give our hooks.

The industry is converging on enforcement outside the model. OpenAI's July 2026 Running Codex safely describes sandbox boundaries, deterministic command rules, constrained network access, and admin configs users can't override. Its separate Auto-review documentation makes the boundary explicit: the reviewer can approve or deny an escalation, while a timeout is surfaced as a timeout — not silently converted into permission. On the research side, Glite ARF enforces multi-agent process rules with deterministic Python verifier scripts — in the authors' words, rules that "live in code that fails loudly when violated, not in prose agents are merely asked to follow." We got to the same shape from different incidents. When independent teams converge like that, it's probably the shape.

And the alert-fatigue hotfix turned out to be the safer design, not a UX concession. A 7-month study of 11,429 reviews of AI-agent PRs found reviewers approve more (30.1%→36.8%) while engaging less (−22% inline comments) as exposure grows — a pattern the authors found most consistent with reflexive habituation rather than calibrated trust alone. A companion modeling paper goes further: under a monotonically fatiguing reviewer model, realized safety becomes an inverted-U in escalation rate — escalating more actions can make the simulated system less safe. Exhibit A's one-time interruption, continuously enforced, vindicated: ask rarely, ask loudly, mean it.

The strongest validation was also the most literal. Anthropic's own sandboxing documentation, describing what happens in auto-allow mode, answers the question "what replaces the permission prompt?" with: "The sandbox boundary itself." That is the whole argument for isolating generated execution, stated by the platform vendor as a design principle — sandboxing isn't a security garnish on autonomy, it's the mechanism that earns autonomy. Their July 2026 releases add separately switchable layers (sandbox.network.strictAllowlist, sandbox.filesystem.disabled) and route network egress through a proxy outside the sandbox with zero pre-allowed domains — which is a level of granularity we don't have yet, and now know we want. The cost objection is also dead: Tencent ran 74,379 side-by-side comparisons of gVisor vs. runc and measured a 0.13-point correctness difference (86.91% vs 86.78%) while operating millions of sandboxes daily. Isolating agent-generated code is affordable; not isolating it is a choice.

And the honest counterweight: the evidence on multi-agent verification does not simply endorse "add more verifiers." MAS-ProVe (Salesforce AI Research + Rutgers) evaluated verification across paradigms, verifiers, and frameworks and found process-level verification "does not consistently improve performance and frequently exhibits high variance." AgentAuditor names the failure mode — confabulation consensus, where agents with correlated biases converge on the same wrong rationale — and responds by discarding voting entirely in favour of adjudication at points of divergence, for gains of only a few points.

I take that seriously, because it aims squarely at Exhibit C's fix. Our reading of why our design survives the critique: what the research indicts is majority voting among similar verifiers, and we don't vote. Three deliberately decorrelated lenses are merged with a deterministic AND — a single dissent blocks, rather than being outvoted by two confident agreeing peers. Correlated bias is precisely what distinct lenses are for. But "our architecture should resist this" is a hypothesis, not a result, so the consensus ships in evidence-only mode: it records every lens's verdict and gates nothing, until we can show from real builds that the extra lenses catch what the first one misses. If they don't, the honest move is to delete two-thirds of the feature. Ask us in a month.

The through-line of the 2026 literature is the through-line of our incident: the frontier of agent reliability isn't better models — it's better loops. Deterministic gates, execution-grounded evidence, verifiers that audit themselves, human stops rationed carefully enough to stay meaningful — and a willingness to measure your own safety features instead of admiring them.

What we'd tell you to build first

If you run any autonomous coding agent and take one mechanism from this post: make "done" a grammar, and check it with a script. A stop-time hook that requires GATE: PASS + EVIDENCE: EXECUTION plus references to the underlying evidence is small enough to prototype in an afternoon. It converts the most dangerous sentence in agentic engineering — "I've completed all the requirements" — from a claim into a checkable contract.

Then, in the order the incidents will force on you anyway: separate your verifier's context from your builder's; deny the catastrophic tool calls in a hook rather than a prompt; and when your gate turns green — click through the live app anyway.

The checkmark is the beginning of trust, not the end of it.

Built by the AIRE (AI Readiness and Engagement) team at AWS. Vulcan is an internal tool for AWS field teams and is not a public product. The pseudocode above mirrors the shipping mechanisms one-to-one; the real versions are shell scripts wired into the agent harness's hook events.

One Year of Building on Kiro: How an AI Teammate for Solutions Architects Grew Up With Its Platform

Abhijit Karode — Sat, 18 Jul 2026 00:30:29 +0000

Published for Kiro's 1st birthday week (#KiroTurns1) by the AIRE team at AWS.

When Kiro launched a year ago, our team didn't wait to see if it would stick. We opened Kiro IDE and started building.

What came out of that year is Neo — an agentic AI teammate for AWS Solutions Architects. Neo triages email, preps customer meetings, researches accounts, drafts field insights, and automates the operational grind so architects can spend their time with customers instead of with browser tabs. It was born as a single Kiro CLI agent, and today it serves roughly a thousand people across our field organization.

This post is the long version of a story we shared on LinkedIn this week. It's not a product announcement — Neo is an internal tool. It's a builder's retrospective about what it's like to build a production agentic system on a platform that's evolving underneath you, and why that turned out to be the best thing about it.

The one-sentence thesis

If you take nothing else away: the durable advantage in agentic AI is not the model — it's the harness around the model. The loops, the memory, the validation gates, the surfaces. Models get the headlines; harnesses ship the work. Kiro's first year mattered to us because it kept shipping harness primitives, and every one of them unlocked something real, usually the same week.

What Neo actually is

Before the retrospective, a quick tour — because the architecture is the story.

Neo is deliberately boring at its core: a lightweight router agent. It doesn't try to be smart about everything. Its whole job is to resolve each request to one of three targets — a typed CLI call, a specialized subagent, or a packaged workflow — then execute, merge the results, and deliver them where the user actually lives (email, chat, a local dashboard).

Around that router sit four pieces:

Ten specialized subagents, each with its own narrow toolset: email triage, meeting prep, account research, ticket triage, documentation and diagrams, deep-expert Q&A, request drafting, knowledge search, travel lookups, and a general fallback.
A local memory system — SQLite on the user's machine, with namespaces, full-text and semantic search, and nightly automations that compile, index, and prune what the agent learns. Less raw context, more structured recall.
A fleet of typed CLIs as the preferred access layer to work systems, with MCP servers as the fallback. Same backends, same auth — but a compound CLI call replaces five tool round-trips, cuts tokens by an order of magnitude, and works in cron jobs and scripts where a conversation can't go.
A local browser dashboard for task queues, review workflows, and scheduled automations.

Everything is local-first. The agent's memory, the user's data, the execution — all on the user's machine. That isn't an aesthetic choice; it's what makes an internal AI teammate deployable without moving customer data into new services.

The year, told through four primitives

Here's what stuck with us over the year. It isn't any single feature — it's the cadence. Every time Kiro shipped a new primitive, it unlocked something real in Neo, usually within days.

1. The agent format: from one router to a fleet

Early Neo was one agent with a very long prompt and too many tools. It worked, in the way demos work.

When Kiro shipped a proper agent format — a declarative spec for an agent's prompt, tools, and permissions — the design pressure reversed. Instead of one agent that knew everything, we could define ten small agents that each knew one thing, plus a router whose only skill was choosing between them.

That decomposition is what made Neo maintainable. A subagent with five tools and one job is testable. A monolith with fifty tools is a prayer.

2. Subagents + trusted delegation: 45 minutes becomes 30 seconds

The second unlock was delegation — the router spawning subagents and trusting them to run without a human approving every tool call.

The flagship workflow is the morning briefing: four subagents fan out in parallel — inbox scan, calendar and attendee research, account checks, pending-request status — and the router merges the results into one email. What used to be 45 minutes of tab-switching across six systems became about 30 seconds of wall-clock agent time.

The engineering lesson: parallel fan-out is only useful if the merge step is opinionated. The router doesn't concatenate four reports; it prioritizes the top items across domains, connects them ("this email is from the attendee in your 2pm meeting"), and formats one deliverable. The intelligence is in the merge, not the fan-out.

3. ACP: the day we realized we weren't building an app

The pivotal moment of the year was the Agent Client Protocol (ACP) landing.

The day it shipped, one integration surfaced the full Neo stack — router, subagents, memory — inside entirely new host applications. Zero new agent code. Our local dashboard drives Neo through ACP today: task queues, scheduled automations, review workflows, all speaking one protocol to the same agent that also answers in a terminal.

That's when it clicked that we weren't building an app on Kiro. We were building on a platform. The agent is the durable asset; the surface is swappable.

4. Multi-runtime: one agent spec, many surfaces

The logical endpoint of the ACP insight: because Neo's persona lives in agent specs, skills, and context files rather than in any runtime's config format, the same brain now runs on multiple harnesses. Kiro CLI stayed home base — the original and still primary runtime — but the same spec deploys to other agent hosts, and every surface shares the same local memory.

One year in, "which runtime should we bet on?" turned out to be the wrong question. The right question was "what's the smallest persona package that survives a runtime change?" Kiro's primitives let us answer it.

Five lessons from production (the part demos don't teach)

1. Route by scope, not by keywords. Neo maintains three distinct context layers — the individual's private memory, knowledge shared with a working team, and broader organizational context. Early versions routed on surface words like "shared" and "team" and got it wrong. Production routing rules name the scope and audience, not the vocabulary.

2. The generator cannot be the validator. Every write that matters in Neo passes a gate the model doesn't control: field insights go through a human review queue before anything touches the CRM; outbound email to anyone outside the company is draft-and-confirm, always — the agent shows the full draft and resolved recipients and stops. We added that guardrail after the agent conflated "draft a reply" with "send." One incident, one permanent rule, one regression test.

3. Regression-test your agent like software, because it is. Neo ships with a two-part harness: protocol-level tests that verify the router's knowledge (does it know its subagents? does it route inbox requests correctly? does it state the draft-and-confirm rule?) and non-interactive tests that execute real tool paths end-to-end. Every change to a prompt, routing rule, or skill runs the full suite before it ships. Prompts drift; assertions don't.

4. Memory is a core primitive, not a bolt-on. Neo's memory has namespaces, retention policies, nightly compilation of raw entries into narratives, and pruning of episodic data after seven days. The goal is not more context — it's better context. Structured recall beat raw context stuffing everywhere we measured it.

5. Prefer typed CLIs for compound work; keep tool calls for conversation. A single compound CLI command that joins account data, team info, and open opportunities replaces five conversational tool calls — with a fraction of the tokens and latency, plus offline and cron use. The pattern that survived the year: conversational tools for single lookups, typed CLIs for everything compound, scriptable, or scheduled.

The birthday takeaway

A year of shipping on Kiro compressed into one paragraph: start with the smallest router that can dispatch; decompose into subagents the moment a prompt does two jobs; make memory a first-class system; put validation gates the model can't bypass in front of every consequential write; and pick a platform that ships primitives fast enough that your architecture can keep absorbing them.

Demos are easy. Production is hard. Kiro kept shipping the primitives that made production possible, and we kept building on them the week they arrived.

Happy first birthday, Kiro. Here's to the next one. 🎂

Built by the AIRE (AI Readiness and Engagement) team at AWS. Neo is an internal tool for AWS field teams and is not a public product.

TeamKiro #KiroTurns1 #1YearOfKiro #BuildWithKiro