AI research
Ji
An experimental foundation for a general computer agent: durable work, changing goals, and verifiable progress.
Ji is an experimental general computer agent. Give it a goal, and it uses models and tools to investigate, make changes, and check the results. I’m building it to carry work across interruptions and respond when requirements change.
The current agent reads and searches files, edits code, runs commands in an isolated environment, and checks applications through HTTP requests. For example, it can work on a task-list application: investigate how due dates are stored, change which tasks appear in an Overdue view, run tests, and check the behavior after a server restart. Coding is the first testbed for the broader agent.
Its Rust runtime owns tool execution, records actions and results, and supports recovery after interruptions. Each run has configured limits on tool and model requests and on generated output. The saved history lets Ji check unfinished work when it resumes, including work affected by a revised goal.
Ji’s controller decides what to do next. It can ask a language model to interpret a test failure, propose a code change, or choose a tool to run. For focused decisions, such as which file to inspect, a separate interface lets me compare specialized models with rules. I can replace these decision methods, or the whole controller, without rewriting the code that runs tools and saves their results.
The research asks how to make an agent useful over longer stretches of work: preserve what it has learned, adapt to new instructions, and check whether it achieved the user’s goal. A separate evaluator checks the results of the coding studies.
How it works / Explore the workflow
Acting and checking what happened
The controller chooses an action: read a file, make a change, or run a test. The runtime records what it is about to do and then saves the result. After a restart, it checks unfinished work before continuing. A separate evaluator tests the requested behavior in coding experiments.
Learnings
An agent needs to carry useful information from one step to the next. In one set of Ji runs, the model identified the defect nine times, but only two runs repaired it. Later model calls did not receive the earlier reasoning. Before asking for a better answer, I needed to make sure the agent could use the answer it already had.
The surrounding software also affects how well a model can do its job. How does it receive earlier reasoning? How are its tool requests interpreted? What can it find through search? Comparing one change at a time helps identify which of these affects task success. The combined changes tested in Ji did not produce an overall improvement; gains on some tasks came with losses on others.
An agent’s own tests can repeat the same misunderstanding as its code. Passing them is useful, but the requested behavior still needs an independent check. In Ji’s studies, a separate evaluator rejected many completed runs even though the agent had passing tests. This is a practical reason to keep acceptance checks separate from the process that writes the solution.