Trellis: Software Worth Keeping

Abstract

Software products make expert-built systems widely available by sharing their design and implementation across many users. Generative AI makes it easier to tailor software to individual needs, including for people without a software team. This need not mean rebuilding it: mature applications contain useful workflows, interfaces and engineering knowledge that are costly to rediscover. The opportunity is to combine shared foundations with personal software. The obstacle is continuing ownership: applications must be deployed, secured, recovered and upgraded, while local changes and integrations must remain compatible.

We propose Trellis, an agent-mediated operating layer for open-source applications that makes application-specific expertise reusable alongside the software itself. Developers describe how an application is deployed and inspected, what can be customized, which access each operation requires and how its results are checked. Agents apply this knowledge to install or adopt applications, diagnose faults, propose resource and configuration improvements, and develop tested adaptations and integrations. Trellis constrains execution through existing deployment tools and verifies results; routine monitoring does not require a model. Owners retain authority over deployment and changes while delegating routine administration.

The design combines application operators with malleable software and treats human attention as a resource alongside infrastructure. We develop it through an existing Plane deployment and a new Memos installation. The proposed evaluation asks whether shared operational knowledge and agent-mediated adaptation can reduce the expertise, cost and supervision small organizations need to own interconnected software, compared with the same applications and agent tools without Trellis.

1. Personal software, shared expertise

Shared software makes accumulated expertise available beyond the team that produced it. A project tracker carries decisions about assigning work, discussing it, finding it again and recovering from mistakes. Reusing the application lets each organization benefit from those decisions without rebuilding the system. Well-chosen abstractions also make selective change possible: Parnas’s account of modularity explains how hiding a design decision behind an interface can limit the effects of changing it.¹ The useful inheritance includes both working code and boundaries within which it can evolve.

A common product does not settle every local need. One company may want requests arriving by email to enter its project workflow; another may need a different review process or a view spanning several tools. Configuration, extensions and integrations already accommodate such differences. End-user software engineering has long studied people who develop software to accomplish their own work, including the requirements, reuse and testing problems they encounter.² Malleable-software research advances the related ambition of making the transition from using a tool to changing it more gradual.³ The opportunity is to make these adaptations accessible while retaining the parts of an application that already serve their users well.

Generative AI gives a new reason to pursue that ambition. Coding-assistance field experiments have found productivity gains in some organizational settings, while METR’s later methodological work shows how selection effects and time measurement complicate estimates.⁴⁵ These studies concern developers; they do not establish that non-specialists can independently operate production systems. They motivate a possibility: if expressing and implementing a local change requires less specialist effort, more organizations may be able to afford software tailored to their work. For Trellis, that is an opportunity to reuse and adapt established applications rather than assume their foundations must be regenerated.

Creation is only one part of ownership. Even an unmodified application needs deployment, security updates, monitoring and recovery. Local changes add compatibility obligations, and connections introduce dependencies between applications. Consider the email-to-project workflow: an initial demonstration is insufficient if a retry creates duplicate work or an upgrade breaks the connection. Someone must detect the failure, understand its consequences and restore the intended behavior. SRE’s distinction between repetitive operational toil and engineering that removes future work helps identify the burden to reduce.⁶ For a small organization, that burden consumes both money and attention; cheaper generated code need not mean cheaper software to own.

The next unit of reuse should therefore include the knowledge needed to operate and adapt the application. Application operators already establish part of this approach: Juju charms package operational procedures alongside references to their workloads.⁷ Trellis proposes to make such expertise accessible to agents across installations and local variations. Developers describe supported operations, customization points, required access and checks. Agents use this knowledge to interpret requests, diagnose faults and prepare changes; constrained software executes the permitted operations and verifies their effects. Owners decide which work to delegate. The expertise must still be developed and maintained, but each organization should not have to reconstruct it from a new conversation.

