I built an AI system to tend my repositories. Then I rebuilt it.

Giving a model more tools quickly made Artemis more capable. It also made the engineering around those tools more important.

The original agent loop assembled broad project, memory and conversation context, exposed a large capability surface, and allowed the model to move through tool calls until the turn completed. That worked, but it made several questions increasingly difficult to answer precisely:

What context did this step actually need? What state must survive a process restart? When is a failed action safe to retry? How do you know whether an external side effect already happened? Which decisions belong to the model, and which belong to deterministic application logic? How do you measure whether a more selective architecture is actually better?

Artemis Lite started with a different division of responsibility. The application would own workflow lifecycle, persistence, approvals, retries, timeouts, recovery, context budgets and tracing. The model would own the decisions that genuinely required reasoning.

I wanted to test whether the repository-tending mission of Artemis could survive that constraint: not by reducing the final task to a toy example, but by rebuilding toward the same meaningful workflows.

The model can decide what evidence matters or how to approach a bug. It should not be responsible for remembering whether a side effect was already committed after the process restarts.

In Lite, a user goal becomes a persisted workflow with explicit steps and valid transitions. Every consequential operation sits behind typed boundaries. Approvals are records, not transient UI state. Usage is persisted. Trace events are append-only. Recovery starts from durable state rather than trying to recreate an in-memory conversation loop.

The target is still the original Artemis mission: oversee repositories, investigate engineering work, delegate implementation and return reviewable changes. The difference is that each stage now has an explicit contract and can be inspected independently.

The finished Lite workflow should demonstrate the architecture on a real engineering task rather than a synthetic agent loop.

The worker is deliberately not the authority. It receives a bounded task and environment, returns an implementation result, and the parent workflow resumes control for checks and verification.

Publication is another boundary. Artemis can do substantial work autonomously, but creating the external review artifact remains an explicit, persisted side effect.

One of the main experiments in Lite is treating context as a measurable input rather than invisible prompt plumbing.

For each reasoning step, the Context Builder can assemble the goal, current workflow state, selected repository evidence, GitHub evidence, prior tool results and relevant memory within an explicit budget. The inspector exposes that composition to the engineer.

A successful happy-path agent demo proves very little about a long-running workflow. Lite includes deterministic fault injection so the same workflow can be exercised under model timeouts, provider failures, tool failures and process interruption.

Recovery is based on persisted workflow state. Completed steps can be skipped, pending approvals can be reconstructed, and known side effects can be reused. Where the external outcome is ambiguous, the tool can reconcile against reality before deciding whether another execution is safe.

This is not a claim of generic exactly-once execution. Reconciliation is capability-specific. The point is to make ambiguity explicit instead of hiding it behind a retry loop.

Original Artemis could review several projects at once, combining repository activity with connected operational data. Lite retains that direction, but the briefing is built from explicit evidence sources and context selection.

A morning review should be able to surface changed repositories, failing checks, new issues, requested reviews, work already prepared by Artemis and workflows that need approval or recovery.

The purpose of Lite is not to claim that smaller prompts or explicit workflows are automatically better. The architecture is instrumented so those assumptions can be tested.

Quantitative results will be published from real evaluation runs. No placeholder metrics are presented as measurements.

Building Artemis changed how I think about AI product engineering. The first challenge was capability: connecting a model to repositories, tools, memory, monitoring and workers. The harder challenge appeared once those capabilities started doing real work.

Long-running agentic systems need ordinary software-engineering properties around the model: explicit state, durable persistence, narrow interfaces, permission boundaries, recovery semantics, observability and tests. They also need a clear answer to a less obvious question: what should the model not be responsible for?

Artemis Lite is my attempt to make that boundary visible. The model reasons. The application remembers what happened.