AriesGent

AriesGent is a research-oriented personal agent runtime. It inherits the foundation of GenericAgent and reworks its core runtime around a smaller, more inspectable architecture for agent research and long-horizon task execution.

Research status: This is an experimental project. Interfaces, provider configuration, and memory formats may change while the system is evaluated.

AriesGent began as a continuation of GenericAgent, an open-source general-purpose agent project. The original project provides the starting point for an agent that can reason, use tools, browse the web, operate on files, and retain useful knowledge.

This repository takes that foundation in a research direction: make the core execution path easier to reason about, make failures observable, and create a better platform for testing ideas about persistent learning and reliable multi-step work.

Aries is the name of my two-year-old daughter. Watching her encounter the world is a daily reminder that learning is not simply collecting facts: it is trying, noticing, forgetting, connecting, asking again, and gradually building better intuitions from small experiences.

AriesGent is named with the hope that this project can grow alongside her. It is our small attempt to study agents that learn a little more like people do: curious enough to explore, careful enough to remember what mattered, and humble enough to revise a lesson when the world proves it wrong. No toddler-level chaos is required from the runtime—though a little curiosity is very welcome.

We simplified and redesigned the core architecture to make it a better fit for research. Instead of treating the agent as one opaque loop, AriesGent separates conversation state, task execution, tool modules, memory retrieval, and completion checks. The result is a smaller system whose behavior is easier to inspect, measure, and change when testing a research hypothesis.

The old Streamlit interface has been replaced with a browser chat client served by Flask. Rather than relying on a framework rerun for each interaction, the client explicitly sends chat, continuation, and tool-execution events to the server. This makes a tool-using turn visible as a sequence of interactions: the user sends a request, the agent proposes tool calls, the UI executes or reports their results, and the agent continues until it has a grounded answer.

The interface is deliberately small. Its role is to expose the agent runtime, not to hide it behind a heavy UI layer. That makes it easier to prototype new interaction patterns and to diagnose where a long task stopped making progress.

codes/chatllm_session.py routes model access through the Cline-compatible uni-llmchat client. A single configured account can select among the models and providers it supports, while the rest of the agent continues to use one conversation and tool-calling interface.

This separation is useful for research: model choice becomes a configuration decision rather than a rewrite. The session layer also owns conversation history and context handling, so provider experiments can be performed without mixing transport details into planning, memory, or tool code.

Google is useful, but depending on one search engine makes autonomous web research fragile. AriesGent provides multiple search-engine candidates with a common tool interface. When an engine is blocked, rate-limited, unavailable, or simply unhelpful for a query, the agent can choose another candidate instead of treating the failed search as the end of the task.

The search tool is paired with URL-opening and browser automation utilities. Together, they let the agent move from a query, to a result page, to an inspectable source while retaining the tool output needed to justify later steps.

The original layered memory files remain the canonical and human-readable record. AriesGent adds a deterministic graph catalog over them: memory facts, skills, tools, and supporting resources are indexed as nodes and linked by their relationships. A query retrieves the most relevant small set of entries instead of adding the entire memory store to every prompt.

This has two intended benefits. First, it helps the agent rediscover useful knowledge that would otherwise be buried in an expanding memory directory. Second, it separates retrieval from storage: researchers and users can still read, review, and correct the underlying Markdown files directly. The graph is an aid to recall, not an opaque replacement for the memory source.

Long tasks often fail quietly: an agent completes some work, loses track of a remaining subtask, and writes a plausible but false completion message. To address this, AriesGent turns each executable request into a concise ledger:

1. The agent first records the objective, ordered steps, constraints, and any durable-memory candidates.
2. The runtime derives completion requirements for concrete actions, such as a downloaded artifact, a modified workspace file, a successful command, or an opened URL.
3. Tool results add evidence to those requirements as work actually happens.
4. Finalization is blocked if required evidence is still missing; the agent is prompted to continue working or to state the real blocker.

This is not a guarantee that every task will succeed. It is a practical guard against unsupported self-reports of completion, and it gives researchers a clear trace for studying where long-horizon execution succeeds or breaks down.

The ledger also treats evidence as a first-class part of tool use. For example, a truncated tool response that was saved to disk must be inspected before the agent reasons from it; a URL is not considered a downloaded file; and an unsuccessful command is not a completed command. These checks favor observable state over a model's confidence, which is especially important when evaluating agent reliability.

Our long-term focus is human-like learning: agents that do more than store a growing pile of task notes. We want them to revisit experience, extract what is generalizable, and make that knowledge useful in later work while preserving the ability to inspect and correct it.

Dreaming mode is our working name for an offline or low-priority consolidation process inspired by the way sleep is often associated with memory processing. The analogy is intentionally modest: we are not claiming that an agent dreams like a person. We are exploring whether a separate reflection pass can improve what an agent learns from completed work.

During normal task execution, the agent produces short-lived material such as conversation summaries, tool traces, failed attempts, successful procedures, and tentative observations. Keeping all of it forever would make memory noisy; discarding all of it would repeat the same mistakes. Dreaming mode is intended to sit between those two extremes.

flowchart LR
    A[Task experience<br/>traces, outcomes, observations] --> B[Candidate review<br/>what is reusable?]
    B --> C{Worth retaining?}
    C -- No --> D[Keep only the task record<br/>or allow it to expire]
    C -- Yes --> E[Distill and link<br/>fact, skill, or procedure]
    E --> F[Reviewable long-term memory]
    F --> G[Graph retrieval in a future task]

In rough terms, the workflow is:

1. Collect candidates. Identify observations or procedures from task history that may matter again—especially a reliable method, a recurring constraint, or a lesson from a failed approach.
2. Distill. Rewrite a useful candidate into a short, general statement or procedure. The goal is to preserve the lesson, not a raw transcript or a private detail.
3. Validate and scope. Check whether the candidate has supporting evidence, whether it is safe to keep, and where it belongs. Personal or sensitive information should require explicit consent rather than being retained by default.
4. Connect. Store accepted knowledge in the readable memory hierarchy and connect it to relevant skills, tools, or resources in the graph catalog.
5. Reuse and evaluate. On a later task, retrieve the memory only when it is relevant, then measure whether it improved the outcome rather than merely increasing the amount of context.

A preliminary version of this learning workflow is implemented and still under test. The open research questions are as important as the mechanism itself: which experiences are worth consolidating, how to avoid reinforcing an error, when to forget or revise outdated knowledge, and how to demonstrate a genuine improvement in recall and long-horizon task success. For now, dreaming mode should be treated as an experimental research direction rather than a finished continual-learning system.

• Python 3.10 through 3.13
• A configured LLM credential. The runtime reads CLINE_API_KEY; when it is not set, it falls back to OPENAI_API_KEY.
• The local editable uni-llmchat package referenced by pyproject.toml, or an equivalent package installation available to your environment.

Create an environment and install the project dependencies with your preferred Python package manager. For example, with uv:

Set the path of uni-llmchat library in pyproject.toml '{ path = "../021.uni_llmchat", editable = true }'.

uv sync
export CLINE_API_KEY="your-api-key"
uv run python server.py

Then open http://127.0.0.1:5001 in a browser. The default model and provider settings live in codes/config.py; update them to match the models available through your account.

To run the test suite:

uv run pytest

• Keep durable memory human-readable and reviewable.
• Retrieve only task-relevant memory instead of inserting the entire memory store into every prompt.
• Turn intended outcomes into explicit, checkable task state.
• Prefer evidence over a model's unsupported declaration of success.
• Keep research experiments modular so they can be evaluated, replaced, or removed without rewriting the entire agent.

This project is released under the MIT License.