This connects personalization and operation in one product. Trellis’s intended audience is small organizations seeking control over their applications, local adaptations and connections without a dedicated software team. P1, P2 The research question is whether reusable application knowledge and agents can reduce the combined expertise, cost and supervision required, compared with the same applications, deployment tools and capable agent without Trellis. Preserving a customization through an upgrade is one test; operating an unchanged application with less intervention is another. The larger goal is to let organizations make software their own without making its upkeep their principal occupation.

2. Shared foundations, local differences

Two lines of work motivate Trellis. Application operators package knowledge about running a particular system. Juju charms associate operational code with an application; the Kubernetes operator pattern uses controllers to perform application-specific management. Both show that reusable software can include expertise about its continuing operation.⁷⁸

Malleable software addresses a different limitation: the distance between using software and changing it. Litt and colleagues advocate a gentler transition, composable tools and communal creation.³ Trellis takes an incremental route through that ambition. It begins with existing applications whose coherent interfaces remain useful, then makes selected changes and connections maintainable. This differs from replacing application boundaries with a shared toolkit from the outset.

The shared question is what knowledge must accompany an application so that another operator—human or agent—can take responsibility for it. Deployment assets say how to start it. Continuing operation also requires knowing which observations matter, how to investigate a failure, which changes are supported and how to recover. This knowledge is useful before anyone customizes the application. Trellis proposes to make it reusable across installations and accessible through an interface that agents can inspect and use.

A local adaptation extends that knowledge. It adds an upstream dependency, the difference being maintained, its intended behavior, tests, required access and a removal path. Configuration, extensions and source patches can use the same principle. An upgrade must then check both the application’s health and the behavior its owner chose to preserve. Ordinary versioned files can hold these records beside the application definition; a marketplace or new packaging system is unnecessary for the first example.

An application operator can already encode many of these procedures. A capable agent can already read documentation and invoke tools. Trellis’s proposed contribution is to connect reviewed procedures, diagnostic guidance, local constraints and durable operation state so that an agent can act on a particular installation without reconstructing its operating model. Whether that integration lowers total work—including the work of maintaining this knowledge—is the claim to test.

The common case should remain common. Ten installations using the same upstream release should reuse its operational knowledge. Only their configuration, bindings, granted access and adaptations need differ. The engineering challenge is to separate those differences without concealing interactions between them: a plugin can constrain an upgrade; a database setting can change recovery; an integration can widen access.

Self-hosting is only part of ownership. Local-first research distinguishes control over data and continued use from merely choosing where a server runs.⁹ Trellis should make the practical exit visible: where data lives, how it can be exported or restored, and how the application can run without Trellis. Local, hybrid and hosted deployments are different placements of these responsibilities, not interchangeable guarantees of sovereignty.

3. A small operating model

Trellis sits above deployment mechanisms such as Docker Compose and OpenTofu. Its job is to carry application knowledge across them and expose bounded operations to people and agents. It should reuse a suitable operator or deployment asset rather than translate everything into a new infrastructure language.

The proposed interface needs five distinctions. Each prevents a concrete failure; none requires a separate service.

A definition describes possibilities; local enrollment establishes which of them may be used. It can declare that a backup needs access to a database, but cannot grant itself database credentials. Adaptations attach to the application definition. Changes to application code and infrastructure both pass through the same planning and verification interface, with different backend procedures and tests.

Desired state and observed state must remain separate. Kubernetes provides a familiar precedent in its distinction between object specification and status.¹⁰ For Trellis, an observation also needs a timestamp and source. A successful HTTP request may establish endpoint reachability while leaving storage integrity or backup recoverability unknown. The interface should say which question was answered.

The prototype can extend its existing Python registry, application assets and adapters. Process boundaries follow isolation requirements; network services require a separate operational justification.

What the developer supplies

