Acontext: Turning Agent Runs into Editable Skill Files
Agent Skills as a Memory Layer
At a glance
- What is it?
- Acontext is an open-source memory layer that distills agent session logs into Markdown skill files, retrievable by tool calls instead of vector search. It targets teams building agents with Claude Code, OpenClaw, or custom SDKs who want inspectable memory without embedding infrastructure.
- Who is it for?
- Adopt Acontext if you want memory that your agent can read and edit as plain Markdown, and if you prefer tool-based retrieval over embedding search. Skip it if you need fully offline operation without any LLM API dependency, or if your agent cannot call tools reliably.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 63 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Acontext Actually Stores and Why That Matters
Most agent memory systems store vectors or key-value pairs in a database. Acontext takes a different route: it writes memory as agent skill files, which are Markdown documents. The repository describes this as 'Skill is Memory, Memory is Skill.' The practical consequence is that you can open a memory file in any text editor, grep it, or mount it into a sandbox. There is no binary format and no vendor-specific encoding. The README claims you can download skills as a ZIP and run them elsewhere, which removes the migration burden typical of memory stores. This design targets developers who have watched opaque memory blobs corrupt agent behavior and want to see exactly what the agent learned. It also helps when you need to correct a wrong memory: edit the file, do not retrain or re-embed.
Distillation Pipeline: From Session Logs to Skill Updates
The learning loop has four stages, according to the flowchart in the README. First, session messages are collected, including conversation and optionally tool calls and artifacts. Second, a task is marked complete or failed, either by explicit agent reporting or automatic detection. Third, a distillation step runs: an LLM pass infers what worked, what failed, and what user preferences appeared. Fourth, a Skill Agent decides whether to write to an existing skill or create a new one, following the schema defined in your SKILL.md file. That schema is the contract. You define the structure, naming, and file layout; the system handles extraction, routing, and writing. For example, you could require one file per contact or one per project. This is not a black box. The output is human-readable, and the routing logic is driven by your instructions, not by a hidden clustering algorithm.
Recall by Tool Use, Not by Semantic Search
On the next run, the agent does not query a vector index. Instead, it gets Skill Content Tools named get_skill and get_skill_file. The agent decides which skill it needs, calls the tool, and receives the content into its context. The README calls this 'progressive disclosure, agent in the loop.' This is a deliberate rejection of top-k retrieval. The reasoning is that semantic search can return irrelevant chunks, and the agent has no way to reason about why those chunks were selected. With tool-based retrieval, the agent applies its own judgement about what is relevant. The trade-off is that the agent must know which skills exist and when to call them. That places a burden on the agent's reasoning and on the quality of skill names and descriptions. If your agent has weak tool-use discipline, it may simply ignore relevant memories.
Getting Started: Cloud, Self-Host, and SDKs
The quickstart has two paths. For the cloud, you go to Acontext.io, claim free credits, and complete a one-click onboarding to get an API key starting with sk-ac. Then you install the Python SDK with pip install acontext, or the TypeScript SDK from npm as @acontext/acontext. The client initialization is simple: pass the API key from the ACONTEXT_API_KEY environment variable. For self-hosting, the README provides a CLI installer: curl -fsSL https://install.acontext.io | sh. You must have Docker installed and an OpenAI API key. Then run acontext server up in a fresh directory. That command creates .env and config.yaml files, plus a db folder for persistence. The server exposes an API at http://localhost:8029/api/v1 and a dashboard at http://localhost:3000. The default model is gpt-4.1, and the README warns that your LLM must support tool calling. For Claude Code or OpenClaw, the setup is instruction-based: you tell the agent to read https://acontext.io/SKILL.md and follow it. There is no manual copy-paste of config shown in the README for those cases.
The Self-Hosted Path Still Depends on an External LLM
A genuine limitation is that self-hosting does not mean fully local operation. The distillation step requires an LLM with tool-calling ability, and the default is gpt-4.1 from OpenAI. If you self-host, you still need an OpenAI API key and network access to that provider. That may be acceptable for a proof of concept, but it undermines the promise of data control for teams with strict data residency rules. The README does not mention any option to plug in a local model such as Ollama or a vLLM endpoint. Also, the server persists data in a db folder, but there is no description of the database engine or backup strategy. If you run this in production, you need to inspect the generated config.yaml yourself to understand retention and access controls. The documentation is thin on operational details like scaling, authentication for the self-hosted API, or how to rotate the OpenAI key.
Framework and Vendor Lock-In: The Real Trade-Off
Acontext claims 'no vendor lock-in' because skills are plain files and you can export them as ZIP. That is true for the memory format. But the learning pipeline depends on Acontext's backend, whether cloud or self-hosted. The SDKs are only for Python and TypeScript, so if your agent is written in Go or Rust, you would need to call the REST API directly. The README mentions compatibility with LangGraph, Claude, AI SDK, and OpenClaw, but only through the skill content tools. There is no adapter for every agent framework. The bigger lock-in risk is the distillation logic: it is a black-box LLM call that you cannot fully control beyond the SKILL.md schema. If Acontext's backend changes its prompt or routing behavior, your skill files may look different over time. The ZIP export mitigates this, but only if you export regularly.
Alternative Approaches: Vector Memory and Manual Skill Registries
The most direct alternative is a traditional vector memory store like LangChain's memory or a dedicated vector database such as Chroma or Pinecone. Those systems embed conversation snippets and retrieve by cosine similarity. The difference is fundamental: Acontext retrieves by explicit tool calls and reasoning, while vector memory retrieves by statistical proximity. Vector memory can surface related information without the agent knowing its name, but it can also return irrelevant results and offers no easy way to inspect or edit what is stored. Another alternative is to manage skills manually: write Markdown files yourself, put them in a folder, and give your agent a tool to read that folder. That gives you full control but no automation. Acontext sits in between: it automates the distillation and writing, but leaves the retrieval and the schema to you. If you already have a disciplined skill library and only need automation for capturing new lessons, Acontext may be overkill; if you want to avoid embedding infrastructure entirely, it is a coherent choice.
Licensing and Maintenance Considerations
The repository is licensed under Apache-2.0, which permits commercial use, modification, and distribution, provided you preserve the license notice. That is permissive, but the README does not clarify whether the server code, the SDKs, and the UI are all under the same license. You should check each package's license file before embedding them in a proprietary product. The maintenance picture is mixed. The last push to the default branch was on 2026-07-14, and there are recent releases for the UI, the TypeScript SDK, and a Claude Code package, all from April 2026. That suggests active development. However, the project depends on external services: the cloud API for the hosted path and OpenAI for the self-hosted distillation. If the maintainers change the API or the cloud service shuts down, your self-hosted server may stop working unless you maintain a fork. The skill files themselves remain readable, but the automation layer is tied to the project's code and its default model choices.
Editorial conclusion
Adopt Acontext if you want memory that your agent can read and edit as plain Markdown, and if you prefer tool-based retrieval over embedding search. Skip it if you need fully offline operation without any LLM API dependency, or if your agent cannot call tools reliably. Before committing, verify that your target framework supports the skill content tools (get_skill, get_skill_file) and that your LLM provider permits function calling, since Acontext defaults to gpt-4.1 for distillation. Also test the self-hosted server with Docker and an OpenAI API key to confirm the data flow matches your security requirements.
Community notes