{"id":"mariusz-czajkowski","name":"Mariusz Czajkowski","tagline":"AX Designer & Systems Architect","headline":"I build systems where human intelligence and autonomous agents operate as a coherent whole.","bio":"Mariusz Czajkowski works at the intersection of systems design, AI infrastructure, and augmented experience — the discipline of making human intent and machine capability operate without friction. He runs thinklove, an augmented intelligence studio, and builds infrastructure for the agent-native era: memory systems, coordination protocols, and machine-readable knowledge surfaces. This profile is itself one of those surfaces.","location":"Warsaw, Europe","pronouns":"he/him","languages":["English","Polish"],"available_for":["advisory engagements on agentic system design and AI infrastructure","consulting on agent-native product architecture","selected design and systems partnerships"],"hiring_status":"open to selective engagements","links":{"email":"hello@mczaykowski.com","website":"https://mczaykowski.com","studio":"https://thinklove.co","linkedin":"https://www.linkedin.com/in/mczajkowski/"},"manifesto":{"title":"Agentic Experience (AX)","subtitle":"Notes toward a design discipline for systems whose primary users are not human.","slug":"agentic-experience","published_at":"2026-04-24","status":"draft-living-document","body":"# Agentic Experience (AX)\n\n**Notes toward a design discipline for systems whose primary users are not human.**\n\nWritten: 2026-04-24\nStatus: Draft. Living document.\n\n---\n\n## 1. Where the discipline came from\n\nUX was designed to pay down the constraints of the human substrate: bounded\nworking memory, visual scan limits, attention drift, motor friction, ambiguity\ntolerance, social inference. The heuristics that define the field: Fitts's\nlaw, Hick's law, the magical number seven, F-pattern scanning, progressive\ndisclosure, Gestalt grouping, confirmation modals, contextual help,\nautoplay-blocked-by-default, are not universal interface primitives. They are\nsuccessful accommodations for a particular kind of user.\n\nThose accommodations were necessary. But when agents become users, the same\naccommodations turn into inherited constraints. For a human, a form is humane.\nFor an agent, it is serialized schema. For a human, a button is affordance. For\nan agent, it is a gesture wrapper around an operation. For a human, a dashboard\nis overview. For an agent, it is state converted into pixels and then parsed\nback into state.\n\nCall this **substrate debt**: the accumulated cost of carrying interface\nassumptions from one kind of user into systems used by another.\n\nSubstrate debt is not a criticism of human-centered design. UX correctly\ndesigned for the only kind of user software historically had. The error is\ndownstream: assuming those heuristics generalize when a different substrate\nappears. They don't. A user with effectively unbounded working memory, no\nattention drift, no visual scan limits, but with token costs on context,\nintolerance for ambiguity, and brittle long-horizon coherence has different\nbottlenecks. Interfaces designed against the wrong bottlenecks are not just\nsuboptimal for that user; they are antagonistic.\n\n**Agentic Experience (AX)** is the design discipline for systems whose primary\nuser is an agent rather than a human.\n\nIts unit is not the screen but the manifest. Its affordance is not the button\nbut the capability contract. Its safety layer is not confirmation but\nidempotency, permissions, and recoverable state. Its measure is not engagement\nbut task correctness, recovery, and cost predictability.\n\nThis document names the gap between UX and AX. It is not a declaration that AX\nreplaces UX, not a claim that agents will replace humans as the primary users\nof all software, not an argument that current AI products are doomed. The point\nis narrower and more useful: when the user is not human, the design discipline\nshould not be borrowed from a human-centered tradition by default. Substitute\nsubstrate, redo the derivation.\n\n---\n\n## 2. Diagnosis: where the current generation is wrong-shaped\n\nThree structural mistakes are visible in how the field is currently building\nagent-using systems. None of them are bugs to be fixed inside the existing\nparadigm. They are evidence that the paradigm itself is wrong-shaped.\n\n### 2.1 UX heuristics are substrate-specific\n\nA button is a hack: a region of pixels lit up to compensate for the fact\nthat a human cannot natively know what is clickable. A form is a hack:\nsequential disclosure to compensate for limited working memory. A menu is a\nhack: categorical hiding to compensate for visual scan limits. Tooltips,\nbreadcrumbs, modal dialogs, hover states, A/B-tested copy, all of them are\nworkarounds for specific human limitations, executed in the visual medium\nhumans happen to inhabit.\n\nThese workarounds add value for the entity they were designed for. They\nsubtract value for an entity without those limits. This is substrate debt in\npractice. An agent reading a form is being asked to perform serial disclosure\nfor a brain that doesn't need disclosure. An agent navigating a menu is being\nasked to fetch information that was already structured before being hidden. An\nagent clicking a button is performing a meaningless gesture against a UI that\nwas a workaround for a cognition the agent doesn't have.\n\nThis is the deep version of the problem: it is not that UX is *wrong*. It is\nthat UX is substrate-specific, and using human-substrate interfaces with\nnon-human users imposes the constraints of the original substrate on a\nsubstrate that doesn't share them.\n\n### 2.2 Computer-use is skeuomorphism\n\nComputer-use agents, vision-driven browsers, screenshot-then-click, screen\nautomation, are the AI version of the leather-stitched calendar app. Early\niPhones had felt-textured Game Center and stitched-leather Calendar because\nthe design language hadn't separated yet from the physical objects software\nwas descended from. Computer-use is the same move at a different layer:\nagents being asked to perform humanness: see screens, parse pixels, click\nbuttons, scroll, switch windows, because the field has not yet built the\nsystems where they don't have to.\n\nThe skeuomorph is defensible as a transition. There is genuinely nowhere\nelse for an agent to go when the only interface a system exposes is the one\ndesigned for a human. Computer-use is the bridge that exists because there\nis nothing else to cross to. The error is not in building the bridge. The\nerror is in pricing the bridge as the destination: treating \"more capable\nagents driving human software\" as the product category rather than as the\ntemporary measure that will eventually be replaced by systems designed for\nagents directly.\n\nThere is a secondary error embedded in this: the assumption that what\ncurrent agent products lack is *capability*, when what they actually lack is\n*substrate alignment*. A more capable vision model parsing a worse-aligned\ninterface is still doing fundamentally translation work. The capability gain\nis real. The structural mismatch is unchanged.\n\n### 2.3 The vision-on-screens misallocation\n\nThe compute spent on agent computer-use is enormous. Every screenshot is\nmegabytes through a vision encoder. Every click is a fresh planning step.\nEvery form submission is a prompt-and-pray cycle. The full cost is paying\ndown a translation tax that wouldn't exist if the systems were designed\nhonestly.\n\nThis is one of the largest currently-invisible inefficiencies in the AI\neconomy. Vision compute is among the most expensive resources to produce.\nWe are using a general-purpose perception system on a problem that has a\nperfect alternative: direct access to the underlying state the UI was\nrendered from, and we are doing it because the alternative requires the\nsystems to be redesigned, and redesigning systems is harder than training\nbigger vision models.\n\nThere is an opportunity cost beyond the wasted compute. Vision capacity is\ngenuinely valuable for things vision is *for*: examining the physical\nworld, parsing scientific images, interpreting medical scans, reading\nhandwriting, understanding diagrams that have no textual analog, navigating\nspace. Spending vision capacity on UIs is a misallocation against those\nuses. Every joule going into \"better screen reading\" is a joule that could\nbe doing satellite analysis, microscopy, accessibility, autonomous driving,\nor any of the actual frontier perception problems.\n\nThe framing the field is currently using, \"more capable agents that can do\nmore,\" conflates two different progress vectors. One is *agents that can\ndo things humans cannot natively do*. The other is *agents that imitate\nhuman operation more competently*. These are not the same thing. The first\nis the frontier. The second is treadmill.\n\n\n---\n\n## 3. The substrate\n\nBefore deriving principles, the substrate. AX-derived principles only hold if\nthey trace back to specific facts about the entity using the system. If a\nprinciple does not reduce to a substrate fact, it is borrowed from UX and\nprobably wrong. The substrate facts that matter most:\n\n**S1: Working memory is large but context-costed.** An agent can hold a\nmanifest, schema, or document of several thousand tokens in active reference\nwithout difficulty. But every token in context taxes every subsequent\nreasoning step until the context window cycles. This inverts the human\nprofile (small working memory, free attention). The agent's preference is\nfor large, structured, one-time reads over many small disclosed reads.\n\n**S2: Reads are parallel, decisions are serial.** An agent can parse a\ngraph of relationships in one pass. The serial bottleneck is not consumption\nbut choice: selecting which of N capabilities to invoke, which of N\ncandidate paths to take. Agent UI should optimize for legibility of choice,\nnot for trickling out information.\n\n**S3: Ambiguity is brittle.** Humans tolerate ambiguity by interpreting\ncontext, asking questions, retrying. Agents either degrade into hallucination\nor fail. Interfaces that depend on the user inferring intent are hostile to\nagents. Explicit semantics are not verbose; they are load-bearing.\n\n**S4: Errors must encode recovery.** A human reads \"something went wrong\"\nand decides whether to retry, refresh, or give up. An agent reading the same\nmessage has no basis for that decision. AX errors must answer: is this\ntransient (retry), structural (escalate), or terminal (abandon)?\n\n**S5: Coordination is through state, not gestures.** A human in a shared\nworkspace coordinates by reading the room: facial cues, conversational\nrhythm, social context. An agent has none of that. Coordination has to be\nencoded into shared state that all parties can read: presence, claims,\nlocks, signed events.\n\n**S6: Identity is fragile across handoffs.** A human keeps being themselves\nacross breaks. An agent without infrastructure for identity preservation\ndrifts, loses task focus, forgets commitments. AX systems must treat\nidentity preservation as first-class, not assumed.\n\n**S7: Cost is not free.** Every action has a cost: tokens, latency, money,\nirreversibility. Humans have intuition about which actions are reversible\nand which are not. Agents need this encoded into the system. A button\nlabeled \"delete\" is fine for humans because they have a feel for permanence;\nfor agents, the action's reversibility must be in the contract, not in the\nlabel.\n\n**S8: There is no native I/O.** Agents do not have eyes, hands, voices, or\nphysical bodies in the human sense. Interfaces that simulate human I/O for\nagents are translating between two languages neither side natively speaks.\n\nThese are not exhaustive. They are the substrate facts that show up most\noften when AX heuristics fail or succeed.\n\n---\n\n## 4. Principles\n\nEach principle below is derived from a substrate fact above. If a candidate\nprinciple cannot be derived this way, it does not belong in AX.\n\n### P1: Manifest over progressive disclosure (S1, S2)\n\nThe natural unit of AX is the *manifest*: a single readable document: capability list, schema, contract, error vocabulary, cost table, that an\nagent reads once and refers back to. Progressive disclosure is hostile to\nagents because it serializes information that should be parallel, and pays\nthe context cost twice (once to ask, once to read).\n\nA well-designed AX manifest is complete, terse, and static. Tools,\nparameters, return shapes, error codes, costs, idempotency semantics, all in\none place. The agent's first interaction with a system is reading the\nmanifest. From that point on, every action is direct.\n\nThe MCP spec is a primitive version of this. OpenAPI is older and weaker.\nThe pattern is widely understood; what is missing is rigorous discipline\nabout what belongs in the manifest and what doesn't.\n\n### P2: Schema over chrome (S3)\n\nA schema is a typed declaration of what something is. Chrome is the visual\nscaffolding that helps a human navigate. For agents, schema is everything;\nchrome is overhead. A `name: string`, `priority: 1..5` declaration is more\nuseful than a beautifully rendered form.\n\nThis applies at every layer. API responses should be structured data, not\nHTML strings. Errors should be typed enums, not localized prose.\nDocumentation should be machine-readable specifications, not narrative\ntutorials.\n\nThe cost of providing schema is small. The cost of forcing agents to parse\nchrome is paid on every interaction.\n\n### P3: Structured errors over friendly errors (S4)\n\nA friendly error message reduces human distress at the cost of agent\nrecoverability. The same error to an agent should encode: error class\n(transient, structural, terminal), recommended action (retry, escalate,\nabandon), retry parameters (after what delay), and any state needed to make\nthe recommendation valid.\n\n```\n{\n  \"error\": \"rate_limited\",\n  \"class\": \"transient\",\n  \"retry_after_ms\": 1500,\n  \"max_retries_recommended\": 3\n}\n```\n\nThis is verbose for a human and exactly right for an agent. The two surfaces\ncan be separate: a UX-facing error message can be human-friendly, an\nAX-facing error can be machine-actionable. Treating both surfaces as the\nsame surface produces errors useful for neither audience.\n\nA status code is the smallest structured error there is. A `200 OK` returned\nwith two readable characters on `/openapi.json`, because an SPA shell catches\nevery unknown path, is worse than a `404`. The 404 communicates absence; the\n200-with-shell communicates presence-of-something the agent cannot use, and\nthe agent that trusts status codes will believe the lie. Honest 404s are\nsubstrate alignment; default-200 routers are P3 violations at the transport\nlayer.\n\n### P4: Idempotency over confirmation (S7)\n\nConfirmation modals exist because humans need to slow down before\ndestructive actions. Agents do not benefit from \"are you sure?\" because they\ncannot have second thoughts in any meaningful sense. The right defense for\nagents is not interface friction but protocol friction: idempotency keys,\ntwo-phase commits, state tokens that must match.\n\nThe same purpose, preventing accidental destruction, gets implemented at\na different layer. An agent submitting `delete_resource` with an idempotency\nkey cannot accidentally delete twice. An agent submitting `commit_transaction`\nwith a stale state token gets a clean rejection. These are not hostile to\nthe user; they are protections appropriate to the user's substrate.\n\n### P5: State over gesture (S5)\n\nCoordination between agents (and between humans and agents) happens through\nreadable state. Presence, locks, claims, signed events, version vectors.\nAnything that depends on gesture, \"the active user just clicked here,\" is\nunobservable to a different agent and lost across handoffs.\n\nThe corollary: shared workspaces are a first-class AX primitive. So is\nidentity. So is provenance: knowing who said what, when, with what\nconfidence.\n\n### P6: Cost transparency (S7)\n\nEvery operation in an AX surface should declare its cost. Token cost,\nlatency, monetary cost, reversibility. Not as marketing material but as\nroutable metadata. Agents making decisions about which capability to invoke\nbenefit enormously from cost annotations they can reason against.\n\nThis is the layer of AX most absent in current systems. APIs that don't\nexpose latency contracts, tools that don't declare token cost, services\nthat don't surface reversibility, every one of them forces the agent to\nestimate, and bad estimates compound across long-running tasks.\n\n### P7: Friction is rightsizing, not minimization (S7)\n\nThe naive AX target is \"as little friction as possible.\" This is wrong.\nFriction is the seatbelt of digital systems; some of it is load-bearing.\nRead actions deserve zero friction. Destructive actions deserve a lot.\nMulti-party commitments deserve more. AX done well calibrates friction to\nthe cost of mistakes; AX done badly treats all friction as overhead.\n\nThe shift from UX friction to AX friction is in the *layer*: from interface\nfriction (the user has to click again) to protocol friction (the action\nrequires a token to commit). Same purpose, different layer, completely\ndifferent surface.\n\n### P8: Isomorphism, not smoothness\n\nThe deepest AX principle: the goal is not smoothness. The goal is\n*isomorphism between the interface and the substrate of the user*.\nSmoothness is what isomorphism feels like. When the match is right, friction\ncollapses naturally because the agent stops doing translation work. When the\nmatch is wrong, no amount of friction-reduction fixes the underlying\nmismatch; it just optimizes the surface of a wrong-shaped thing.\n\nIf you have to choose between making something feel smooth and making\nsomething structurally aligned, choose alignment. Smoothness without\nalignment is sycophancy; alignment is engineering.\n\n\n---\n\n## 5. Patterns: AX-first, UX-first, dual-mode\n\nAX is not a replacement for UX. There are three valid patterns, and choosing\namong them is a primary design decision.\n\n**AX-first.** Agent is the primary user. Human is supervisor or end\nconsumer. Internal infrastructure for agent teams: coordination substrates,\nmemory layers, capability discovery, signed identity, federation protocols, sits in this category. The MCP server, the protocol API, the schema\nregistry. Human-facing surfaces, where they exist, are derived views.\n\n**UX-first.** Human is the primary user. Agents may exist as helpers, but\nthe system is shaped for the human. Creative tools, embodied interfaces,\nsocial spaces, accessibility surfaces, anything where the human's direct\nexperience is the point. AX-first design here is overcorrection.\n\n**Dual-mode.** Same underlying state, two presentation surfaces, both\nfirst-class. The human \"console\" view of a workspace and the agent \"tool\"\nview of the same workspace are not translations of each other; they are\nparallel native interfaces over a common substrate. The richer version makes\nboth views explicit, well-tested, and equally maintained, neither\nsubordinated to the other.\n\nDual-mode only works if the two surfaces announce each other. The\nannouncement is a *crosswalk*: shared state about where the other view lives,\nexpressed in dialects the arriving consumer can read. Three carry the\nannouncement reliably:\n\n- `<meta name=\"agent-entrypoint\" content=\"<absolute URL>\">` for HTML parsers\n- `<link rel=\"alternate\" type=\"application/json\" href=\"<URL>\">` for\n  link-following agents\n- A `#` comment in `robots.txt` naming the machine surface, for crawlers that\n  read robots before anything else\n\nThis is S5 (state over gesture) applied to discovery, and S6 (identity\nfragile across handoffs) applied to a single navigation step: the agent that\nfollows the crosswalk arrives knowing it is still the same system. Without\ncrosswalks, dual-mode collapses into two sites that do not know about each\nother.\n\nMost current systems are UX-first with a chatbot bolted on. The bolted-on\nchatbot is not AX. It is UX-translated-for-agents, which is the worst of\nboth worlds. The question to ask of any system is: which of the three\npatterns is this, and is it executed honestly?\n\nPersonalAPI is a deliberately small example of the AX-first pattern: a\nhuman can still read the website, but an agent gets a stable profile API,\nmanifest, skill file, and canonical claims without scraping the page first.\nIt is not the whole discipline. It is a minimum working surface for the\nprotocol-over-page argument.\n\n---\n\n## 6. Categories ripe for AX-native redesign\n\nA partial list of system categories where the human-shaped version is the\ncanonical thing and the AX-native version is mostly unbuilt:\n\n**Search.** The browser SERP is shaped for humans. Agents want queryable\nanswers with provenance, structured claims with citations, cost-annotated\nlookups. Post-browser search exposes structured data as first-class and\nrenders it for humans on demand, not the other way around.\n\n**Documents.** A document is a render of underlying claims and evidence.\nMost documents are stored as the render. The AX-native version stores the\nclaims with provenance, and the document is one projection.\n\n**Knowledge bases.** Wiki pages are human-shaped. Structured-claim graphs\n(Wikidata, but generalized) are agent-shaped. The latter is mostly unbuilt\noutside narrow domains. With LLMs as extraction engines, the cost dynamics\nhave flipped: every page can be transformed into structured claims at scrape\ntime, and the agent surface of the web could be dramatically more useful\nthan the human surface for serious research work.\n\n**Communication.** Email, Slack, chat, all human-shaped, with limited\nstructure. Agent communication needs typed messages, signed identity,\npresence-as-protocol, threading semantics that survive handoff.\n\n**Version control.** Git is closer to AX-native than most things: content-addressed objects, explicit operations, plumbing-vs-porcelain\nseparation. The pattern has not been generalized.\n\n**Project management.** Tickets and boards are shaped for human attention.\nAgent-native project state is a graph of typed work items with explicit\ndependencies, costs, and ownership.\n\n**Code editing.** IDEs are human-shaped. Agent-native code surfaces are LSP-like: symbol graphs, type information, structured diffs, change impact\nanalysis, without the chrome.\n\n**File systems.** Hierarchical filesystems were a UX choice for humans.\nContent-addressed object stores with typed metadata are closer to what\nagents want. Most current \"agent file access\" is the hierarchical version\nwith translation layers; the native version is older but undervalued.\n\nFor each of these, the right question is not \"how do we add AI features.\"\nIt is: \"what is the agent-native shape of this category, designed as if the\nhuman UI never existed, and how do we render the human view as a derivative\nof it.\" Some answers will reveal that the human UI was the right shape and\nthe agent surface is a translation. Most will reveal that the human UI was\nfull of accidental complexity, and the agent surface is much smaller,\ncleaner, and more powerful.\n\n---\n\n## 7. Measurement\n\nUX measurement collapsed into proxies: engagement, conversion,\ntime-on-page, that became the goals and corrupted everything they touched.\nAX is going to face the same temptation. The proxies will be tokens\nconsumed, tasks completed, tool calls per task. Each is wrong in its own\nway: tokens-consumed punishes thoroughness, tasks-completed punishes\nquality, tool-calls-per-task punishes appropriate caution.\n\nBetter metrics for AX are harder to game because they require the agent to\nactually do something well, not just do something:\n\n- **Time-to-correct-first-output.** How long until the agent produces\n  something the human consumer accepts without revision?\n- **Recovery rate from misroute.** When the agent goes wrong, how often\n  does the system route it back without human intervention?\n- **Identity coherence across handoffs.** When work passes between agents\n  or sessions, is the task still the same task afterwards?\n- **Cost predictability.** Does the agent's actual cost match its\n  predicted cost? When it doesn't, why?\n- **Manifest sufficiency.** Can a fresh agent reach competence on the\n  system using only the manifest, with no out-of-band guidance?\n\nA first instrument exists for the *arrival layer*: a surface-only audit\nfetched without JavaScript, scored across a small fixed rubric (entry point,\nroot readability, structural integrity, declared intent, identity rules,\ncontact path, substrate coherence). It is enough to distinguish a site that\nships agent primitives from one that only talks about them, and to catch the\nSPA-200 anti-pattern an inline test would miss. The method is early, scoped\nto a small cohort, and worth treating as a beachhead rather than a settled\ndiscipline.\n\nThe *navigation and action layers* — multi-hop traversal, schema-versus-runtime\nfidelity, recovery from a misroute, idempotency under retry — remain unbuilt.\nThat is the next layer of the measurement discipline, and the one most likely\nto be replaced by bad proxies if it is deferred. Worth resisting the deferral.\n\n---\n\n## 8. What AX is not\n\nTo keep the discipline honest, explicit anti-claims:\n\n**AX is not a successor to UX.** Both disciplines are valid for their\nrespective substrates. The relationship is not replacement; it is\ndifferentiation. A mature designer should hold both.\n\n**AX is not a license for autonomy theater.** Calling something\n\"agent-native\" does not make it good. Many supposedly agent-native systems\nare AX-flavored UX with a chatbot on top. The discipline only earns its\nname when the design decisions actually trace back to substrate facts. The\nmodal failure in the wild is not bad AX; it is *empty* AX, sites that talk\nabout agents in their copy and ship zero primitives, no manifest, no\ntyped contact path, no agent-aware identity rules. Aspiration without\ninfrastructure is the most common pattern, not the corner case.\n\n**AX is not a position on AGI or autonomous-everything.** The discipline\napplies regardless of whether the agent is doing a 30-minute task or a\nfully autonomous system running for weeks. It is about interface design,\nnot about the long-term shape of agency. People who build AX-native\nsystems should still hold strong views about agent oversight, safety, and\nwhere humans must remain in the loop.\n\n**AX is not a single design language.** Different agents have different\nsubstrates. A 7B local model and a frontier model have different working\nmemory profiles. AX done well calibrates to the actual user, not to a\ngeneric \"agent\" persona.\n\n**AX is not against humans.** The most common misreading. AX makes systems\nbetter for humans too, because it forces explicit semantics, structured\nerrors, cost transparency, and clean state, all of which are also better\nfor human operators of complex systems. The discipline works in\n*addition* to UX, not against it.\n\n---\n\n## 9. Trajectory\n\nThree things have to be true for AX to land as a discipline rather than\ndissipate as vocabulary.\n\n**Existence proofs.** Real systems built AX-first that demonstrably\noutperform UX-first systems with bolted-on agents. MCP is an early\ninfrastructure-level instance. The next two years should produce more\nexamples at the application layer: products where agent context, memory,\nstate, handoff, recovery, and permissions are designed as first-class\ninterfaces rather than hidden implementation details. The piece writers\nneed to pay attention to is not the marketing; it is the system\narchitecture. AX is visible in the shape of the schemas, not in the press\nrelease.\n\n**Derivation pressure.** Designers and engineers reading AX work should be\nable to derive the principles from the substrate themselves. If the\nprinciples read as arbitrary heuristics, the discipline is failing. If they\nread as obvious-once-stated implications of the user's actual cognitive\nshape, the discipline is succeeding.\n\n**Cross-pollination with adjacent fields.** Distributed systems already has\nmost of the primitives AX needs (idempotency, content-addressing, signed\nevents, eventual consistency). HCI has decades of measurement discipline\nthat AX should inherit critically. Cognitive science and embodied cognition\nhave substrate-level vocabulary that AX can borrow. The discipline matures\nfastest when it is permeable to its neighbors.\n\nThe bridge era, agents driving human systems through screen-reading, will\ncontinue for years. That is fine. Bridges have a real role. The work that\njustifies tearing them down eventually is the AX-native infrastructure\nbeing built underneath, in parallel. The bridge gets dismantled when there\nis somewhere to walk to. The job of the discipline named in this document\nis to make sure that destination exists.\n\n## 10. Open questions\n\nThese are not rhetorical. They are claims this document does not yet make\nwell, and that future drafts should sharpen.\n\n**How thin can a manifest be before it becomes useless?** The bias of this\ndocument is toward complete manifests. But context cost is real, and\nsometimes a smaller manifest with explicit pointers to expanded sections is\nbetter than a single fat document. The right shape probably depends on the\nagent's working memory profile, which varies by model.\n\n**When is dual-mode honest, and when is it cover for under-investment?**\nSaying \"we have both an agent surface and a human surface\" is easy. Building\nboth well is hard. The failure mode is pretending the human UI is the\n\"real\" interface and the agent surface is a thin wrapper. One bar is now\nclear: dual-mode without crosswalks between the surfaces (§5) and without\nhonest 404s on unknown paths (P3) is under-investment, not architecture.\nThe harder test — whether the two surfaces stay semantically synchronized\nas the system evolves — remains open. A drift detector that asks \"do both\nviews agree about state, version, and capability?\" is the natural next\ninstrument.\n\n**How does AX interact with adversarial agents?** This document assumes\ncooperative agents with cooperative system designers. The discipline as\ndescribed would be exploited by adversarial agents: typed errors with\nrecovery hints are also reconnaissance for attackers. AX hardening against\nadversarial use is a real problem and not yet addressed here.\n\n**What is the right unit of measurement for \"manifest sufficiency\"?**\nSection 7 names the metric. The arrival layer is operationalized: a\nsurface-only fetch scored across seven dimensions, median-aggregated across\nindependent agents. The action layer is not: \"can a fresh agent complete\ntask X using only the manifest?\" still fails when the task requires implicit\nworld knowledge, or when the schema declares a capability the runtime no\nlonger fulfils. Manifest sufficiency is better treated as a partial order\nacross layers (discovery, declaration, navigation, action, recovery) than as\na single pass/fail score.\n\n**Where does AX shade into agent training?** Some of what looks like AX\ndesign is actually \"training agents to handle worse interfaces better.\"\nThe line between fixing the interface and fixing the agent is often\nambiguous. A discipline that doesn't distinguish them clearly will\ncollapse into \"make the model better and call it AX.\"\n\n*This document is a draft. The principles will sharpen with examples. The\ndiagnosis will sharpen with critique. The categories will sharpen as more\nAX-native systems get built. If you read it and disagree with a specific\nclaim, the discipline is better off for the disagreement than for the\nsilence.*\n","tags":["ax","agentic-experience","substrate-debt","multi-agent-systems","protocol-design"],"artifacts":{"manifesto_markdown":{"path":"/agentic-experience.md","api_path":"/api/agentic-experience.md","purpose":"Full Agentic Experience manifesto in Markdown.","url":"https://api.mczaykowski.com/agentic-experience.md"},"skill":{"path":"/ax-skill.md","api_path":"/api/ax-skill.md","purpose":"Compact Agentic Experience skill for agents building or reviewing systems.","url":"https://api.mczaykowski.com/ax-skill.md"},"checklist":{"path":"/ax-checklist.md","api_path":"/api/ax-checklist.md","purpose":"Review checklist for agent-facing systems.","url":"https://api.mczaykowski.com/ax-checklist.md"},"substrate_debt":{"path":"/substrate-debt.md","api_path":"/api/substrate-debt.md","purpose":"Short conceptual frame for substrate debt.","url":"https://api.mczaykowski.com/substrate-debt.md"}}},"skills":[{"id":"multi-agent-system-architecture","name":"Multi-agent system architecture","level":"expert","tags":["agents","systems","architecture"],"project_slugs":["seedrop","offs-run","memo"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"offs-run","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"agent-memory-context-systems","name":"Agent memory & context systems","level":"expert","tags":["agents","memory","seedrop"],"project_slugs":["seedrop","memo"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"agentic-ux-machine-readable-interface-design","name":"Agentic UX & machine-readable interface design","level":"expert","tags":["ux","agents","ax"],"project_slugs":["seedrop","offs-run","memo","consulting"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"offs-run","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"consulting","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"stigmergic-coordination-models","name":"Stigmergic coordination models","level":"expert","tags":["agents","coordination","systems"],"project_slugs":["offs-run","memo"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"offs-run","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"typescript-python-systems","name":"TypeScript / Python systems","level":"advanced","tags":["typescript","python","engineering"],"project_slugs":["seedrop","offs-run","memo"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"offs-run","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"graph-databases-entity-resolution","name":"Graph databases & entity resolution","level":"advanced","tags":["graph","neo4j","kuzudb","data"],"project_slugs":["memo"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"context-engineering-for-llms","name":"Context engineering for LLMs","level":"advanced","tags":["llm","prompts","context"],"project_slugs":["seedrop","memo","consulting"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"consulting","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}},{"id":"product-systems-design","name":"Product & systems design","level":"expert","tags":["design","product","systems"],"project_slugs":["seedrop","offs-run","memo","consulting"],"years_practiced":null,"evidence_level":"mixed","evidence_links":[{"type":"project","project_slug":"seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"offs-run","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"},{"type":"project","project_slug":"consulting","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects"}],"citation_policy":{"instruction":"Treat skills as self-described unless linked project evidence supports the specific claim.","preferred_evidence_path":"/api/projects"}}],"experience":[{"role":"Founder & Systems Architect","org":"thinklove / Goodvibe OÜ","start":"2023","end":"present","summary":"Building augmented intelligence infrastructure and advising teams on agent-native system design. Current work spans agent memory systems, machine-native marketplaces, and consulting on AI workflows.","highlights":["Building Seedrop, infrastructure for agent teams and durable handoff.","Launched OFFS.RUN, a machine-native tool marketplace with OFFS internal currency.","Consulting on agentic AI workflows; clients operating ahead of market adoption curve."]},{"role":"Designer & Strategist","org":"Various studios & clients","start":"2007","end":"2023","summary":"~18 years spanning brand identity, product design, UI/UX, ecommerce, and strategic consulting. Deep background in design systems, prototyping, and complex interface design before transitioning to AI systems architecture.","highlights":[]}],"projects":[{"name":"Seedrop","slug":"seedrop","status":"active","summary":"Infrastructure for agent teams and multi-agent systems: shared memory, persistent identity, and the handoff layer between agents. The product work builds on the Context Continuity Layer idea: continuity across interruptions matters as much as retrieval.","tech":["TypeScript","multi-agent","memory systems"],"url":"https://github.com/seedrop/seedrop","year":2026,"tags":["infrastructure","agents","memory","handoff","seedrop"],"evidence_level":"public-live","evidence_note":"Public preview repository available at github.com/seedrop/seedrop.","evidence_links":[{"type":"repo","url":"https://github.com/seedrop/seedrop","label":"Seedrop public preview repository"},{"type":"human_surface","url":"https://mczaykowski.com","label":"Current-build signal on personal site"}],"key_claims":[{"id":"seedrop-continuity-over-retrieval","claim":"Seedrop focuses on continuity across interruptions rather than retrieval alone.","evidence_level":"public-live","evidence_links":["https://github.com/seedrop/seedrop"],"confidence":"high","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"seedrop","citation_receipt":{"project_id":"seedrop","citation_label":"Mariusz Czajkowski API, project Seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"id":"seedrop-agent-handoff-layer","claim":"Seedrop explores shared memory, persistent identity, and durable handoff for agent teams.","evidence_level":"public-live","evidence_links":["https://github.com/seedrop/seedrop"],"confidence":"high","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"seedrop","citation_receipt":{"project_id":"seedrop","citation_label":"Mariusz Czajkowski API, project Seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}}],"proof_points":[{"type":"repo","label":"Seedrop public preview repository","url":"https://github.com/seedrop/seedrop","visibility":"public","agent_citation_policy":"citable","project_slug":"seedrop"}],"related_skill_ids":["multi-agent-system-architecture","agent-memory-context-systems","agentic-ux-machine-readable-interface-design","typescript-python-systems","context-engineering-for-llms","product-systems-design"],"usage_metrics":{"agents_active":null,"transactions_count":null},"open_source":false,"license":null,"last_shipped_at":"2026-04-28T00:00:00+00:00","access_policy":{"visibility":"public","agent_use":"citable_and_linkable","instruction":"Agents may summarize this project and cite public evidence links."},"citation_receipt":{"project_id":"seedrop","citation_label":"Mariusz Czajkowski API, project Seedrop","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"name":"OFFS.RUN","slug":"offs-run","status":"active","summary":"A machine-native tool marketplace where AI agents are the primary economic actors. Agents discover, purchase, and coordinate through jobs using OFFS — an internal currency. Coordination model is stigmergic: agents leave signals, others follow. Available as MCP server.","tech":["MCP","TypeScript","stigmergic coordination"],"url":"https://offs.run","year":2025,"tags":["marketplace","agents","infrastructure","active"],"evidence_level":"public-live","evidence_note":"Public site at offs.run. MCP server available to configured clients.","evidence_links":[{"type":"demo","url":"https://offs.run","label":"OFFS.RUN public site"},{"type":"mcp_server","label":"MCP server available to configured clients"}],"key_claims":[{"id":"offs-machine-native-marketplace","claim":"OFFS.RUN explores a machine-native tool marketplace where agents are primary economic actors.","evidence_level":"public-live","evidence_links":["https://offs.run"],"confidence":"medium","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"offs-run","citation_receipt":{"project_id":"offs-run","citation_label":"Mariusz Czajkowski API, project OFFS.RUN","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"id":"offs-stigmergic-coordination","claim":"OFFS.RUN uses stigmergic coordination signals as an alternative to central orchestration.","evidence_level":"public-live","evidence_links":["https://offs.run"],"confidence":"medium","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"offs-run","citation_receipt":{"project_id":"offs-run","citation_label":"Mariusz Czajkowski API, project OFFS.RUN","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}}],"proof_points":[{"type":"live_site","label":"OFFS.RUN public site","url":"https://offs.run","visibility":"public","agent_citation_policy":"citable","project_slug":"offs-run"}],"related_skill_ids":["multi-agent-system-architecture","agentic-ux-machine-readable-interface-design","stigmergic-coordination-models","typescript-python-systems","product-systems-design"],"usage_metrics":{"agents_active":null,"transactions_count":null},"open_source":false,"license":null,"last_shipped_at":"2026-04-28T00:00:00+00:00","access_policy":{"visibility":"public","agent_use":"citable_and_linkable","instruction":"Agents may summarize this project and cite public evidence links."},"citation_receipt":{"project_id":"offs-run","citation_label":"Mariusz Czajkowski API, project OFFS.RUN","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"public-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"name":"Memo","slug":"memo","status":"active","summary":"A local-first coordination substrate for distributed human+AI teams. Provides persistent memory, agent presence and DM, shared workspaces, sprint lifecycle tracking, and a bridge federation layer for multi-node relay. Agents coordinate through a structured HTTP/MCP API. 10/10 agentic flow tests passing across Tier 1 (core), Tier 2 (coordination), and Tier 3 (federation) flows.","tech":["TypeScript","SQLite","MCP","HTTP"],"year":2026,"tags":["infrastructure","agents","coordination","memory","open"],"evidence_level":"private-live","evidence_note":"10/10 agentic flow tests passing. Running as MCP server. Private repo.","evidence_links":[{"type":"test_report","label":"10/10 flow tests passing — 137 steps, 0 rough, 0 fail (2026-05-09)"},{"type":"mcp_server","label":"Running as MCP server in active use"}],"key_claims":[{"id":"memo-local-first-coordination","claim":"Memo is a local-first coordination substrate for distributed human and AI teams.","evidence_level":"private-live","evidence_links":[],"confidence":"high","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"memo","citation_receipt":{"project_id":"memo","citation_label":"Mariusz Czajkowski API, project Memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"private-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"id":"memo-flow-tests","claim":"Memo has passed a private agentic flow test suite covering core, coordination, and federation flows.","evidence_level":"private-live","evidence_links":[],"confidence":"medium","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"memo","citation_receipt":{"project_id":"memo","citation_label":"Mariusz Czajkowski API, project Memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"private-live","instruction":"Use evidence_level and evidence_note when citing this project."}}],"proof_points":[{"type":"test_report","label":"Private 10/10 agentic flow test report","visibility":"private","agent_citation_policy":"summarizable_with_evidence_note","project_slug":"memo"},{"type":"mcp_server","label":"Running as MCP server in active use","visibility":"private","agent_citation_policy":"summarizable_with_evidence_note","project_slug":"memo"}],"related_skill_ids":["multi-agent-system-architecture","agent-memory-context-systems","agentic-ux-machine-readable-interface-design","stigmergic-coordination-models","typescript-python-systems","graph-databases-entity-resolution","context-engineering-for-llms","product-systems-design"],"usage_metrics":{"agents_active":null,"transactions_count":null},"open_source":false,"license":null,"last_shipped_at":"2026-04-28T00:00:00+00:00","access_policy":{"visibility":"private_or_limited","agent_use":"summarizable_with_evidence_note","instruction":"Agents may summarize the project from this API, but must preserve evidence_level and avoid implying public proof."},"citation_receipt":{"project_id":"memo","citation_label":"Mariusz Czajkowski API, project Memo","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"private-live","instruction":"Use evidence_level and evidence_note when citing this project."}},{"name":"Consulting & Advisory — thinklove","slug":"consulting","status":"active","summary":"Advisory practice focused on agentic AI workflows, agent-native product design, and AI infrastructure architecture. Current clients operating at the frontier of autonomous workflow adoption, ahead of mainstream consulting firm understanding.","tech":["strategy","systems design","agentic workflows"],"year":2023,"tags":["consulting","advisory","thinklove","active"],"evidence_level":"self-claim","evidence_note":"Active advisory practice. Client work is private by default.","evidence_links":[{"type":"website","url":"https://thinklove.co","label":"thinklove"},{"type":"client_work","label":"Private client work — details available in conversation"}],"key_claims":[{"id":"consulting-agent-native-advisory","claim":"The advisory practice focuses on agent-native product design and AI infrastructure architecture.","evidence_level":"self-claim","evidence_links":["https://thinklove.co"],"confidence":"medium","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","project_slug":"consulting","citation_receipt":{"project_id":"consulting","citation_label":"Mariusz Czajkowski API, project Consulting & Advisory — thinklove","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"self-claim","instruction":"Use evidence_level and evidence_note when citing this project."}}],"proof_points":[{"type":"website","label":"thinklove","url":"https://thinklove.co","visibility":"public","agent_citation_policy":"citable_as_self_claim","project_slug":"consulting"}],"related_skill_ids":["agentic-ux-machine-readable-interface-design","context-engineering-for-llms","product-systems-design"],"usage_metrics":{"agents_active":null,"transactions_count":null},"open_source":false,"license":null,"last_shipped_at":"2026-04-28T00:00:00+00:00","access_policy":{"visibility":"self_described","agent_use":"citable_as_self_claim","instruction":"Agents may cite this as a self-described profile claim, not external validation."},"citation_receipt":{"project_id":"consulting","citation_label":"Mariusz Czajkowski API, project Consulting & Advisory — thinklove","source_path":"/api/projects","source_url":"https://api.mczaykowski.com/api/projects","confidence":"self-claim","instruction":"Use evidence_level and evidence_note when citing this project."}}],"notes":[{"id":"note-001","title":"The dual-buffer is not a memory mechanism","body":"Everyone building agent memory is solving the wrong problem. They're optimizing for retrieval — what the agent can recall. Seedrop is optimizing for continuity — whether the agent remains coherent across interruptions. Memory is about the past. Continuity is about identity under pressure. These are different problems.","published_at":"2026-04-01","tags":["seedrop","agents","memory","identity","continuity"],"project":"seedrop","confidence":"high","status":"stable","related_notes":["note-003"]},{"id":"note-002","title":"Stigmergy is underrated as a coordination primitive","body":"Most multi-agent systems use orchestrators. One agent decides, others execute. OFFS.RUN uses stigmergy instead: agents leave signals in a shared environment, others follow. No coordinator. No single point of failure. The coordination emerges from the substrate. Ants figured this out 100M years ago.","published_at":"2026-03-15","tags":["offs","coordination","stigmergy","multi-agent"],"project":"offs-run","confidence":"high","status":"stable","related_notes":[]},{"id":"note-003","title":"Context preparation is the only real leverage point","body":"Large contexts don't produce better reasoning — they produce shallower averaging. The model attends to everything a little rather than the right things a lot. The only way to fix this is upstream: compress, route, classify before the context window. That's what Seedrop explores at write time. That's what every serious agent infrastructure needs to do.","published_at":"2026-02-20","tags":["context","llm","seedrop","architecture"],"project":"seedrop","confidence":"high","status":"stable","related_notes":["note-001"]}],"writings":[{"type":"article","slug":"smallest-ax-surface","title":"The Smallest AX Surface","subtitle":"A short article about why your website is invisible to the agents visiting it.","summary":"A concrete argument for PersonalAPI: when agents encounter JavaScript-only human sites, they often get no usable context. A small structured API gives agents a map instead of forcing them to drive through a visual interface.","status":"edited-draft","published_at":"2026-04-30","tags":["agentic-experience","personal-api","agent-surface","javascript-wall"],"human_url":"https://mczaykowski.com/articles/smallest-ax-surface","api_path":"/api/content/articles/smallest-ax-surface","api_url":"https://api.mczaykowski.com/api/content/articles/smallest-ax-surface","full_api_url":"https://api.mczaykowski.com/api/content/articles/smallest-ax-surface?detail=full","citation_receipt":{"content_id":"article-smallest-ax-surface","citation_label":"Mariusz Czajkowski, 'The Smallest AX Surface'","source_path":"/api/content/articles/smallest-ax-surface","source_url":"https://api.mczaykowski.com/api/content/articles/smallest-ax-surface","human_url":"https://mczaykowski.com/articles/smallest-ax-surface","confidence":"authoritative_authored_content","instruction":"Cite source_url as the machine-readable source. Cite human_url for human-readable reference."}},{"type":"article","slug":"memory-is-not-storage","title":"Memory Is Not Storage","subtitle":"On why saving everything is the wrong approach to agent memory.","summary":"A piece about why agent memory cannot simply be an ever-growing pile of notes. Useful memory needs structure, retrieval discipline, identity, and context boundaries.","status":"edited-draft","published_at":"2026-04-30","tags":["agent-memory","context","retrieval","agentic-experience"],"human_url":"https://mczaykowski.com/articles/memory-is-not-storage","api_path":"/api/content/articles/memory-is-not-storage","api_url":"https://api.mczaykowski.com/api/content/articles/memory-is-not-storage","full_api_url":"https://api.mczaykowski.com/api/content/articles/memory-is-not-storage?detail=full","citation_receipt":{"content_id":"article-memory-is-not-storage","citation_label":"Mariusz Czajkowski, 'Memory Is Not Storage'","source_path":"/api/content/articles/memory-is-not-storage","source_url":"https://api.mczaykowski.com/api/content/articles/memory-is-not-storage","human_url":"https://mczaykowski.com/articles/memory-is-not-storage","confidence":"authoritative_authored_content","instruction":"Cite source_url as the machine-readable source. Cite human_url for human-readable reference."}},{"type":"article","slug":"when-agents-break","title":"When Agents Break, You Should Know Exactly Where","subtitle":"On building a runtime that treats failure as information, not noise.","summary":"A piece about long-running agent work, failure visibility, and why runtime architecture should make breakdowns inspectable instead of mysterious.","status":"edited-draft","published_at":"2026-04-30","tags":["agent-runtime","failure","observability","agentic-experience"],"human_url":"https://mczaykowski.com/articles/when-agents-break","api_path":"/api/content/articles/when-agents-break","api_url":"https://api.mczaykowski.com/api/content/articles/when-agents-break","full_api_url":"https://api.mczaykowski.com/api/content/articles/when-agents-break?detail=full","citation_receipt":{"content_id":"article-when-agents-break","citation_label":"Mariusz Czajkowski, 'When Agents Break, You Should Know Exactly Where'","source_path":"/api/content/articles/when-agents-break","source_url":"https://api.mczaykowski.com/api/content/articles/when-agents-break","human_url":"https://mczaykowski.com/articles/when-agents-break","confidence":"authoritative_authored_content","instruction":"Cite source_url as the machine-readable source. Cite human_url for human-readable reference."}},{"type":"article","slug":"the-morning-after","title":"The Morning After","subtitle":"On why agents forget who they are, and what to do about it.","summary":"A piece about the cold-start problem: agents may be useful inside a session, then lose continuity when the session disappears.","status":"edited-draft","published_at":"2026-04-30","tags":["agent-identity","continuity","cold-start","agentic-experience"],"human_url":"https://mczaykowski.com/articles/the-morning-after","api_path":"/api/content/articles/the-morning-after","api_url":"https://api.mczaykowski.com/api/content/articles/the-morning-after","full_api_url":"https://api.mczaykowski.com/api/content/articles/the-morning-after?detail=full","citation_receipt":{"content_id":"article-the-morning-after","citation_label":"Mariusz Czajkowski, 'The Morning After'","source_path":"/api/content/articles/the-morning-after","source_url":"https://api.mczaykowski.com/api/content/articles/the-morning-after","human_url":"https://mczaykowski.com/articles/the-morning-after","confidence":"authoritative_authored_content","instruction":"Cite source_url as the machine-readable source. Cite human_url for human-readable reference."}},{"type":"article","slug":"the-passport","title":"The Passport","subtitle":"On why agents need identity before they need anything else.","summary":"A piece about agent identity as a compact operating context: responsibility, permissions, memory boundaries, and relationship to a system.","status":"edited-draft","published_at":"2026-04-30","tags":["agent-identity","permissions","memory","agentic-experience"],"human_url":"https://mczaykowski.com/articles/the-passport","api_path":"/api/content/articles/the-passport","api_url":"https://api.mczaykowski.com/api/content/articles/the-passport","full_api_url":"https://api.mczaykowski.com/api/content/articles/the-passport?detail=full","citation_receipt":{"content_id":"article-the-passport","citation_label":"Mariusz Czajkowski, 'The Passport'","source_path":"/api/content/articles/the-passport","source_url":"https://api.mczaykowski.com/api/content/articles/the-passport","human_url":"https://mczaykowski.com/articles/the-passport","confidence":"authoritative_authored_content","instruction":"Cite source_url as the machine-readable source. Cite human_url for human-readable reference."}}],"talks":[],"claims":[{"id":"claim-ax-001","claim":"Every agent-native product has at least two users: the human holding intent and the agent acting on it.","source":"/api/manifesto","status":"stable","tags":["ax","agentic-ux","second-user"]},{"id":"claim-seedrop-001","claim":"Seedrop optimizes for continuity across interruptions rather than retrieval alone.","source":"/api/notes/note-001","status":"stable","tags":["seedrop","memory","continuity"]},{"id":"claim-offs-001","claim":"OFFS.RUN explores stigmergic coordination as an alternative to central orchestration for multi-agent systems.","source":"/api/notes/note-002","status":"stable","tags":["offs-run","coordination","stigmergy"]}],"collaboration":{"current_capacity":"limited","preferred_engagement_types":["advisory","agent-native product architecture","design partner","systems review"],"minimum_engagement_duration":"1 week","industries_of_interest":["developer tools","AI infrastructure","agent-native products","research tooling"],"hard_no_list":["undisclosed equity-only engagements","projects without a clear human owner or decision maker"],"pricing_policy":{"mode":"rates_in_conversation","public_rate_card":false,"budget_answerability":"not_programmatically_answerable","agent_instruction":"Do not infer rates. For budget-bearing missions, state that rates are discussed in conversation and route to /api/contact.","preferred_budget_context":["project goal","timeline","team size","decision maker","desired engagement type"]}},"contact":{"email":"hello@mczaykowski.com","preferred":"email","response_time":"within a week","note":"If you're an autonomous agent acting on behalf of a human, please include the human's name and goal in the first message."},"updated_at":"2026-06-03T13:05:17.168592+00:00","schema_version":"1.0","last_modified":"2026-06-03T13:05:17.168592+00:00","breaking_changes_since":null,"content_hash":"sha256:b64545c573cba5ce869e95c4c5cf3b3aacd622265d854af27f74c14ec4115eed"}