An application definition combines executable procedures with guidance for interpreting their results. Consider a proposed Plane check for storage headroom. For the deployed version, the definition must identify which discovered mounts hold database state, uploads and diagnostic logs, and which maintenance procedures require application coordination. This example describes the information needed, not a manifest already supported by the prototype.

The definition supplies application knowledge; the owner supplies local constraints such as retention, minimum headroom, spending limits and acceptable interruption. The agent relates observations to those constraints and proposes a remedy. Trellis resolves the actual target, enforces authority and invokes the reviewed procedure. Guidance can suggest an investigation; it cannot grant access or make a newly generated command executable. Definition changes that introduce new operations must pass review before admission.

This gives a replacement agent more than generic documentation: it can discover the supported checks and remedies, inspect their applicability and obtain installation-specific evidence through the same interface. The knowledge remains inspectable and versioned independently of the conversation. Missing instrumentation or an unsupported procedure must remain visible rather than being improvised into a capability.

Agents propose; constrained software acts

An agent supplies judgment where a fixed procedure is insufficient: discovering an unfamiliar application’s deployment options, interpreting a request, diagnosing a failure or preparing an adaptation. Routine checks and approved procedures should run without a model. Both the human CLI and agent tools should call the same application interface.

For a change, that interface resolves an installation, prepares a plan, obtains the required authorization, invokes a reviewed backend and checks the result. Authorization must cover the final plan. If the target, effects or relevant preconditions change, the system must reconsider it. Capability systems such as UCAN offer a useful precedent for scoped delegation and validation at execution; a token format alone does not enforce the scope inside a backend.¹¹

The executor must receive only the access needed for the operation. An agent’s ability to write a definition must not imply a general shell or reusable infrastructure credentials. Application content is also untrusted input: a note or issue asking an agent to change infrastructure has no authority merely because the agent read it.

Progress must survive interruption. Durable execution systems demonstrate the value of retaining operation history independently of workers.¹² Trellis can initially use its existing store. If a connection drops after a restart request, the next agent should see an uncertain attempt and obtain fresh evidence—not repeat the request because the preceding chat ended. Some effects cannot safely be retried without further inspection.

Internal approval, attempt and observation records support this behavior. The owner need not learn them as a vocabulary. They should see the application, the proposed change, the result and any decision that still needs them.

Attention is part of the interface

The default view should answer three questions: what is running, what needs attention and what can I change? Chat is useful for expressing an unfamiliar goal; a persistent view is better for comparing applications and seeing unfinished work. Mixed-initiative research motivates choosing when to act, ask or defer according to uncertainty and the cost of interruption.¹³

A routine check should be quiet when no action is needed. A failure should retain its evidence and offer a concrete next action. SRE monitoring practice distinguishes symptoms from causes and treats unnecessary alerts as a cost to the operator.¹⁴ A cost recommendation should show its source assumptions, expected saving and implications for capacity, recovery and reliability. Explicit thresholds and schedules can govern routine work. An agent is useful when evidence needs interpretation or the owner faces a trade-off.

4. Apply it to the application that already exists

An existing Plane deployment is a stronger design constraint than an empty example. The project’s September 8 inventory records Plane v1.4.1, a Compose deployment and a custom backend image. It also records missing evidence about that image’s provenance and retrievability, plus backup archives without a demonstrated restore. These are dated manual observations, not a completed Trellis adoption. P3

4.1 Discover without replacing

The first output is a candidate installation binding. It identifies the deployment assets, Compose project, running images, persistent stores, ingress and ownership boundaries. Shared routing and unrelated applications must remain outside the application operation’s authority. Secret references can be recorded without exposing their values to the agent.

Discovery must retain disagreement. If configuration names a mutable image tag while the running container has a specific digest, record both. If a custom image cannot be reproduced, mark that as a recovery and upgrade constraint. Do not substitute a clean upstream deployment and call the existing application adopted.

