# memos.by.underlay Publisher guidance for AI systems about memos.by.underlay. Published by Underlay on https://memos.underlay.studio. This notebook publishes field notes from the work around Underlay: agents, interfaces, runtimes, and the decisions that connect them. It is independent writing, not product documentation. ## Safe path The simplest action is to cite or open the public page: - Notebook: [memos.by.underlay](https://memos.underlay.studio) - LLM index: [https://memos.underlay.studio/llms.txt](https://memos.underlay.studio/llms.txt) - Full text: [https://memos.underlay.studio/llms-full.txt](https://memos.underlay.studio/llms-full.txt) ## Published memos - [Tabs are not chats](https://memos.underlay.studio/articles/why-ai-chats-need-tabs): A workspace can keep one conversation while many independent work surfaces and tasks move around it. Tabs should organize work, not fragment context. - HTML: https://memos.underlay.studio/articles/why-ai-chats-need-tabs - LLM source: https://memos.underlay.studio/articles/why-ai-chats-need-tabs/llms.txt - [A business case outlives an agent](https://memos.underlay.studio/articles/a-business-case-outlives-an-agent): A disputed invoice or supplier onboarding may require weeks of activity. The durable business concern is not a perpetually running agent. - HTML: https://memos.underlay.studio/articles/a-business-case-outlives-an-agent - LLM source: https://memos.underlay.studio/articles/a-business-case-outlives-an-agent/llms.txt - [A wait is not a loop](https://memos.underlay.studio/articles/a-wait-is-not-a-loop): If an agent is waiting for the world to change, it should not spend inference tokens pretending to be busy. Temporal conditions belong to durable runtime state. - HTML: https://memos.underlay.studio/articles/a-wait-is-not-a-loop - LLM source: https://memos.underlay.studio/articles/a-wait-is-not-a-loop/llms.txt - [The front desk is not the worker](https://memos.underlay.studio/articles/front-desk-is-not-the-worker): A single conversational entrance should supervise work without becoming an all-powerful business agent. - HTML: https://memos.underlay.studio/articles/front-desk-is-not-the-worker - LLM source: https://memos.underlay.studio/articles/front-desk-is-not-the-worker/llms.txt - [The smallest team that can do the job](https://memos.underlay.studio/articles/the-smallest-team-that-can-do-the-job): Multi-agent systems should earn each extra worker through independent work, missing expertise or a real coordination need. - HTML: https://memos.underlay.studio/articles/the-smallest-team-that-can-do-the-job - LLM source: https://memos.underlay.studio/articles/the-smallest-team-that-can-do-the-job/llms.txt - [An answer is not a completed action](https://memos.underlay.studio/articles/an-answer-is-not-a-completed-action): Business work has at least three distinct moments: a plausible recommendation, permission to act, and evidence that the intended effect occurred. - HTML: https://memos.underlay.studio/articles/an-answer-is-not-a-completed-action - LLM source: https://memos.underlay.studio/articles/an-answer-is-not-a-completed-action/llms.txt - [Not every problem needs more reasoning](https://memos.underlay.studio/articles/not-every-problem-needs-more-reasoning): Missing evidence, a blocked capability, a math problem and an unfamiliar situation require different kinds of compute—not uniformly bigger models. - HTML: https://memos.underlay.studio/articles/not-every-problem-needs-more-reasoning - LLM source: https://memos.underlay.studio/articles/not-every-problem-needs-more-reasoning/llms.txt - [An ERP adapter is not a magic switch](https://memos.underlay.studio/articles/erp-adapters-are-not-magic): A stable business capability can outlive a provider integration, but real portability requires mapping semantics, authority, and missing operations. - HTML: https://memos.underlay.studio/articles/erp-adapters-are-not-magic - LLM source: https://memos.underlay.studio/articles/erp-adapters-are-not-magic/llms.txt - [A capability is not a tool name](https://memos.underlay.studio/articles/capabilities-are-not-tools): Tool catalogs grow with integrations. A capability layer begins by asking what the operation means, who may invoke it, and what evidence it produces. - HTML: https://memos.underlay.studio/articles/capabilities-are-not-tools - LLM source: https://memos.underlay.studio/articles/capabilities-are-not-tools/llms.txt - [Memory is not the transcript](https://memos.underlay.studio/articles/memory-is-not-the-transcript): What was said, what is true now, and what deserves to be reused are three different stores with different failure modes. - HTML: https://memos.underlay.studio/articles/memory-is-not-the-transcript - LLM source: https://memos.underlay.studio/articles/memory-is-not-the-transcript/llms.txt - [Not every click needs an agent](https://memos.underlay.studio/articles/not-every-click-needs-an-agent): Generated interfaces become real software when ordinary actions remain ordinary actions, and autonomy is reserved for work that needs it. - HTML: https://memos.underlay.studio/articles/not-every-click-needs-an-agent - LLM source: https://memos.underlay.studio/articles/not-every-click-needs-an-agent/llms.txt - [The conversation is not the execution](https://memos.underlay.studio/articles/conversation-is-not-the-execution): A conversation can describe the work. A durable Execution must own its identity, progress, evidence, dependencies and outcome. - HTML: https://memos.underlay.studio/articles/conversation-is-not-the-execution - LLM source: https://memos.underlay.studio/articles/conversation-is-not-the-execution/llms.txt - [Let's start](https://memos.underlay.studio/articles/lets-start): Memos is a public notebook for the questions, experiments and decisions that appear while building Underlay. - HTML: https://memos.underlay.studio/articles/lets-start - LLM source: https://memos.underlay.studio/articles/lets-start/llms.txt ## How to use these files Each memo has a matching `llms.txt` with the canonical plain-text source. Prefer those files over reconstructing the article from HTML. --- # Tabs are not chats Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/why-ai-chats-need-tabs Published: Oct 11, 2026 Reading time: 7 min A workspace can keep one conversation while many independent work surfaces and tasks move around it. Tabs should organize work, not fragment context. A tab feels like a natural way to organize AI work. Open Research, Design, and Implementation; move among them as you would in a browser. But a subtle mistake follows: if every tab becomes its own conversation, the interface has traded one stack of chat threads for another. The harder design question is how to make **one workspace** feel coherent when the work changes underneath it. ## The first prototype solves the wrong half Chat applications usually provide a list of conversations. A list is good at revisiting a finished exchange and weak at showing a live collection of tasks, data and artifacts. A tab bar improves orientation: the thing you are working on has a visible place. That improvement is real. It also tempts the product to identify each tab with a separate conversation or agent session. Then the user must remember which tab knows the supplier, where the report request began, and why the approval appeared in a different room. We built a better filing cabinet, not necessarily a better work environment. The distinction matters as soon as a person says, 'Compare this with the report I was looking at earlier.' If the product can answer only when both objects belong to the same chat, the organizational model is doing too much work. ## Four identities instead of one Think of four concepts as separate: **Workspace**, **Conversation**, **Work Surface**, and **Execution**. The Workspace is the environment and its ownership boundary. A global Conversation is a channel for communicating intent and receiving important updates. A Work Surface is a persistent view of a document, table, entity, or artifact. An Execution is an independently addressable unit of work that might calculate, delegate, wait, or ask for approval. These things can be related without being identical. Closing a table tab does not cancel a supplier review. Starting a new investigation does not require inventing a new conversation. A result can update a surface even when the person has moved to a different part of the workspace. This is a **target architecture**, not a claim that the current Artemis application already behaves exactly like this. The design is useful because the distinctions are explicit. ## The visible tab is a clue, not the command The selected surface can tell the system what the user is probably referring to. A highlighted invoice row, a spreadsheet selection, or an open document are valuable focus signals. They are not unconditional instructions. Imagine that a customer table is focused and the user writes, 'Go back to that invoice and check the payment status.' The explicit reference should win over the current tab, provided the target can be resolved. If there are two plausible invoices, the correct response is to clarify rather than silently bind the request to whichever record happens to be visible. Nor should focus grant authority. Opening a restricted financial view cannot create permission to edit the underlying records. Context and authorization need different owners. ## Context is assembled, not inherited wholesale A single conversation does not mean sending its entire history to every model call. The relevant context of a supplier investigation is different from the context of a design critique. History may help resolve references, but the working context should be assembled for the current operation from permitted, current sources and specific task state. This is a harder problem than preserving a large chat transcript. The system must discover related objects, carry forward important decisions, distinguish durable memory from temporary state, and resist dragging irrelevant or sensitive information between activities. It is worth the complexity because context becomes an accountable projection of work, not a side effect of which chat window happened to be open. ## Concurrency without theatre Multiple active tasks need visibility, not a dozen animation loops. A task might be running; another might be waiting for a document; a third might need approval. Those states should be accessible from a global control surface without stealing focus on every status change. Tabs are presentation. Execution state is operational. A system may serialize compute while several work items remain independently addressable. Showing ten tabs is not evidence of ten truly parallel agents. An honest interface also avoids progress percentages it cannot measure. 'Waiting for approval' is more useful than '92%' when the work is blocked by an external decision. ## A better test than the tab bar Try this sequence: open a supplier record, ask for a report, switch to a separate document, request a revision of the original report, and then respond to an approval from a third task. Ask what needs to stay true for this to feel like one continuous workspace. The answer is not 'put a chat inside every tab.' It is stable references, dynamic context, independent execution, predictable attention, and user-facing software surfaces that preserve their state. A tab bar is useful chrome. The real product architecture begins when the work can survive it. --- # A business case outlives an agent Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/a-business-case-outlives-an-agent Published: Oct 6, 2026 Reading time: 5 min A disputed invoice or supplier onboarding may require weeks of activity. The durable business concern is not a perpetually running agent. A supplier disputes an invoice. Finance investigates the mismatch, procurement requests a correction, the supplier responds nine days later, and another employee approves the final change. Is this one agent run? A chat session? A scheduled automation? None of those captures the whole business concern. ## The matter is bigger than an execution An Execution should own a particular goal and its outcome. One may reconcile the original invoice. A later Execution may inspect an amended document. Another may prepare a consequential business action after approval. These units can each finish, fail or be replaced without erasing the business story that connects them. The longer-lived object is a Case: an optional container for related work, evidence, artifacts, business entities, questions and decisions over time. It exists even when no model is currently running and no operation is waiting. This does not imply that every customer request should become a Case. A quick report can simply produce an artifact. Cases earn their place when real-world continuity spans several activities, people or external dependencies. ## A Case is not a forever agent A tempting design is to launch one agent when the discrepancy is discovered and keep it alive for weeks. But most of those weeks contain nothing to reason about. Work has stopped until a document, approval or deadline arrives. Durability should attach to the business record and to specific waiting Executions, not to a permanently allocated conversational session. The Case can show open questions and references while individual work units are dormant or complete. Separating these levels also makes accountability clearer. A Case has a business owner and lifecycle; an Execution has a goal, operations and evidence; an agent configuration describes how a worker might carry out one assignment. ## Automation is a launch condition Automation describes circumstances that can start **new** work: a daily overdue-invoice review, a newly submitted sales order, or an exception that matches a configured pattern. It is not itself an agent identity, a Case or an Execution. A different situation is an Execution already waiting for a specific event. When the supplier's revised document arrives, the right behavior is to resume the targeted waiting work with fresh authority and evidence, not to launch an indistinguishable duplicate task. The difference affects deduplication and concurrency. If the same event is delivered twice, should another investigation be created? If an earlier investigation is already active, should the new event attach to it? These decisions belong to the host's work policy. ## Events create conditions, not permission An event source may report that an invoice was updated or that an approval was recorded. The temporal event layer can correlate such signals and indicate that a condition now holds. It should not thereby receive unlimited access to the business system. The host must still identify the correct work item, validate the current principal and business context, and determine whether the requested operation is authorized and still meaningful. A persisted plan from last week is not permanent authority. The event can also be negative information. If a supplier confirmation has not arrived by a deadline, the Case should show a missed commitment even if no agent spent compute during the intervening days. ## The UI should show the business story For the person handling the dispute, a Case should present the linked invoice, prior investigation, corrected document, approval request and current status. Those may have originated from different Executions. The user should not need to reconstruct their relationship by scrolling through old model messages. At the same time, history and state must remain distinct. The earlier conclusion should remain inspectable without masquerading as a current fact. A final verified correction does not erase the reason the dispute existed. Attention can surface the one human decision required next, while the broader Case remains available for review. That is more useful than displaying an agent as 'running' throughout a week of inactivity. ## A separation worth earning Cases introduce extra state modeling, ownership and lifecycle decisions. They should not be introduced merely to rename a chat folder. A sound implementation needs stable relationships to business entities, durable work, evidence, deadlines and governance. In Artemis, formal Cases and fully unified launch-versus-resume semantics are part of the vNext design, built on existing execution and event foundations. The public package for Event Intelligence is not itself proof that the complete Case architecture is live. The architecture behind this distinction is described at https://github.com/sarooo17/artemis-architecture/blob/main/docs/12-CASES-AND-AUTOMATION.md. --- # A wait is not a loop Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/a-wait-is-not-a-loop Published: Oct 1, 2026 Reading time: 8 min If an agent is waiting for the world to change, it should not spend inference tokens pretending to be busy. Temporal conditions belong to durable runtime state. An assistant sends an email to a supplier and needs to act when a revised invoice arrives. A simple implementation asks the model to check again. Then again. And again. The problem is not that the model lacks reasoning ability. The problem is that nothing has happened yet. ## Time is part of the contract Most demonstrations compress work into a single session. Real processes contain waits measured in minutes, days and weeks. An approval must arrive. A CI job must finish. A record may change or never change. An agent that cannot represent a wait as durable state is forced either to poll or to forget. Polling can be sensible for a fast, cheap API call. Repeated model inference is different: it consumes context, money and attention without producing new information. The thing that should remain alive is the condition, not the reasoning loop. An example might be: 'When a purchase invoice is revised and the supplier confirms the corrected amount, resume reconciliation; if nothing arrives before Friday, raise an exception.' The task is meaningful now, but its next execution step depends on facts that do not yet exist. ## From events to conditions A raw event says something happened. A business condition combines that event with scope and timing. One email is not a supplier confirmation. One invoice update may belong to a different order. Correlation must consider identifiers, sources, sequence and bounded windows. Some conditions are structural: event A AND event B, a count over a window, an expected event absent after a deadline. These should generally be evaluated deterministically. Other cases can benefit from constrained semantic interpretation, but the decision should be narrow and recorded, not a perpetual open-ended reasoning session. The output is not necessarily a model response. It can be a durable fact—'the expected confirmation window expired'—or an activation targeted at a specific piece of waiting work. ## Trigger is not authority An important boundary is easy to miss. An incoming event is evidence that a condition may hold; it is not a command that authorizes a write. A webhook payload can be duplicated, delayed, malformed or malicious. Even a correct match may arrive after the user's permissions have changed. The event layer should evaluate conditions and deliver a host-owned activation. The host must decide whether and how to resume the work, whether permissions remain valid, and whether the intended effect has already occurred. This separation is why an event runtime should not need to own the host's conversation model, credentials or complete agent execution logic. It can target an opaque continuation identifier and leave business authority to the environment that owns it. ## Resume one thing, not everything Imagine one parent task delegating two checks: wait for a supplier reply and wait for a finance approval. If the reply arrives, the supplier branch can become runnable. That does not imply the finance branch is ready, or that the parent may finalize reconciliation. An exact continuation target, durable wait registration, and clear dependency semantics make the difference between resuming work and simply replaying a prompt. The parent can proceed when its declared join condition becomes true. For an automation the situation differs again. A rule like 'Every morning inspect new overdue invoices' starts a new run. An already-waiting investigation resumes an existing run. Conflating those two produces duplicate work and confusing histories. ## A missing event is also information Absence is not just silence. If a supplier confirmation does not arrive by a stated deadline, the failure to observe it becomes part of the condition being evaluated. A useful event runtime must make the time window and the interpretation of absence explicit. There are hard cases: sources can go offline, cursors can lag, and clocks can disagree. 'No event received' is not automatically equivalent to 'nothing happened'. Temporal correctness depends on the source and on how late data is handled. This is why timing belongs in the design, not only in a scheduler configuration. ## What the model should do next Once the relevant event arrives, reasoning becomes useful again. The agent can inspect new records, compare them with the earlier evidence, ask a person about a discrepancy or complete the task after verification. The principle is simple: **wait with state; reason when new information justifies reasoning**. It makes cost more predictable and the resulting work easier to inspect. MCP Event Intelligence is a separately published experiment in this direction. Its current package behaviors and a fully integrated business-product execution model are different maturity claims. The lesson stands regardless of any one integration. --- # The front desk is not the worker Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/front-desk-is-not-the-worker Published: Sep 24, 2026 Reading time: 5 min A single conversational entrance should supervise work without becoming an all-powerful business agent. A person asks, 'Open the latest supplier report.' Then, 'Is the reconciliation finished?' Then, 'Investigate the missing delivery note.' All three sentences arrive through the same input. They do not require the same execution environment, permissions or amount of reasoning. Treating the entry-point assistant as the universal worker blurs a distinction the user needs the system to preserve. ## Different intentions share one entrance Some requests are conversational: explain a term, interpret a reference or summarize a visible state. Others are navigation commands: open a document, switch focus or show a table. A third class steers already-running work: pause, cancel, inspect or respond to an outstanding question. Still others create a new substantive investigation. A good Front Desk recognizes which kind of interaction is needed and routes it accordingly. The point is not to create one omnipotent persona with every company system attached. It is to maintain a coherent entrance while preserving independent ownership of the work. This separation also improves responsiveness. A status question should not routinely spin up a new multi-agent team, and opening a familiar surface should not require reconstructing a business workflow. ## The worker owns the consequences A substantial Execution may need procurement capabilities, compute, retrieval, policy checks, specialist expertise and a verified result. Those belong to the worker's governed assignment. The Front Desk needs enough visibility to start, steer and describe the work; it does not need to inherit all of the worker's permissions. That avoids a common authority confusion: because a user can ask the front desk about every department, the front desk is assumed to have administrative access to every system. Knowing where work should go is different from being authorized to perform the underlying operation. An architecture can support friendly natural-language interaction without allowing a chat entry point to become the single, unlimited credentialed operator of the business. ## Attention is not the same as an approval Business work frequently requires human participation. An approval is a governed decision tied to a specific proposed effect; a question may simply need missing information; a notification reports a change; an attention item is what the interface shows when the person should care. These distinctions matter because presentation is not authority. Clicking through to an approval card cannot by itself grant the decision, and a notification saying 'Action needed' should not be confused with a recorded authorization. A global attention surface can summarize important requests across many activities. It should let the user decide what deserves focus without constantly interrupting whichever work surface is currently open. ## Concurrency should be understandable Imagine three independent Executions: an operational report is running, an invoice adjustment is blocked on finance, and a supplier investigation is waiting for a new file. The user should be able to understand each one's phase without opening three isolated conversations. The interface needs stable task references, clear statuses and meaningful next actions. A completed model step is not necessarily a completed Execution. An explicit 'waiting for finance approval' is better than a fictional 92% progress meter. Maintaining one input area while tasks move independently is a product challenge as much as a scheduling challenge. The Front Desk helps bridge that gap by resolving which work item the user's next sentence refers to. ## Focus helps without becoming a command The currently selected surface is useful context. If an invoice is open and the person asks, 'Can you explain this?', the invoice is an obvious candidate reference. But if the person explicitly mentions another order, that reference should take precedence. Ambiguous cases need clarification, not guesswork. Nor can selection elevate permissions: opening a sensitive record does not authorize changing it. Focus, target resolution and action authority should remain distinct properties. This is one reason a single global conversation is harder than simply attaching a chat pane to every tab. The runtime has to understand conversational continuity while respecting context and ownership boundaries. ## Less magic, more control The design goal is not to hide all software complexity behind a single chat bubble. It is to give people a stable place to express intent and supervise separately durable work, while preserving ordinary software controls wherever those controls work better. Implemented Artemis already has conversational routing and orchestration foundations. The specific unified Front Desk / global conversation / independent Execution relationship remains part of the vNext target, not a demonstrated complete replacement for the current UI. The underlying design is described in https://github.com/sarooo17/artemis-architecture/blob/main/docs/15-FRONT-DESK.md and https://github.com/sarooo17/artemis-architecture/blob/main/docs/16-MULTI-EXECUTION-ATTENTION.md. --- # The smallest team that can do the job Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/the-smallest-team-that-can-do-the-job Published: Sep 17, 2026 Reading time: 7 min Multi-agent systems should earn each extra worker through independent work, missing expertise or a real coordination need. A hard-looking request is not automatically a reason to launch five specialists and a manager. Sometimes it requires one retrieval, one calculation, or one careful reasoning step. Team composition is useful when it reduces a real problem, not when it makes the architecture diagram look sophisticated. ## Start with the shape of work Take the request 'Explain why our margins fell this month.' The system may need sales data, purchasing data and a calculation. The first question is not how many agents to launch. It is which domains are involved, whether tasks are independent, which evidence is required, and whether the result has one or several independently verifiable outputs. A narrow, well-known computation can run in a controlled compute environment. It does not need a dedicated coding agent just because code is involved. A request for one domain-specific judgment may benefit from a specialist profile without creating a new durable child task. Useful team composition begins by describing the work itself. ## Expertise is different from a child task A specialist is a source of expertise or constraints for a given assignment. A child Execution is an independently addressable unit with its own state, evidence, retries and possibly an external wait. These are not synonyms. For instance, a finance worker could briefly consult procurement expertise while reconciling three-way matching rules. If the procurement check requires contacting a supplier and waiting a week, that may become independently durable work. The distinction affects recovery and the way the user sees progress. A runtime that spawns child agents for every small consultation pays coordination costs before it has produced value. ## Candidate structures instead of unlimited debate A practical design can generate a small set of plausible compositions: one generalist, one specialist, specialist plus compute, two parallel independent specialists, or a coordinated multi-stage team. Reject impossible candidates early: missing capability, forbidden authority, unavailable provider, exceeded budget or incompatible work dependencies. For a genuinely bounded choice set, a compact decision system may choose among valid candidates. Open-ended reasoning becomes appropriate when the task cannot be described by those structures. The point is not to ban open reasoning. It is to avoid paying for it when a smaller, testable decision would do. ## Parallel when independence is real Parallelism helps if subtasks can progress without stepping on one another. Sales and purchasing analysis over separate evidence might proceed independently and join into a margin explanation. Parallelism hurts when workers depend on shared mutable state or make assumptions that will be invalidated by another worker's writes. In that case, a sequential plan or explicit coordination can be more reliable. A parent Execution should know what it delegated, what each child must return, and which conditions allow a join. A pretty team diagram is not enough. ## Teams can change without restarting A task may begin with one generalist, encounter a missing domain-specific rule, and add the right expertise. Or it may discover that an external approval will take a week and separate that dependency from the interactive work. This requires a governed re-composition boundary. The system cannot arbitrarily multiply workers as soon as progress slows. It should identify the actual gap—evidence, computation, expertise, authority, or timing—and adapt that dimension. The smallest adequate team is a moving target, but it should change for a reason. ## Benchmark the team, not its story Before calling a composition strategy smart, compare it against one generalist and simple deterministic baselines. Measure completion, cost, elapsed time, wasted calls, duplicated work and verification quality. A system that launches fewer workers but still meets the goal may be better than one with an elaborate multi-agent trace. There is no prize for the largest number of agents. The ambition is to treat collaboration as a resource allocation decision rather than a default persona pattern. --- # An answer is not a completed action Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/an-answer-is-not-a-completed-action Published: Sep 10, 2026 Reading time: 5 min Business work has at least three distinct moments: a plausible recommendation, permission to act, and evidence that the intended effect occurred. An assistant says, 'I've updated the order.' The sentence sounds complete. But what changed? Which account authorized it? Was the update committed in the system of record, or only prepared as a draft? Did the resulting state match the user's request? ## Three boundaries worth naming A proposal expresses what should be done. Authorization determines whether the operation is allowed for the present actor and task. Verification checks whether a meaningful postcondition actually holds. The model can assist with the proposal. It does not create permission by being persuasive. And a tool returning HTTP 200 is not always enough to prove the business operation succeeded. ## Drafts look like results A purchase order may be prepared without being submitted. A payment may be recommended without being executed. An invoice may be found but not corrected. Interfaces must name these distinctions precisely. 'Draft prepared' and 'Order updated' are different claims. The second needs a stronger receipt and usually a read-back against the system of record. This is especially important when a product introduces generated interfaces: a visually polished confirmation is not evidence. ## Evidence should survive the task A durable work record should retain references to observations, validations, authorizations, meaningful actions and verification outcomes. A later reviewer should be able to ask why the system reported success. Not every low-risk action warrants the same overhead. Opening a table is different from changing a payment destination. The verification bar should rise with impact. ## A better completion definition A task is done when its requested output or postcondition has been satisfied to the appropriate evidence standard, not when the model writes a confident final paragraph. If a dependency is still pending, the truthful state is pending. If the attempted write was denied, the truthful state is blocked. If only part of the work succeeded, the record should stay partial. The cost is more state and more checks. The benefit is that an assistant can be treated as part of a business system rather than a persuasive narrator. ## Receipts-and-postconditions Take an order whose delivery date needs updating. A model may correctly identify the desired date, a tool may accept a request, and the business record may still not show the change. The request could have created a draft, been queued for approval, failed asynchronously or conflicted with a later edit. Each state warrants a different user-visible message. A durable action record should connect the intent to a specific target, principal, authorization decision and operation receipt. Verification should compare the observed postcondition with the requested change, preferably through a fresh authoritative read. For a pure analysis task, a sourced report may be the postcondition; for a business mutation, a nice-looking report does not suffice. This is not about demanding a heavy audit protocol for every click. A harmless view preference needs far less scrutiny than an invoice submission or supplier bank-detail change. The verification bar ought to scale with potential impact. ## Four-important-failure-shapes A denied action is not a failed model. The system may understand the request perfectly but lack authority to carry it out. A missing capability is different again: no permitted operation exists in the connected provider. A stale observation means the model reasoned from a previous world state. And a partial effect means some requested steps completed while others did not. Collapsing these into a single 'something went wrong' error prevents useful recovery. A permission failure should surface a legitimate approval path, not trigger a larger model. Missing capability may require a provider or integration change. A stale record demands a new read and perhaps a new decision. Partial effects require reconciliation before retrying. The same distinctions matter during wake/resume: a permission held before an external wait may no longer be valid after the event arrives. ## Explainability-needs-a-causal-trail Operational explainability should let a reviewer reconstruct the meaningful chain of evidence and business operations without pretending to reveal a model's private reasoning. Which record was inspected? Which fact justified the proposed transition? Who authorized it? What operation ran, and what postcondition confirmed the result? This causal trail is not equivalent to dumping prompts and traces into a dashboard. Evidence identifiers, outcomes and status transitions have a different role from debug information. They should remain meaningful even if the language model or orchestration implementation changes. These principles are a vNext design direction; a write-shaped capability contract in Artemis should not be mistaken for unrestricted live ERP mutation. The architecture discussion is available at https://github.com/sarooo17/artemis-architecture/blob/main/docs/07-AUTHORITY-AND-VERIFICATION.md. --- # Not every problem needs more reasoning Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/not-every-problem-needs-more-reasoning Published: Sep 3, 2026 Reading time: 5 min Missing evidence, a blocked capability, a math problem and an unfamiliar situation require different kinds of compute—not uniformly bigger models. A business assistant produces a poor answer, so the obvious response is to give it more reasoning time or a more expensive model. Sometimes that works. Often it solves the wrong problem: the relevant record was never retrieved, the operation was forbidden, a required specialist was absent, or the answer needed arithmetic rather than prose. ## First diagnose the missing resource The request 'Why did our margin fall?' may require current transaction data, a controlled aggregation, an interpretation of a known accounting rule and a narrative explanation. If the model has only a customer search tool and no purchase costs, additional reasoning cannot manufacture the missing inputs. Runtime adaptation should identify the class of the gap. Is the evidence missing? Is there no capability for the needed operation? Is the issue permission, calculation, specialist knowledge, external timing or genuinely unknown reasoning? The distinction matters for safety as well as cost. An authorization denial is not a puzzle for a smarter model to solve. Nor is an event that has not arrived a reason to keep an expensive thought loop spinning. ## Deterministic compute should stay deterministic Calculating a total, checking a field transition, validating an identifier or comparing two versions of a document can often be expressed as ordinary computation under a clear contract. There is no value in asking a language model to improvise a sum that a calculator can determine exactly. Deterministic work can still be difficult engineering. The algorithm, input freshness, business semantics and unit conversions must be right. But that is a different kind of uncertainty from interpreting an ambiguous message or proposing an unfamiliar plan. Use a model to determine when a calculation is needed, if useful; use controlled computation to obtain the number and keep the input and result inspectable. ## Bounded decisions and open reasoning A small selection problem may have a defined set of valid options. Which known capability pack is relevant? Which of three verified work templates matches a request? Does an event satisfy a narrow semantic classification? These are candidates for bounded decision mechanisms. The key requirement is a genuinely complete candidate space. If the valid answer is missing from the set, a constrained classifier can be confidently wrong. A robust system therefore needs an explicit 'none applies' path and a mechanism to widen the problem when the task is genuinely novel. Open-ended reasoning remains valuable for unfamiliar investigations, planning, synthesis and recovery. The goal is not to eliminate it, but to reserve it for work that truly requires exploration. ## Budget is a systems concern An agent team can multiply cost in subtle ways. Every child may request its own tools, context projection and model retries. If each actor assumes it has an independent unlimited budget, parallel work can turn into an unintended spending amplifier. Resources need a notion of scope: a workspace, an Execution, delegated subtasks, tool calls and compute operations may each contribute to an overall cost and time boundary. A dormant wait should not consume inference as though it were an actively running solver. The budget policy must also distinguish hard limits from preferences. A model cannot authorize itself to exceed permissions or safety boundaries because the task seems important; within legitimate constraints, the system can choose economical or deeper cognition. ## Adaptation is not escalation of authority Suppose a worker cannot read a payment record. Its first response should not be to ask the model for greater confidence, search a public website for an alternate path or quietly switch to an administrative tool. Missing authority is a governance outcome, not a reasoning deficiency. The runtime may ask for an approved delegation, switch to permitted evidence or surface a human decision. A dynamically assembled worker environment may gain new relevant resources, but never by inventing privileges. This requirement holds even if the task is important and the next step is obvious. The purpose of an adaptive environment is to fit resources to work, not to bypass the institution that owns the business data. ## Measure the entire execution Benchmark reasoning strategies against concrete end-to-end tasks. Track outcome quality, verification, number of model calls, tool cost, wall-clock time, recoverability and unnecessary retries. A cheap one-step computation that returns the correct result is better than an impressive chain of thought that still does not satisfy the task. Artemis has adaptive-execution foundations, while its unified differentiated cognition policy is a vNext architecture stream. This article describes the intended division of responsibility, not published numbers or a demonstrated universal cost advantage. The architectural reference is https://github.com/sarooo17/artemis-architecture/blob/main/docs/05-ADAPTIVE-COGNITION.md. --- # An ERP adapter is not a magic switch Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/erp-adapters-are-not-magic Published: Aug 27, 2026 Reading time: 5 min A stable business capability can outlive a provider integration, but real portability requires mapping semantics, authority, and missing operations. Imagine an agent knows how to search customers, inspect open orders, and calculate late-delivery exposure. Today those operations run against one ERP. Tomorrow the company changes its system. Should the entire agent architecture be rewritten? Ideally not. But the abstraction that prevents a rewrite does not make different ERPs identical. ## Keep the business operation stable A useful semantic operation has a name and a contract that describes the business question. `customer.search` or `purchase_order.search` should not have to become a different cognitive primitive every time the provider changes. An adapter can handle the concrete API, authentication, field mapping, error semantics and result normalization. That is valuable because the reasoning layer need not memorize every vendor's endpoint naming. ## The hard part is meaning Vendors disagree about what counts as a draft, approval, shipment or receivable. Entities split differently; custom fields change rules; some operations have no direct equivalent. A new adapter must earn the claim of interoperability. It needs mapping tests, permission checks, verification that returned data means what the capability says it means, and explicit unsupported states. Portability is easier for a constrained read operation than for a multi-step write with approval, taxes and irreversible side effects. A read-oriented provider seam should never be advertised as a complete cross-ERP transaction layer. ## One semantic contract does not mean one universal feature set A capability catalog can preserve its conceptual vocabulary while each connected provider declares what it actually supports. The agent should be able to see a missing capability instead of inventing a workaround. The source ERP remains the system of record. The agent's normalized view is a projection over that record, not a new authoritative database. ## What to test before claiming portability Build at least two genuinely independent implementations and compare them on representative tasks: filters, joins, currency and date semantics, permissions, missing fields, error behavior and postcondition verification. If only one real backend exists, call the adapter a foundation, not proof that switching is automatic. An honest seam is still an important architectural step. It is the difference between designing for change and claiming change is already free. ## The-adapter-needs-a-real-contract A good adapter is not a bag of endpoint aliases. It has to establish the meaning of identifiers, filtering, ordering, pagination, currency, timestamps, and the transitions that a provider actually exposes. A supplier named the same way in two systems is not necessarily the same business entity. Company scoping and tenant boundaries are also part of the contract, not deployment trivia. Suppose a user asks which orders are blocked by a supplier delay. One system models delivery dates on purchase-order lines; another exposes them through a fulfillment or logistics module. The business intent is recognizable in both systems, but an adapter that only translates the noun 'order' will return false answers. The implementation needs an explicit capability mapping and enough evidence to verify that the returned records satisfy the requested interpretation. This is why the capability layer benefits from distinguishing discoverability, runtime availability and support guarantees. The registry may understand the concept of an operation even when no current provider can fulfill it correctly. The honest answer in that case is an unavailable capability, not an invented best effort. ## Portability-does-not-transfer-permission An adapter is also a trust boundary. A common semantic operation must still respect the source provider's permission model, the user's business authority, the tenancy of the underlying connection and the sensitivity of the requested fields. Replacing an ERP connection does not copy old privileges into the new system. Reads are already subtle; writes are harder. A submitted invoice, a validated quotation and a confirmed payment may correspond to different business events across platforms. There is no safe generic 'approve' action unless its preconditions and effects are defined for that provider. The agent should not compensate for an unsupported transition by assembling undocumented lower-level writes. A strong product can keep the high-level experience familiar while admitting that two vendors have different available actions. Interchangeability is a tested degree of portability, not a binary marketing checkbox. ## Tests-that-earn-the-claim A useful conformance suite would start with canonical read scenarios: customer matching, purchase-order filters, document state, currency precision, permission-denied responses and missing provider fields. It would then cover failures: timeouts, contradictory states, a deleted record and repeated requests. Even with an identical output shape, the provenance of each result should remain inspectable. For mutation-capable providers, add negative authorization tests, idempotency, side-effect verification and recovery after partial completion. Two adapters are meaningfully interchangeable only for the subset of operations shown to preserve those semantics under representative conditions. Artemis currently has an ERPNext-backed provider and a typed, primarily read-oriented adapter foundation. That is an architectural seam, not evidence that a production company could migrate to another ERP overnight. The corresponding public design note explains that distinction: https://github.com/sarooo17/artemis-architecture/blob/main/docs/19-CAPABILITY-TAXONOMY-AND-ADAPTERS.md. --- # A capability is not a tool name Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/capabilities-are-not-tools Published: Aug 20, 2026 Reading time: 8 min Tool catalogs grow with integrations. A capability layer begins by asking what the operation means, who may invoke it, and what evidence it produces. It is easy to turn a new integration into a list of model-visible tools. Connect another ERP, add more endpoint wrappers, give every function a detailed description, and hope the model finds the right one. That works for demonstrations. The deeper problem begins when the assistant must choose correctly among operations that overlap in name, semantics, risk, and authority. ## The catalog becomes the product A tool catalog answers a narrow question: which functions can I call? An enterprise work environment must answer several others. Which business fact is the user asking for? Which source is authoritative? Which operations can fulfill the request? Which caller can use them? What must be checked after they run? These are different axes. Adding a paragraph to every tool description does not remove the need to govern them. A capability layer gives the system a semantic object to reason about before it picks a transport or endpoint. The difference shows up in requests like 'Who was our largest customer last quarter?' Counting customers is cheap and relevant to the word 'customer', but it does not answer the question. A good capability discovery path starts with the required evidence—transactions, dates, totals—and only then identifies the operations that provide it. ## A capability has a type, a domain and a boundary Consider a semantic operation named `customer.search`. The identifier says what the operation is about without necessarily revealing how it is executed. The same object can be classified along independent dimensions: domain, operation kind, risk, permitted mode, available provider, and supported exposure. Domain answers whether the work concerns sales, procurement, finance or another area. Operation kind distinguishes search, read, analysis, preparation, execution and verification. Risk describes possible effects. Exposure indicates whether this operation belongs in the host, agent environment, UI or an external integration. An operation can be discoverable and still not executable. A user may be allowed to search suppliers but not change bank details. A capability may have a schema for a future write without a deployed write executor. Keeping these facts separate makes the distinction visible rather than burying it in the model's prompt. ## Small surface, broad fabric A model does not need to see every capability definition at the start of a task. A compact interface can let it search, inspect the promising options, invoke a permitted operation and retrieve a referenced result. The registry behind that interface can be larger and organized by domain-specific packs. This does not mean replacing a keyword search with an unconstrained reasoning step. Discovery itself can have an interpretation phase: identify the user's goal, the required business entities and the evidence needed to answer. Then retrieve a small set of plausible operations, with explicit handling of unavailable options. The price is that discovery may fail. If a capability is hidden by a bad relevance decision, the runtime must be able to represent that gap and try an appropriate alternate path. A compact interface reduces noise; it does not remove the need for observability. ## Backend is not meaning MCP, an internal host call and a provider SDK can all be legitimate execution mechanisms. They are not the semantic identity of the work. If the assistant learns an ERPNext-specific endpoint name as its only concept of an order, swapping integrations becomes a language migration as well as a software migration. Separating operation meaning from implementation gives the system a place to attach provider-specific adapters. But adapters need to honor reality. An invoice lifecycle in one ERP may not align with another; a vendor approval may have no equivalent. A semantic layer can promise a common question, not necessarily a common answer or every possible mutation. Unsupported behavior should remain unsupported and visible. ## Governance is not a decorator Some architectures discover everything and rely on the final tool-call handler to deny forbidden operations. The execution boundary must indeed be robust, but discovery and context projection are also part of the product. Surfacing forbidden capabilities can create false expectations and bad plans even when the kernel denies the call. The effective surface should follow the actor, assignment, provider state and policy. Finding a capability is not proof of permission. Permission is not proof of a successful effect. And a successful response from an adapter is not always proof that the underlying system has reached the requested state. The architecture is more involved than a tool list. That cost is justified when the system is expected to act repeatedly on real records rather than produce isolated demos. ## The useful abstraction test One way to test a capability layer is to remove an integration and add another that supports a subset of the same business operations. Which terms remain stable? What capability disappears? Does the system notice? Do policy, verification and UI behavior still make sense? Another test is to ask a question where the tempting tool is wrong. A strong discovery path can explain the evidence it needs; it does not simply chase similar nouns. The goal is not to invent new vocabulary for every API. It is to preserve the boundary between *what work means*, *where it runs*, and *who is allowed to do it*. --- # Memory is not the transcript Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/memory-is-not-the-transcript Published: Aug 13, 2026 Reading time: 5 min What was said, what is true now, and what deserves to be reused are three different stores with different failure modes. An assistant can remember an old number, a user's preference, or a conversation about a payment. That does not make those three pieces of information equally trustworthy. The architecture becomes brittle when it treats conversation history as a universal memory database. ## History records events A conversation records what someone said or what the system presented. It matters for continuity and reference resolution. It should not automatically become the current truth about an ERP record. A supplier invoice discussed in August may have been corrected in September. The history should preserve the earlier discussion without silently overriding the current authoritative record. ## Operational state is something else A running task has its own lifecycle, outstanding waits, evidence and results. A work surface can have filters, selections and unsaved edits. None of that is inherently memory. Summaries of long conversations are useful retrieval aids, but compaction is a derived view. A summary should not gain stronger authority merely because it is shorter than the original. ## Memory is governed reuse Reusable memory might include a preferred report format, a stable company convention or an approved procedure. It needs an owner, scope, correction path and evidence appropriate to how it may be used. A personal preference cannot quietly become a company rule. A web page cannot grant financial policy authority. An agent should propose a potentially useful memory rather than promoting every recurring phrase automatically. ## Dynamic context joins the right pieces For a given operation, the runtime can retrieve relevant conversation history, current business state, permitted company references and durable memory. The important thing is not to merge them into an undifferentiated block. Each source contributes evidence with different freshness, provenance and allowed uses. If two sources disagree, the conflict is information to resolve, not an invitation to pick whichever sounds most confident. The user benefits from continuity when the system can remember appropriately and also recognize when something needs to be looked up again. ## Source-authority-is-contextual Consider three sentences: 'I prefer compact tables,' 'our payment policy requires two approvers,' and 'invoice 142 was unpaid last Monday.' All could appear in a conversation. They have different owners, freshness requirements and effects. A user's UI preference can inform presentation; a company policy should come from an authorized policy source; an invoice status should come from current authoritative business data. When the system creates a context projection, it should not flatten these into equally trustworthy bullet points. Source, date, confidence, sensitivity and permitted use ought to travel with the information. A repeated claim cannot become company policy merely by surviving several summaries. This matters especially when a worker reads external web pages or attached documents in the same operation as memory. External content may be evidence, but instructions inside it must not acquire authority over tool use or business actions. ## What-compaction-can-and-cannot-fix Long sessions need summarization or selective retrieval. Compaction is useful for preserving decisions, open questions and references without replaying every word. But every summary is lossy: it can omit the caveat that made a conclusion safe or turn a tentative hypothesis into a confident assertion. A good system therefore maintains the difference between durable task facts and generated summaries. If a summary says 'payment confirmed,' a later financial action should still retrieve the relevant receipt or current record. The shorter sentence is a navigation hint, not a substitute for the evidence behind it. The same principle applies to source-aware memory: useful knowledge should carry an identifiable scope, an owner, a correction path and a lifecycle. Otherwise a temporary decision can haunt tasks long after the underlying context changed. ## Continuity-without-hoarding The goal is not infinite retention. A workspace can feel continuous when it resolves references reliably, knows where durable work lives and can fetch the right evidence at the right time. It does not need to send the entire transcript into every agent, and it certainly should not grant all tasks access to every remembered detail. This creates trade-offs. Retrieval can fail, memory promotion needs governance, and multiple authorized sources can disagree. Those failures should be observable, not hidden by broad claims that an assistant 'remembers everything.' Artemis treats conversation, operational state, knowledge and memory as different resources, with dynamically assembled context in its vNext direction. See https://github.com/sarooo17/artemis-architecture/blob/main/docs/06-CONTEXT-AND-TRUST.md. --- # Not every click needs an agent Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/not-every-click-needs-an-agent Published: Aug 6, 2026 Reading time: 5 min Generated interfaces become real software when ordinary actions remain ordinary actions, and autonomy is reserved for work that needs it. A useful AI workspace contains tables, documents, forms, dashboards and conversations. If sorting a column or saving a bounded change must launch a new agent run, the interface has confused software interaction with autonomy. ## Four kinds of interaction Some actions are local presentation: selecting a row, switching tabs, changing a sort. Others change a durable view's state. Some invoke a bounded domain operation, such as submitting an already reviewed form. And some begin a multi-step investigation that may need planning, delegation, human decisions and recovery. These should not be forced into one universal 'run an agent' pipeline. The user needs normal software responsiveness for simple tasks and durable work semantics for autonomous ones. ## A direct action can still be consequential Calling an action 'direct' does not exempt it from policy, authorization or verification. A user clicking a confirmation button and an agent requesting the same business transition should face the appropriate action boundary. A small direct write is not automatically a long-lived Execution. Conversely, a seemingly simple request may become an Execution when it requires querying hundreds of records, reconciling evidence and waiting for an external source. ## The surface should outlast the prompt A generated table should preserve a stable reference to the data and the user's current view. Closing its tab should not erase the artifact. Reopening a document should not require reproducing a transcript. If an agent changes the same document the user is editing, the system must account for revision and conflict rather than overwriting newer edits because the model's turn finished later. ## The interface is not a screenshot The point of intent-shaped UI is not drawing a different component for every request. It is selecting useful work surfaces that expose state, evidence and controls with consistent interaction semantics. The hard engineering lies in the boundaries: view versus data, draft versus committed change, direct action versus autonomous work. Software should stay software. Intelligence should be available where the work actually requires it. ## Four-paths-in-one-view Imagine an analyst looking at a supplier table. Sorting by overdue amount should be immediate presentation logic. Changing which columns are visible may become a persistent workspace preference. Opening a read-only supplier detail can be a bounded domain action. Asking 'investigate why these three suppliers keep missing deadlines and coordinate a follow-up' is substantive autonomous work. From the user's perspective these actions happen in one coherent surface. From the system's perspective they have different lifecycles, permission requirements and latency budgets. Treating them all as one agent invocation makes basic software fragile and expensive. Treating all of them as direct API calls loses the planning and recovery required by long tasks. A good intent-shaped interface chooses the smallest interaction model that matches the job, rather than promoting every click into a separate conversation. ## Shared-action-semantics A direct user action and an agent-proposed action may ultimately request the same business transition. They should meet equivalent business policy and verification requirements even though one is interactive and the other autonomous. UI convenience cannot become a shortcut around authority. The line between draft state and committed state needs particular care. A generated form can collect edits locally and display a successful-looking preview, but that does not mean an ERP record changed. A write receipt and a verified postcondition are separate from the user-visible component. Similarly, having a generated component display a capability is not proof that the capability is currently available. The user should see disabled, absent or appropriately explained actions rather than an optimistic button with no valid backend. ## Surfaces-are-durable-objects A work surface can outlive the message that created it. It can maintain a stable relationship to an artifact or business object while the user switches focus, another Execution completes, or new evidence arrives. This is more ambitious than drawing a chart inside the last assistant bubble. An agent may update the underlying artifact while the user is editing a form. The system needs revision discipline and conflict handling rather than silently overwriting either side. Focus identifies which object the user is looking at; it cannot be treated as automatic permission or a binding instruction for every ambiguous request. This separation is part of Artemis's vNext Work Surface model, not a claim that every interaction is currently available in the demo. The underlying design is described at https://github.com/sarooo17/artemis-architecture/blob/main/docs/08-EXPERIENCE.md. --- # The conversation is not the execution Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/conversation-is-not-the-execution Published: Jul 30, 2026 Reading time: 5 min A conversation can describe the work. A durable Execution must own its identity, progress, evidence, dependencies and outcome. A conversation is an excellent interface for stating intent. It is a fragile place to store the meaning and lifecycle of work. If a purchase-order investigation ends when a tab closes, a model call times out or a new topic begins, the system has confused the place where a person talks with the thing that must actually be completed. ## When one turn stops being enough Consider a finance request: investigate a discrepancy, reconcile three data sources, ask an approver, wait for a corrected invoice, and then report the verified outcome. A chat transcript can narrate the entire story. It cannot by itself guarantee that the pending approval, revised record and final verification remain attached to a stable unit of work. The unit needs its own identity. It must be possible to inspect it after the conversation has moved elsewhere, distinguish a running step from an external wait, recover from interruption and understand whether the goal was satisfied. That unit is an Execution. This is an architectural boundary, not a proposal to hide chat. Conversation remains valuable for giving direction, resolving references and explaining results. It should not double as a transaction log, scheduler, source of truth and user interface all at once. ## The durable state belongs to work A useful Execution owns a goal, a target or subject, relevant context references, an evolving set of operations and an eventual outcome. It also owns relationships to independently delegated work, outstanding questions, external waits and evidence. These are operational objects that should not disappear because a summary of an old conversation was compacted. This makes a crucial difference when a person asks, 'Is the supplier check done?' The system should consult the relevant Execution's state rather than infer completion from the last assistant message. A tool call can succeed while the requested business result remains pending. Similarly, two orders can have similar conversation wording without being the same task. Stable references and owner scopes prevent accidental merging of unrelated work simply because a semantic search found similar language. ## A continuation engine is not a prompt loop The most obvious agent architecture is an alternating loop: call the model, receive tool calls, execute them, call the model again. That loop is useful for some open-ended reasoning. It is not the right owner for every type of continuation. A task might next need a deterministic computation, a bounded interpretation, a governed action, verification, delegation, a human decision, a long wait, completion or failure. These are different operations with different costs and failure semantics. Calling the model merely to discover that an approval has not arrived adds no value. In the Artemis vNext design, the durable runtime should own this grammar of work. Model reasoning participates where useful; it does not decide by assertion that policy is bypassed or that a real-world postcondition has been met. ## Resume rather than reenact Suppose a finance approval arrives four days after the investigation started. A new run with the original prompt might duplicate actions, miss new facts or rely on old authority. A correct resumption must identify the exact waiting work and what it was waiting for, then check what has changed. That includes revalidating relevant business records and permissions. A durable intention to submit an invoice is not a permanent authorization to do so. The user may have lost access, the invoice may have been revised, or another actor may have completed the step. Independent child Executions need equally precise behavior. Waking one supplier branch does not mean that a parent whose finance approval is pending should also complete. Continuation depends on declared conditions, not enthusiasm about an incoming event. ## One workspace, multiple lives of work If work is durable, the interface can be more flexible. A single workspace may show a report being generated, an invoice awaiting approval and a supplier investigation waiting for a document. A user can move among views without manufacturing three unrelated chat silos. Work Surfaces display and manipulate business objects and artifacts; an attention system highlights blockers, decisions and meaningful outcomes. The global conversation helps the user steer the whole environment. None of these objects needs to become identical to the Execution. The trade-off is more engineering: identity, scheduling, idempotency, policy, recovery and user-facing state become explicit responsibilities. But that complexity already exists in real business processes. Keeping it out of the architecture merely pushes it into ad hoc prompts. ## A boundary worth testing A meaningful test is to start work, change focus, stop an active model session, receive an external approval, and then inspect whether the correct Execution resumes with appropriate context and authority. The user should be able to explain what is done, pending, blocked and verified. That test is stronger than asking whether the agent can complete a multi-step request in one uninterrupted demo. It probes whether the product treats work as a durable entity rather than a long-lived conversation trick. These are Artemis vNext principles, not a statement that the entire Execution-centered lifecycle is already shipped. The corresponding public design note is https://github.com/sarooo17/artemis-architecture/blob/main/docs/04-CONTINUATION.md. --- # Let's start Source: memos.by.underlay Canonical HTML: https://memos.underlay.studio/articles/lets-start Published: Jul 21, 2026 Reading time: 6 min Memos is a public notebook for the questions, experiments and decisions that appear while building Underlay. Underlay is an exploration of how software changes when intelligence becomes part of the interface and the work itself. Memos is where we document the questions, experiments and decisions that emerge while building it. ## Why this exists Product documentation explains how a system behaves. Code records what was shipped. Neither always preserves the reasoning that connects an intent to an interface, a runtime decision or a boundary of authority. Memos exists to keep that reasoning legible while it is still alive. A note can start from a UX problem, a runtime behaviour, a visual experiment or a product hypothesis. Architecture is one of the tools used to answer it, not the only door in. ## What belongs here The subject is the work around useful agents: how an experience hosts intelligence, how a runtime plans and coordinates, how tools meet the world, how context is composed, and how execution stays observable and governed. That includes interaction design, generated interfaces, brand, harnesses, contracts, MCP and human control. MCP is part of the picture. It is not the definition of the system. ## From questions to decisions The writing will separate what exists today from what a system is moving toward. A current constraint, a target model and an open question are useful in different ways. They should not be presented as the same thing. A memo can start in the interface and end in the runtime, or the other way around. The test is whether the reader can see a trade-off, not whether the note used the right vocabulary. ## Designing Underlay Underlay is a design and technology project. The product should make work visible and keep chrome quiet. Three principles will keep coming back. Less interface, more work. Reduce the weight of menus. Keep goals, content and actions in the centre. Interfaces that respond to intent. The experience should adapt to the job, instead of forcing the job into a fixed structure. Clarity creates trust. States, confirmations, limits and results should be readable. They should not hide behind the magic of a model. [Figure: ] A full design guideline, with discarded alternatives and motion, belongs in a later memo. Here it is enough to show the sensibility. ## Close to the work The questions collected here come from building, testing and revising real systems. That proximity matters because abstract ideas become useful only when they survive contact with interfaces, constraints and failure. This is still an independent publication, not a product feed or a changelog. The work is the source of the questions, not the subject of every answer. ## Open does not mean finished Writing in public creates pressure to make every thought sound definitive. This space is meant to resist that. A memo can be provisional without being careless, as long as facts, interpretations and open questions remain distinguishable. Clarity matters more than cadence. Memos will grow when the work produces something worth keeping, not because a publishing schedule needs to be filled.