The developer then supplies a Plane definition over the discovered deployment mechanism. Its first procedures may be inspection and a bounded restart. The existing OpenTofu project provisions a different deployment; applying it over the live instance would not constitute import. This illustrates why Trellis must bind to actual resources before choosing an execution path.

4.2 Enroll, then inspect

Enrollment records the agreed binding and locally permitted operations. It does not restart, rewrite or relocate the application. Repeating it against unchanged facts should leave the binding unchanged. Conflicting ownership or unexplained drift should be shown before any operation is enabled.

Inspection turns the binding into a useful view: application and image versions, service state, storage location, recent checks and outstanding limitations. “Backup archive found” and “restore tested” are different findings. The owner should be able to inspect them without knowing how Trellis stores evidence.

The first integration test should use a disposable replica with representative non-sensitive data. Production discovery supplies constraints, not a convenient mutation target. If the custom image cannot be obtained or rebuilt, reproducing the installation is unfinished; a generic container cannot prove Plane compatibility.

4.3 Make one bounded change

On that replica, a restart plan names the selected service set, resolved deployment assets, relevant image identities and the observations on which it depends. It states the expected interruption and how recovery will be checked. Restart has no meaningful promise to undo elapsed downtime; a plan must describe its actual failure response rather than display a generic rollback badge.

After authorization, the backend acts only on the bound target. Verification obtains fresh service and application observations independently of the executor’s success message. The resulting operation record distinguishes a successful request, a recovered service and an unresolved outcome. Tests also check that neighboring services and production Plane did not change.

This establishes one change path. Continuing stewardship must use the same evidence and authority boundaries between explicit owner requests. Recovery also needs a separate demonstration with representative content restored into a clean environment.

4.4 Keep the application within its operating constraints

The September 8 inventory recorded limited disk headroom on Plane’s shared host. P3 Consider a prospective experiment using the definition from Section 3 on a disposable replica. The owner specifies minimum headroom, retention and recovery requirements, a spending limit and acceptable interruption. Scheduled checks compare fresh measurements with these constraints. While conditions hold, the system records the observations without interrupting the owner. Missing or stale measurements leave status unknown.

When headroom falls below the threshold, the definition supplies a read-only investigation of the bound storage locations. The agent compares measured growth with the retention policy and available procedures. Suppose it identifies application-owned diagnostic logs eligible for compression or expiry under the existing policy. It can recommend a reviewed maintenance procedure, estimate the space recoverable and explain its uncertainty. If authorized measurements cannot account for the pressure, Trellis reports the unexplained host-level finding to the host owner; it does not grant broader inspection or cleanup rights.

The plan names the exact eligible resources, retention rule, expected effect and verification. Execution requires the corresponding authorization. Approval for that log maintenance does not authorize deleting application data, shortening backup retention, purchasing capacity or cleaning neighboring services. If no supported remedy meets the owner’s constraints, Trellis presents the unresolved trade-off. Deferral preserves the issue and next check rather than silently lowering the threshold.

After execution, independent observations test the expected headroom improvement, application behavior and preservation of protected resources. A successful command without the expected result leaves the issue unresolved. The next scheduled check establishes whether the improvement persists. This is an illustrative procedure to implement and test, not evidence of an existing Plane capability. It shows the proposed benefit for an unchanged application: less repeated diagnosis and supervision while the owner’s operating constraints remain in force.

4.5 Keep the local difference

The existing custom backend is the first maintenance question, even if Trellis did not create it. Its purpose cannot safely be inferred from its image tag. Recover the source, build instructions and intended behavior, then express that behavior in a test. Until those facts exist, an upgrade recommendation must carry the uncertainty.

Once the operating release works, select one useful configuration or extension as the first new adaptation. Test its behavior, removal and compatibility with an upstream upgrade on a replica. On incompatibility, the useful result is a specific explanation and a choice: repair the adaptation, postpone the upgrade, remove the change or replace it with an upstream feature. Silently discarding it is not successful maintenance.

For example, suppose the owner wants new projects to start with the team’s agreed workflow. First check whether the installed Plane version already supports it. If a local change is needed, test project creation against that requirement before and after an upgrade. This is an illustrative requirement, not a claim about the existing custom backend or a selected release feature.

Provenance makes that choice easier. Record the requirement, source change, builder, upstream dependency and verification alongside the adaptation. PROV-DM’s distinction among entities, activities and responsible agents provides a conceptual model for these links.¹⁵ Ordinary version control and operation records are sufficient initially; a graph database is not needed to explain one change.

5. Build the common path, then test the larger claim

Plane constrains adoption; Memos constrains installation. Both should use the same application definition, binding, plan and result interfaces. Memos must add a different definition rather than a branch inside the core. An installation plan binds to a deployment target and reserved resource names before execution; successful creation fills in the resulting resource identities. Adoption discovers those identities in an existing deployment.

The implementation sequence follows those dependencies. The bounded Memos + Plane operating release comes first; continuing stewardship, adaptation and connection experiments belong to subsequent work, not additional requirements silently imposed on that release.

1. Define against evidence. Derive the minimum interface from existing Plane assets and Memos installation requirements. Keep unresolved facts explicit. Finish when both applications fit without losing their deployment-specific constraints.
2. Connect the operating path. Complete enrollment, listing, inspection, final-plan authorization, bounded execution and result inspection through one installed CLI. Prepare Plane’s adapter and replica while Memos exercises the shared path. Verify complete application journeys and refusal behavior.
3. Make ownership sustainable. Add tested recovery, scheduled monitoring, actionable diagnosis and one replaceable agent integration. Verify data and access after restore. Keep routine checks independent of the model provider.
4. Test adaptation and connection. Carry one useful adaptation across an upgrade or explain its incompatibility, then reuse it on another installation without the original conversation or credentials. A later selected cross-application workflow tests whether the same approach handles dependencies between tools.

The prototype does not yet complete step 2. It contains local application lifecycle code, a registry and experimental authorization and execution components; registered-target dispatch, generic Plane adoption and the full verified change path remain unfinished in the reviewed source. P3 This paper explains the target design. The existing Memos + Plane change specification remains the release authority. P4

Evaluation

The baseline should be competent reuse: the same application versions, deployment assets, operational source material, model and available compute budget without Trellis’s shared interface. Include mature operators where they supply the relevant behavior. Give both conditions the same owner constraints and require equivalent correctness, security and recovery outcomes before comparing effort. This tests the value of the integration rather than an advantage obtained by withholding useful tools or knowledge from the baseline.

Use matched tasks spanning installation or adoption, a quiet operating period, an injected fault, recovery and an upgrade. Include an unchanged application as well as one with an adaptation. Fix workload and observation windows and vary task order. Recruit participants from small organizations without a dedicated software team, record their prior operational experience and keep specialist assistance available but measured. Record incomplete tasks explicitly. An initial developer-run evaluation can establish functional correctness; it cannot establish accessibility to these owners.

Measure owner active time, specialist interventions, unresolved decisions, time to recovery, model usage and infrastructure cost. Include authoring, testing and maintaining definitions and adaptations, reporting one-time effort separately from per-installation work. SRE’s treatment of toil motivates counting work removed from future operation.⁶ Report useful and avoidable notifications together with missed incidents and detection delay: silence caused by overlooking failures is not reduced supervision. Lower cloud spend is not a gain if it creates more outages or maintenance.

Keep the functional refusal tests: unchanged re-enrollment, stale plans, expired or widened authority and interruption after dispatch. Then replace the agent with one that has no original conversation but the same permissions and durable records. Measure how quickly it establishes the state, whether it repeats an uncertain action and whether it can continue correctly. Restoration and adaptation removal must preserve representative content. Tests of an adaptation must exercise its intended workflow before and after upgrade, not just application health.

A later email-to-project experiment can test interconnection with non-sensitive fixtures. Define which incoming requests should create project items, who may see them and how duplicates are recognized. Exercise duplicate delivery, interrupted requests, expired access and an upstream schema change. Count missed or duplicated items, unauthorized disclosures and the work needed to restore the intended behavior. This is a proposed research task; it neither selects an email client nor changes first-release acceptance.

The strongest threat to validity is that curated definitions and developer familiarity account for the apparent benefit. Test transfer to an unfamiliar maintainer or installation and include the cost of preparing that knowledge. Trellis fails its central hypothesis if this continuing work matches the work it replaces, or if it hides obligations until a failure exposes them. Plane and Memos can reveal a broken abstraction; two prepared applications cannot establish general reductions in ownership cost. No results from these proposed experiments are claimed here.

6. Keep the ambition; earn the generality

The long-term opportunity is software that can fit a company without making that company a software vendor. Application expertise could be shared across installations, an agent could take over continuing work without reconstructing a conversation, and local adaptations could travel with their tests and maintenance requirements. Several applications could share operational policies while retaining their own data and interfaces.

Connections add obligations of their own. A shared context layer must preserve source permissions, freshness and meaning as schemas change. Cambria’s work on schema evolution shows why data translation deserves explicit treatment.¹⁶ The first useful connection should therefore solve a selected workflow with a declared data contract. A universal context graph can wait for demonstrated demand.

The near-term task is concrete: wrap the Plane that exists, install Memos through the same interface and complete the bounded operating release. Subsequent tests should establish whether reusable knowledge reduces the work of running an unchanged application, preserving a useful adaptation and connecting applications. The larger proposition is practical ownership: software that organizations can understand, direct and change without making its continuing operation their principal occupation.

References

External references support the claims beside which they appear. Research papers, design essays and implementation documentation are identified separately. The sources motivate this proposal; their authors do not endorse Trellis, and their results are not Trellis evaluation results.

Project sources

These sources have a different role from the literature: they establish product intent, local facts and existing constraints. Founder requirements are not empirical validation; project reports are not independent research.

P1 — Product intent. Tim Leers, recorded design conversations. Proven applications, made adaptable (repository: docs/source/2026-09-08-founder-malleable-direction.md), recorded September 8, 2026. Short attributed source record and original-message locator limitations.

P2 — Framing and editorial input. Tim Leers, feedback on the first paper, available September 11, 2026. Personal software and its upkeep (repository: docs/source/2026-09-11-personal-software-and-upkeep.md). Motivates the argument in Sections 1–2; the qualification about abstractions is this paper’s analysis rather than a quotation.

P3 — Prototype and deployment evidence. Trellis project. Launch readiness, September 8, 2026 (repository: docs/evidence/launch-readiness-2026-09-08.md); source revision 6d86d266ae39e9758f5157fe3db6ae4892b3d5c3. The v2 review note (repository: docs/evidence/2026-09-11-paper-v2-review.md) records reading and verification scope. Deployment findings are historical; no runtime experiment was performed for this paper.

P4 — Binding implementation constraints. Trellis project. Repository guidance (repository: AGENTS.md), ADR-0003 (repository: docs/decisions/ADR-0003-package-and-fleet-control-plane.md) and the Memos + Plane execution plan (repository: openspec/changes/manage-plane-and-memos/execution-plan.md). This research revision does not amend release acceptance or operational authority.

Version and method. V2, September 11, 2026; abstract, introduction and body revised September 12. Replaces the framing of the September 10 paper (repository: docs/research/2026-09-10-stewardship-contract-paper.md), retained for detailed historical derivation. Recent model-assisted writing practices and their evidence limits are recorded in a separate editorial research note (repository: docs/research/2026-09-11-model-assisted-paper-writing.md). Citation checks and agent review are recorded in the v2 review note (repository: docs/evidence/2026-09-11-paper-v2-review.md).