Forem: Acontext

The Missing Infrastructure for AI Agents: Unified Context

Acontext — Fri, 06 Feb 2026 17:11:00 +0000

Acontext is a data platform designed to store multimodal context data, monitor agent success, and simplify context engineering.

For all the talk about 'agents', the word itself has become surprisingly fuzzy. In research circles, startup decks, and engineering teams, people often refer to very different things using the same term. And that confusion hides an important truth: most systems we casually call agents today are not actually agents in any meaningful sense.

A tool-calling LLM is not automatically an agent.
A model wired to two predefined tools, even if it chooses when to call them, rarely feels like an agent.

And many projects that appear agent-like are, in practice, deterministic workflows disguised behind prompting.

The distinction matters, not for semantics, but because we are finally seeing real AI agents emerge, and if we want to build the next generation of systems, we must understand why some models behave like agents… and why most don't.

The Gap Between Tools and True Agents

The industry is full of examples where people script a multi-step prompt:

''First, call this tool. Then call that tool. Then summarize the result.''

This is not an AI agent. It's simply a workflow encoded through natural language.

The intuition people hold about agents points to something much more profound:
An agent should be capable of outcomes far beyond what its tools explicitly encode.

That is why Claude Code or Codex feels magical. Their tool implementations are trivial: any Computer Science intern can write a read\_file, write\_file, or exec wrapper. Yet no intern can outperform the model when actually coding.

Tools are mundane.

Behavior that emerges from them is not.

This gap between the simplicity of tools and the sophistication of behavior is the first real clue to what a true agent actually is.

Workflow Builders vs Agent Builders

Once you recognize this gap, the real question becomes: What separates building workflows from building agents?

It comes down to mindset.

Workflow builders think in sequences:

What should be executed first?
What comes next?
What conditions trigger which branch?

Agent builders think in environments:

What environment does my agent operate in?
What are the atomic actions available in this scope?
Does the combination of those actions theoretically cover the action space of a human operator?
What guidelines shape behavior in this environment?

To build agents, you must shift from scripting procedures to designing environments.
Agents emerge not from control, but from well-constructed uncertainty.

The Heart of It All: Context Engineering

Once you step into the environment mindset, a new challenge appears: Your agent is only as capable as the context it can see, retrieve, and use, which means context, not tools, not prompts, is the real substrate of intelligence:

Define a complete and accurate tool set
Define human guidelines and behavioral constraints
Determine the agent's real-time context state
Decide what to load into context and what to offload
Enable the agent to discover new context when needed

Today's discussion around 'context' is dominated by RAG and MCP, but search and tool schema only cover a tiny slice of the problem. Context Engineering is about managing the entire universe of information that an agent can act upon.

A helpful way to think about it is through three types of context:

In-Session Context

The live state of an ongoing interaction.

Most of the engineering work today focuses only here.

External Context

Everything the agent can discover or load: skills, files, knowledge bases, artifacts, and tool descriptions.

Claude Skills is the first industry example in which the builder community has truly embraced this idea. Claude Skills isn't a protocol, it's a way of thinking. It frames context as *experience*,not data, and encourages selective loading rather than building a human-like search index.

Manus follows a similar pattern in its sandbox: its terminal-use exposes discoverable tools and lets agents dynamically uncover new capabilities.

Cross-Session Context

This is what the agent has done before. Traditionally called 'memory', but memory is too weak a word.
What agents really need is experience. Check out more about its differences from memory layer↗.

Understanding and engineering these layers is the real work of agent design.

Why the Agent Era Needs a Context Data Platform

Look at the current landscape.

Developers have frameworks such as LangGraph, Agno, and n8n to orchestrate agent workflows. These tools help with execution, but not with context.

The intelligence of an agent no longer sits in the workflow.
It sits in context.

Yet we still lack a platform dedicated to:

storing all context data
engineering its structure
observing agent behavior
capturing reusable experience
providing continuity across tasks and sessions

If context is now the source of complexity and intelligence, we need infrastructure built for it.

We need a new category—a Context Data Platform.

We call it Acontext↗, a platform designed to store multi-modal context data↗, to monitor agent success, and to provide a layer of certainty amid the inherent uncertainty of agent behavior.

It focuses on two core problems:

How to move the storage and observability of context data into the cloud
How to ensure that when a powerful agent completes a complex task right once, it can continue getting it right every time thereafter

What Lives Inside Context Data?

Acontext is built around this new category, which can manage:

Multi-Modal Messages

Messages from OpenAI, Anthropic, Gemini, and future providers: all normalized, stored, indexed, and accessible across sessions. Text, code, PDFs, images, upcoming modalities, Acontext can handle them for you seamlessly.

No more gluing Postgres, S3, Redis by hand: How Acontext Stores AI Messages?↗

Artifacts

Agents need a place to store what they produce.

Acontext's Artifact Disk offers a cloud-hosted filesystem abstraction (based on Linux file path): intuitive for agents, scalable for developers.

Plan & Task Observability

What did the agent promise?

What did it do?

Was it successful?

Acontext includes background observers that track tasks, gather user feedback, and help quantify agent success.

How to Improve Agents' Success Rates?

The logic is simple: when an agent gets something right, it should keep getting it right; when it gets something wrong, it should avoid repeating the mistake.

Acontext builds a Skill Space for capturing these execution patterns. An internal Experience Agent detects meaningful tasks, extracts the successful workflow, and stores it in a structured space so future agents can reuse it automatically.

This is not memory in the traditional sense.
It is the accumulation of SOPs: the practical know-how generated through real agent–human collaboration.

From context to skill, a further breakdown in this blog: Inside Acontext: How AI Agents Learn from Experience↗

For the Visionaries Building What Comes Next

Acontext is open source.

We're actively developing it with the community and learning from builders pushing the boundaries of agent capability.

If you see the future of agents the way we are doing, we'd love for you to explore Acontext.

GitHub: https://github.com/memodb-io/Acontext

One line of code to launch the full stack with curl -fsSL https://install.acontext.io | sh.

The agent era has entered the era of context. Let's build the infrastructure it deserves.

Native Per-User Resource Management for Multi-Tenant AI Apps

Acontext — Thu, 05 Feb 2026 17:37:00 +0000

Associate resources with users, filter by user, and clean up with cascade deletion - all in a few lines of code.

Building multi-tenant AI applications has always required custom infrastructure for user isolation and resource management. With this release, Acontext now supports per-user resource management natively.

What's New

You can now associate any Acontext resource (Spaces, Sessions, Disks, Skills) with a user identifier. This enables:

Multi-tenant isolation without separate API keys per user
User-scoped queries to retrieve only a specific user's resources
Cascade deletion to clean up all resources when a user leaves

How It Works

Associate Resources with Users

Pass a user parameter when creating resources. Users are created automatically when first referenced.

from acontext import AcontextClient

client = AcontextClient(api_key=os.getenv("ACONTEXT_API_KEY"))

# Create a space for a user
space = client.spaces.create(
    user="alice@example.com",
    configs={"name": "Alice's Workspace"}
)

# Create a session for the same user
session = client.sessions.create(
    user="alice@example.com",
    space_id=space.id
)

# Create a disk for the user
disk = client.disks.create(user="alice@example.com")

import { AcontextClient } from '@acontext/acontext';

const client = new AcontextClient({ apiKey: process.env.ACONTEXT_API_KEY });

// Create a space for a user
const space = await client.spaces.create({
  user: 'alice@example.com',
  configs: { name: "Alice's Workspace" }
});

// Create a session for the same user
const session = await client.sessions.create({
  user: 'alice@example.com',
  spaceId: space.id
});

// Create a disk for the user
const disk = await client.disks.create({ user: 'alice@example.com' });

Filter Resources by User

All list operations now support user filtering:

# List only Alice's resources
spaces = client.spaces.list(user="alice@example.com")
sessions = client.sessions.list(user="alice@example.com")
disks = client.disks.list(user="alice@example.com")
skills = client.skills.list_catalog(user="alice@example.com")

// List only Alice's resources
const spaces = await client.spaces.list({ user: 'alice@example.com' });
const sessions = await client.sessions.list({ user: 'alice@example.com' });
const disks = await client.disks.list({ user: 'alice@example.com' });
const skills = await client.skills.listCatalog({ user: 'alice@example.com' });

Cascade Delete Users

When a user leaves, clean up everything in one call:

# Delete user and ALL associated resources
client.users.delete("alice@example.com")

// Delete user and ALL associated resources
await client.users.delete('alice@example.com');

Use Cases


Scenario	Before	After
Multi-tenant apps	Self-managed user-resource mapping	Native user parameter
User offboarding	Manual cleanup across resources	One users.delete() call
Per-user queries	Self-maintained filtering logic	Native user filter parameter

The feature is available now in:

Python SDK: pip install acontext --upgrade
TypeScript SDK: npm install @acontext/acontext@latest

Have feedback or questions? Join us on Discord↗ or open an issue on GitHub↗.

How to Handle Growing AI Context Without Endless Scripts

Acontext — Wed, 04 Feb 2026 17:18:00 +0000

Learn how Acontext simplifies context engineering from days of manual work to just a few hours，and why a context data platform matters for production agents.

When building AI agents, the real source of complexity is rarely the model itself. It's the context around it.

Model capabilities have improved rapidly, but anyone who has built a production-grade agent knows the pattern: as soon as the system runs longer, handles tools, or spans multiple turns, the hard work shifts away from prompting and into context engineering.

Why does context engineering become the real bottleneck?

In practice, 'context engineering' is not an abstract idea. It is a collection of very concrete engineering tasks:

Storing text, images, memories, artifacts, tool calls...
Managing sessions that grow unbounded over time
Switching message formats across OpenAI, Anthropic, and Gemini
Truncating or filtering context without breaking semantics
Answering:'What exactly did the LLM see at that moment?'

These tasks share a few traits: almost every production agent runs into them; they are ongoing costs, not one-time work; they tend to be implemented as ad hoc scripts and glue code.

As a result, teams often spend more time maintaining context logic than improving the agent's actual reasoning or behavior.

A Simpler Pattern: Context Data as a Unified Layer

The problem is not that context engineering is inherently complex, but that it usually lives in the wrong place.

A more inspiring mental model is to treat context as a system-level data concern rather than as*prompt logic.*

This model has three core ideas:

Context data maintains complete Raw messages and artifacts should be stored intact, not rewritten or mutated as the session evolves.
Editing is in visible control, not a mutation Truncation, filtering, and token control should happen at retrieval, while the original session remains unchanged. Developers can utilize clear context window usage to determine if they need to edit the context.
Rules over scripts Instead of scattering heuristics throughout business logic, developers can describe how context should be shaped using declarative rules.

With this shift, context engineering becomes predictable and reusable rather than fragile and bespoke.

Acontext Simplifies Context Engineering in Two APIs

Seen this way, 'a few lines of code' does not mean doing less work. It means moving complexity into the system layer, where it can be handled consistently.

Acontext follows this approach with two APIs: store_message() and get_messages()

Raw context is stored once
Context editing happens only when messages are retrieved
Editing behavior is defined through explicit strategies
The same rules apply across agents and sessions

Code in Action: Context Editing On-the-fly

The example below shows how context editing is moved from application logic into a declarative read step.

Instead of pulling messages, counting tokens, trimming history, and rebuilding model inputs in code, the application describes its editing rules once and passes them to get_messages. Acontext applies those rules consistently and returns an edited view of the session.

Because editing happens at read time, changing context behavior does not require rewriting storage logic or reprocessing historical data. You can adjust strategies, compare different views, or reuse the same rules across agents without duplicating code.

Editing Strategies Ready-to-use:

get_token_counts() You can inspect the current token size of a session before editing. Benefit:context editing becomes data-driven instead of heuristic-based.
token_limit Truncates the session by removing the oldest messages until the total token count is within a specified limit. Tool-call and tool-result pairs are preserved correctly. Benefit:no custom truncation logic, no broken tool histories.
remove_tool_result Replaces older tool result contents with a placeholder, while keeping recent results intact. Benefit:large, verbose tool outputs*no longer consume*context without losing execution structure.
remove_tool_call_params Removes arguments from older tool calls, keeping only IDs and names so tool-results can still reference them. Benefit:reduces token usage while preserving causal links between tool calls and results
middle_out
offload_to_log
remove_by_completed_tasks
...

from acontext import AcontextClient

client = AcontextClient(
    base_url="http://localhost:8029/api/v1",
    api_key="sk-ac-your-root-api-bearer-token"
)

edited_session = client.sessions.get_messages(
  session_id="session-uuid"
  edit_strategies=[
    {"type": "token_limit", "params":{"limit_tokens": 20000}},
    {"type": "remove_tool_result", "params": {"keep_recent_n_tool_result": 3}},
    ...
  ],
)

original_session = client.sessions.get_messages(
  session_id="session-uuid"
)

In practice, this reduces the amount of glue code developers maintain, shortens iteration cycles when tuning context behavior, and makes context engineering more predictable rather than ad hoc.

Why a Context Data Platform Matters for Production Agents

This unified data layer abstraction is not about making AI agents look better in a demo. It is about making them behave reliably in real production environments, where context grows, tools run repeatedly, and failures are expensive.

In practice, teams begin to see clear, concrete improvements:

Long-running tasks fail less often because context growth is handled safely and consistently
Agent behavior becomes predictable and reproducible across runs, environments, and model upgrades
Debugging no longer depends on guessing what the model may have seen at a given moment
Context engineering recedes into the background, treated as infrastructure rather than application logic

When context is treated as a first-class system concern through a dedicated data platform, production agents become easier to reason about, easier to debug, and significantly easier to maintain as systems evolve.

The Way Forward

Context engineering does not have to take days of manual work.

With Acontext, tasks that once required days of custom wiring can be done in hours: safely, consistently, and without rewriting the same glue code.

That is what simplifying context engineering means in practice.

If this aligns with how you build agents, please do try Acontext in a real workflow.

Share what works, what breaks, and what you wish existed.

Join the community, give feedback, and help agent builders shape the open-source roadmap.

GitHub: https://www.github.com/memodb-io/Acontext↗
Discord: https://discord.gg/SG9xJcqVBu↗

Self-Learning Agents: From Prompt Evolving to Experience Learning

Acontext — Tue, 03 Feb 2026 17:32:00 +0000

Acontext vs. DSPy: Why self-learning AI agents require user-specific experience, not global prompt evolution.

A self-evolving agent framework like DSPy works beautifully when you can define a clear eval for your entire product. With a stable metric, it can evolve prompts and steadily improve overall performance. But agent self-learning in real applications is not 'global' at all, it should be per user, per task.

Users bring different goals: one uses Manus to build a website, another for trip planning, and another for code and architecture docs. These tasks don't share a single success definition. And without a unified eval, DSPy has nothing to optimize toward.

Some might imagine running a separate DSPy loop for each user. But as soon as you try, two structural problems appear.

The system prompts fragments into countless user-specific variants, which are long, unstructured, and impossible to maintain.
Each user would need a specific evaluation, but user tasks vary too widely to define and maintain at scale.

The result is clear: prompt evolution cannot deliver accurate per-user self-learning. It's built for overall intelligence improvement, not task-driven adaptation.

Acontext: User-level Experience Learning

Acontext takes a different path. It never rewrites your prompts or asks you to design evals. It learns directly from real execution and real user confirmation in a Notion-style Skill Space:

No prompt changes:Your system prompt stays clean. The learned skill lives in the user's workspace, not in the prompt.
No eval design required:Acontext uses real user feedback as the signal: confirmation equals success; negative feedback equals failure; silence does not count.

Developers also get direct visibility into what's happening: per-user success rates, day-over-day changes, and task volume, so the learning process is transparent rather than a black box.

Acontext is intentionally conservative about what to learn. Only complex, multi-step experiences become skills; trivial tasks are ignored. And when needed, you can require explicit user approvalbefore a new skill is added: https://docs.acontext.io/learn/advance/wait-user↗

Try Acontext

If you're building agents and want them to learn from real experiences, Acontext is ready for you. It's open-source, and we're improving it rapidly with the help of the community.

👉 GitHub: https://github.com/memodb-io/Acontext↗ ⭐️ Give it a star, explore the examples, and try it in your agent stack.

🤟Discord: https://discord.acontext.io↗

If you try Acontext, please let us know how it works for you. We'd love to hear your feedback and see how we can make Acontext more helpful.

How Acontext Stores AI Messages?

Acontext — Thu, 29 Jan 2026 17:11:00 +0000

Agent developers shouldn't be writing custom message converters every time providers change their APIs. You need to work with messages from OpenAI, Anthropic, and other providers—but each one structures messages differently. Without a unified approach, you end up with fragmented, inconsistent data that's hard to store, query, and learn from.

Building reliable agent systems requires treating message data as first-class infrastructure. Acontext provides a unified and durable message layer that makes context observable, persistent, and reusable. You send messages in any format—OpenAI, Anthropic, or Acontext's unified format—and they just work.

This post explores how Acontext stores and normalizes multi-format messages, the architecture that makes it possible, and what this means for building production-ready agents.

The Problem: Format Fragmentation

Today, agent context is scattered across different formats, storage systems, and provider-specific structures. The result? Fragmented, transient, and nearly impossible to analyze over time.

Consider what happens when you build an agent that needs to work with multiple providers:

Format Fragmentation: Each provider uses different message structures. OpenAI uses tool\_calls[] with nested function.name and function.arguments, while Anthropic uses tool\_use[] with name and input. Without normalization, you can't query or analyze messages uniformly.

Information Loss: During format conversion, important metadata (tool call IDs, message names, source format) often gets lost or becomes inconsistent. You end up with incomplete context that can't be reliably used for learning or debugging.

Storage Inefficiency: Storing large message payloads (images, files, long text) directly in PostgreSQL bloats the database and slows queries. But storing everything in object storage makes querying complex and loses transactional guarantees.

Provider Lock-in: Systems become tightly coupled to one provider's format. When a new provider emerges or an existing one updates their API, you're rewriting converters and risking breaking changes.

All these challenges stem from one root cause: message data is not treated as first-class infrastructure.

We don't need another database or storage system. We need a unified layer that accepts messages in any format, normalizes them to a consistent representation, and stores them efficiently—all while preserving every piece of context. That's what Acontext does.

The Solution: Unified Message Processing

Acontext's message processing system provides a single interface through which your agents can flexibly receive, normalize, and store messages from any provider. Here's how it works:

Multi-Format Support

Instead of requiring clients to convert messages to a single format, Acontext accepts messages in their native format (OpenAI, Anthropic, or Acontext's unified format) and normalizes them internally.

This means:

Clients can use their existing SDKs without modification
The system validates messages using official provider SDKs, ensuring spec compliance
Format conversion happens once at ingestion, not repeatedly during processing

Acontext uses normalizers as adapters that translate provider-specific formats into a unified internal representation, so your downstream systems only need to understand one format.

Complete Context Preservation

Different providers structure messages differently. Without careful normalization, this information gets lost.

Acontext preserves all metadata by:

Storing the original source format in message metadata
Unifying field names (e.g., tool\_use → tool-call, input → arguments)
Preserving provider-specific metadata in a flexible meta field

This ensures downstream systems can handle tool calls uniformly while still accessing original provider-specific information when needed.

Efficient Hybrid Storage

Messages can contain large payloads—images, files, or long text content. Storing these directly in PostgreSQL would bloat the database and slow queries.

Acontext uses a three-tier storage strategy:

PostgreSQL stores lightweight metadata (message ID, session ID, role, timestamps)
S3 stores the actual message parts as JSON files, referenced by the database
Redis provides hot cache for frequently accessed message parts, reducing S3 reads
Content-addressed storage using SHA256 hashes enables automatic deduplication

This separation allows the database to remain fast for queries while S3 handles large payloads efficiently. Redis caching ensures hot data is served instantly without hitting S3, dramatically improving read performance for active sessions. It's like having a filesystem with intelligent caching for your agent's context data.

Provider Flexibility

As new providers emerge or existing providers update their formats, the system needs to adapt without breaking existing functionality.

Acontext achieves this through:

Pluggable normalizers: Each provider has its own normalizer that can be updated independently
Unified internal format: Downstream systems only need to understand one format
Format versioning: Message metadata tracks the source format, enabling format-specific handling when needed

Architecture: Layered Design

Acontext's message processing follows a clean layered architecture that separates concerns, making it easy to add new providers or modify existing behavior:

Router Layer: Handles HTTP routing, authentication, and extracts URL parameters. It's format-agnostic and focuses on request routing.

Handler Layer: Detects content type (JSON vs multipart), parses the request, and validates the format parameter. It orchestrates the normalization process but doesn't perform format-specific parsing.

Normalizer Layer: This is where format-specific logic lives. Each provider has its own normalizer that:

Uses the official provider SDK for validation (ensuring spec compliance)
Converts provider-specific structures to the unified internal format
Preserves metadata and handles edge cases

Service Layer: Handles business logic—file uploads, S3 storage, Redis caching, reference counting. It works with the unified format, so it doesn't need to know about provider differences. The caching layer ensures hot data is served instantly while maintaining S3 as the source of truth.

Repository Layer: Manages database operations and transactions. It stores metadata in PostgreSQL and references to S3 objects.

This separation means adding a new provider only requires implementing a new normalizer—the rest of the system remains unchanged. It's designed to scale with your needs.

Data Flow: From Request to Storage

Here's how a message flows through the system:

Step 1: Ingestion

Client sends message in native format (OpenAI, Anthropic, or Acontext's unified format)
Router extracts format parameter and routes to handler

Step 2: Normalization

Handler detects content type and parses request
Normalizer uses official provider SDK to validate and convert
Message is transformed to unified internal format

Step 3: Storage (Write Path)

Service layer handles file uploads and calculates SHA256 hashes
Content-addressed storage enables automatic deduplication
S3: Parts JSON and files uploaded to S3, organized by SHA256 hash
Redis: After successful S3 upload, parts data cached in Redis with fixed TTL
PostgreSQL: Message metadata (ID, session ID, role, timestamps, source format) and S3 asset reference stored
Reference counting ensures safe deletion when messages are removed

Step 4: Retrieval (Read Path with Caching)

System queries PostgreSQL for message metadata
For each message, first checks Redis cache using SHA256 hash from metadata
Cache hit: Parts returned instantly from Redis (sub-millisecond latency)
Cache miss: Parts loaded from S3, then cached in Redis for subsequent requests
This ensures hot data (recently accessed messages) is served with minimal latency

Format Comparison: Provider Differences

Each provider structures messages differently. Here's how they compare:

Example: Same Message, Different Formats

OpenAI Format:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "I'll check the weather for you."
    }
  ],
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"location\":\"San Francisco\"}"
      }
    }
  ]
}

Anthropic Format:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "I'll check the weather for you."
    },
    {
      "type": "tool_use",
      "id": "toolu_123",
      "name": "get_weather",
      "input": {
        "location": "San Francisco"
      }
    }
  ]
}

Acontext Unified Format:

{
  "role": "assistant",
  "parts": [
    {
      "type": "text",
      "text": "I'll check the weather for you."
    },
    {
      "type": "tool-call",
      "meta": {
        "name": "get_weather",
        "arguments": "{\"location\":\"San Francisco\"}",
        "id": "call_123"
      }
    }
  ],
  "meta": {
    "source_format": "openai"
  }
}

The unified format means downstream systems only need to understand one structure, while original format information is preserved for debugging and auditing.

Storage: Three-Tier Architecture (PostgreSQL + S3 + Redis)

Why Three-Tier Storage?

Storing everything in PostgreSQL leads to database bloat and slow queries. Storing everything in S3 makes querying complex and loses transactional guarantees. Reading from S3 on every request adds latency. Acontext uses PostgreSQL for metadata, S3 for durable storage, Redis for hot cache—the best of all worlds.

PostgreSQL stores:

Message identifiers (ID, session ID, parent ID)
Lightweight fields (role, timestamps, status)
S3 reference (asset metadata pointing to the parts JSON file)
Message-level metadata (source format, name, etc.)

S3 stores:

Message parts as JSON files (content-addressed by SHA256)
Uploaded files (images, documents, etc.)
Organized by project and date (format: parts/{project\_id}/{YYYY/MM/DD}/{sha256}.json) for efficient access
Serves as the source of truth for all message content

Redis caches:

Frequently accessed message parts (hot data)
Keyed by SHA256 hash for content-based caching
Fixed TTL strategy ensures automatic expiration and bounded memory usage
Dramatically reduces S3 read operations for active sessions

This three-tier architecture allows fast SQL queries on metadata, efficient storage for large payloads, and instant access to hot data. It's designed like a filesystem with intelligent caching for your agent's context data.

Content-Addressed Storage and Deduplication

When the same content is uploaded multiple times (e.g., the same image used in different messages), Acontext automatically deduplicates it:

Calculate SHA256 hash of the content
Check if an object with this hash already exists in S3
If found, return the existing object metadata
If not found, upload with a path like parts/{project\_id}/{YYYY/MM/DD}/{sha256}.json

This means identical content is stored only once, saving storage costs and improving cache efficiency. The SHA256-based addressing also enables efficient Redis caching—the same hash is used as the cache key, so identical content benefits from cache hits regardless of which message references it. It's automatic—you don't need to think about it.

Reference Counting for Safe Deletion

When a message is deleted, we can't immediately delete its S3 assets—other messages might reference the same content. Acontext uses reference counting:

Each asset has a ref\_count in the database
When a message references an asset, increment the count
When a message is deleted, decrement the count
Only delete from S3 when ref\_count reaches zero

This is handled atomically at the database level using PostgreSQL's row-level locking, eliminating race conditions without application-level synchronization. It's safe, automatic, and efficient.

Redis Hot Cache for Performance

To minimize latency when reading messages, Acontext uses Redis as a hot cache layer:

On Write (SendMessage):

After successfully uploading parts to S3, the parts data is cached in Redis
Cache key: message:parts:{sha256} (using SHA256 for content-based caching)
Uses a fixed TTL strategy: entries automatically expire after a set duration

On Read (GetMessages):

System first checks Redis cache using the SHA256 hash from message metadata
Cache hit: Parts returned instantly from Redis (sub-millisecond latency)
Cache miss: Parts loaded from S3, then cached in Redis for subsequent requests
This ensures recently accessed messages are served with minimal latency

Benefits:

Reduced S3 reads: Hot data (active sessions) rarely hits S3
Lower latency: Cache hits are orders of magnitude faster than S3 reads
Content-based caching: Same content (same SHA256) benefits from cache regardless of which message references it
Automatic cache management: Fixed TTL strategy ensures cache automatically expires stale entries without manual intervention or complex eviction policies
Predictable behavior: Simple, deterministic expiration makes cache behavior easy to reason about
Bounded memory: Cache size naturally self-regulates as entries expire, preventing unbounded growth

The cache is transparent—if Redis is unavailable, the system gracefully falls back to S3. This ensures reliability while maximizing performance for the common case.

Parsing: Multi-Format Normalization

Using Official SDKs for Validation

Rather than manually parsing JSON and hoping we got it right, Acontext uses official provider SDKs:

OpenAI: Uses openai-go↗ types
Anthropic: Uses anthropic-sdk-go↗ types

This ensures:

Type safety: Compile-time checking of message structure
Spec compliance: SDKs stay updated with provider changes
Error handling: SDKs handle edge cases we might miss

The normalizers act as thin adapters that use SDK types for parsing, then convert to the unified format. It's reliable, maintainable, and future-proof.

The Unified Internal Format

Acontext converts all formats to a unified structure:

{
  "role": "user",
  "parts": [
    {
      "type": "text",
      "text": "Hello"
    },
    {
      "type": "tool-call",
      "meta": {
        "name": "get_weather",
        "arguments": "{\"location\":\"SF\"}"
      }
    }
  ],
  "meta": {
    "source_format": "openai"
  }
}

This unified format means:

Downstream systems only need to understand one structure
Tool calls are handled uniformly regardless of source
Original format is preserved in metadata for debugging/auditing

Use Cases: Real-World Applications

Multi-Provider Agent Systems

You're building an agent that needs to work with both OpenAI and Anthropic, depending on the task. Without Acontext, you'd need separate storage systems, different query logic, and custom converters for each provider.

With Acontext:

from acontext import AcontextClient

client = AcontextClient(api_key="your-api-key")

# Send OpenAI format message
openai_message = {"role": "user", "content": "Hello"}
client.sessions.send_message(
    session_id=session_id,
    blob=openai_message,  # Native OpenAI format
    format="openai"
)

# Send Anthropic format message
anthropic_message = {"role": "user", "content": "Hello"}
client.sessions.send_message(
    session_id=session_id,
    blob=anthropic_message,  # Native Anthropic format
    format="anthropic"
)

# Query uniformly
messages = client.sessions.get_messages(session_id=session_id)
# All messages in unified format, regardless of source

Context Learning and Analysis

You want to analyze tool usage patterns across all your agent interactions, but messages are stored in different formats with inconsistent structures.

With Acontext:

All messages normalized to unified format
Tool calls queryable uniformly: WHERE parts->>'type' = 'tool-call'
Source format preserved for debugging: WHERE meta->>'source\_format' = 'openai'
Fast queries on metadata, efficient storage for payloads

Large Payload Handling

Your agent processes images, documents, and long-form content. Storing everything in PostgreSQL would bloat the database, but object storage makes querying difficult.

With Acontext:

Metadata in PostgreSQL for fast queries
Payloads in S3 for efficient storage
Redis cache for instant access to hot data
Automatic deduplication saves storage costs
Reference counting ensures safe deletion

Provider Migration

You're migrating from OpenAI to Anthropic, or need to support both during a transition period. Without normalization, you'd need separate code paths and risk data inconsistency.

With Acontext:

Send messages in either format to the same API
Unified storage means consistent queries
Source format tracked for auditing
No code changes needed for downstream systems

Built to Scale

Acontext's message processing is designed to grow with your needs:

Add new providers: Just implement a new normalizer
Handle large payloads: Hybrid storage scales automatically
Support new formats: The unified internal format remains stable
Maintain reliability: Official SDK validation ensures spec compliance

It's infrastructure that works, so you don't have to think about it.

Vision: Message Data as First-Class Infrastructure

Building a multi-format message processing system is about treating message data as first-class infrastructure. By providing a unified layer that normalizes, stores, and preserves context data, Acontext enables agents to work with consistent, observable, and learnable context.

This is what a Context Data Platform should do: make context data observable, persistent, and reusable, so you can focus on building agents that deliver real value.

You focus on building agents that solve real problems, not on babysitting message formats.

The system:

Accepts messages in any supported format (OpenAI, Anthropic, or Acontext's unified format)
Normalizes them to a unified internal representation
Stores them efficiently using hybrid storage
Preserves all necessary metadata

This enables Acontext to serve as a reliable foundation for context data management, allowing your agents to work with consistent, queryable, and learnable context data—the foundation for self-learning AI systems.

References

Inside Acontext: How AI Agents Learn from Experience

Acontext — Wed, 28 Jan 2026 17:11:00 +0000

Acontext transforms raw agent execution into structured tasks and reusable skills. Explore how Store → Observe → Learn → Act enables self-improving AI agents.

🧩 Acontext Architecture: From Context to Skill

The diagram below captures the entire process: how Acontext takes raw LLM messages, turns them into structured tasks, distills knowledge, and builds reusable skills.

Let's walk through it step by step.

context data → extract patterns → create & store skills → apply & refine → agent improves

Every message, tool call, artifact, and user feedback is captured as context. Patterns are extracted into reusable skills, applied to new tasks, and refined through feedback, enabling the agent to learn continuously from its own experience.

Acontext organizes and manages this data flow, turning raw context into structured, self-improving behavior.

1️⃣ Multi-Modal Context: Capturing the Raw Stream

On the left, we have everything that happens inside an agent run:

user requests, plans, tool calls, Memories, and feedback.

A typical workflow looks like this:

User: "Make me a landing page."
Agent: "Here's the plan → Initialize → Build → Deploy."
Agent calls tools (list_dir, find_file, etc.) and reports progress.
The user intervenes: "Wrong stack, use Next.js."
The agent continues, completes the task, or fails in the attempt.

All of these steps, including messages, tool traces, generated artifacts, and memory, are saved to Acontext through a unified storage API.

This is the Store phase. It captures every relevant context, so nothing gets lost between runs.

2️⃣ Extract Tasks and Feedback: Making Behavior Observable

The middle section represents Acontext's Observer layer. Once data is stored, this layer automatically extracts tasks and feedback from the raw message stream.

Each task is represented as a structured record containing:

Objective: what the agent was trying to achieve
Progress: key execution steps
User Preferences: hints or corrections from users
State: pending / success / failed
Feedback: what worked and what didn't

For example:

Task 1 — pending: located the source folder but didn't build.
Task 2 — success: built components; user prefers Next.js.
Task 3 — failed: deployment attempted but hit compile errors.

By organizing the execution trace into task-level records, Acontext gives you a clear, context-aware, and task-level view of what the agent promised, what it did, and why it succeeded or failed.

This isn't token-level observability. It's behavioral observability.

3️⃣ Distill & Learn: Turning Execution into Experience

This is where Acontext begins to learn on its own.

Step 1: Structured Data Extraction: Converting Executions into Training Signals

Whenever a task is marked as *successful,*either because the agent achieved the goal or the user explicitly confirmed it, Acontext's background learner retrieves the complete semantic trace related to that task, including:

The conversation segment that established the goal and constraints
The agent's reasoning or planning (when available)
Tool calls, parameters, outputs, and intermediate state
User corrections, preferences, and approvals
The final result and the success signal

The key principle: Only validated successes are selected as learning samples.

Each sample is stored as a structured execution record that includes the goal, the reasoning chain, the operational steps, context conditions, and evidence of correctness.

This is not log scraping; it is targeted data extraction for learning.

Step 2: Semantic Grouping to Identify Successful Patterns Across Runs

Next comes semantic clustering.Acontext automatically groups similar successful tasks by intent and outcome.

It looks for recurring execution patterns, then identifies consistent behavioral patterns and filters out noise or partial runs.

Typical examples include:

Repeated workflows for project initialization
Recurring patterns in 'collect → analyze → report' tasks
Consistent resolution strategies after user corrections
Multi-step tool-call chains that reliably lead to success

Clustering allows Acontext to:

Surface what consistently worked
Filter out partial executions, noise, or one-off behaviors
Identify the underlying structure of a successful process

The result: clusters of tasks that consistently led to success form the foundation for new skills.

Step 3: Compress Successful Behavior into Reusable Skills

From each stable cluster, Acontext synthesizes a Skill:a distilled blueprint describing how to accomplish a goal effectively. There are four core elements which are drawn directly from the execution data:

• Procedures - the actionable steps

The sequence of operations or tool calls that repeatedly produced the desired outcome.

• Patterns - general strategies

How the agent approached the problem:

e.g., "search → filter → summarize," or "update plan after user correction."

• Context - when the skill applies

The input conditions or environment under which the procedure is valid.

e.g., "This workflow is more efficient when the user favors Next.js."

• Preferences - user's implicit rules

Individual user preferences extracted from interactions, such as:

"Always report before executing," or "Use pnpm instead of npm."

Acontext transforms these elements into a structured Skill object, which is ready to be stored and retrieved.

Skill Space: Organize, Retrieve, Reuse

On the right of Architecture Diagram, these learned skills are saved in a Notion-style workspace.

Each Skill Space acts as a dynamic, structured memory layer for your agents, organized by domain or capability, such as:

frontend_preferences
github_operations
linkedin_operations

Skill Space is dynamic and continuously maintained by Acontext, forms a living library of what consistently works, tailored to each individual user or agent.

Skills are automatically created from new successful runs

Overlapping skills are merged
Stale or redundant skills are pruned

Skill Retrieval

When a new task arrives, Acontext searches the Skill Space to surface relevant past experience.

It supports two modes:

Semantic Search：quickly find skills that match the task's intent
Agentic Search：combine multiple skills when the task is more complex

Retrieved skills are provided back to the agent as context or guidance, allowing it to start with learned experience instead of a blank slate.

4️⃣ Act Smarter and Start the Next Loop

At the bottom, the arrow labeled "Improve the Agent next time" represents Acontext's continuous learning loop.

With learned skills in place, the agent begins each new run with:

better defaults
clearer workflows
personalized preferences
fewer mistakes

In short:

Act = the agent behaving smarter because it has learned.

And once the run finishes, its execution trace flows back into the same loop:

Store → Observe → Learn → Act → …

This continuous cycle empowers a self-improving agent: each action generates new data, each success becomes new skillset, and every skill enables better actions in the next iteration.

The Data Model in Acontext

Under the hood, Acontext operates on those object types:

Object

Description

Session

A conversation thread that stores all messages with multi-modal support (message, tool calls, artifacts). Acontext automatically tracks what tasks the agent plans and executes.

Trace

The granular execution timeline within a session: every plan, tool call, state transition, and response captured in sequence.

Task

A step of the agent’s plan, extracted automatically from conversation. Tasks transition through: pending → running → success/failed. Represents intent, progress, and outcome.

Disk

File storage for agent-generated artifacts (e.g., code, images, documents). Used to preserve outputs that tasks produce.

Space

A knowledge repository (like a Notion workspace) where learned skills are stored. Connecting sessions to a Space enables automatic skill learning from completed tasks.

Skill Block

A learned SOP (Standard Operating Procedure) derived from complex tasks. Includes use_when conditions, user preferences, and tool_sops patterns. Only sufficiently complex and validated tasks become skills.

Skill / Skill Space

A distilled, reusable representation of successful behavior. Skills inside a Skill Space are searchable, versioned, and continuously refined. Each skill contains: • Procedures: the step-by-step approach that worked • Patterns: recurring strategies or action flows • Context: where the skill applies • Preferences:user-specific requirements or constraints

Experience Agents

Background AIs that automatically extract tasks, group patterns, and synthesize Skill Blocks. They run continuously and require no direct interaction.

This model turns context from "raw logs" into structured experience datathat's both searchable and reusable.

⚙️ Key Design Principles

Unified Context Storage: Handle messages, sessions, plans, and artifacts through one API.
Task-Level Observability: Focus on what the agent did, not just how long it took.
Automatic Experience Learning: Experience extraction runs continuously in the background.
Personalized Skill Library: Each end user accumulates their own adaptive skill set.
Framework-Agnostic: Works with OpenAI, Anthropic, LangChain, and more.

🌍 Join the Community

Acontext is open source, and we need your feedback to help it grow.

💻 GitHub: github.com/memodb-io/Acontext↗ If you find it useful, give it a ⭐️ , it will help others discover it.
💬 Discord: Join the Acontext Community ↗Share integrations, feedback, or ideas for what to build next.

Why Self-Learning Agent Needs More Than Memory

Acontext — Tue, 27 Jan 2026 17:37:00 +0000

Why Memory layer like Mem0 and Zep can recall conversations but cannot help agents improve, and how Acontext enables true self-learning through workflows and tool usage.

When developers see Acontext learning from past interactions, the first reaction is often:

"Isn't this just another memory layer? Why not use Mem0, Zep, orMemobase↗for this?"

This is a common misunderstanding.

Memory and self-learning are not the same thing.

And this difference is exactly why traditional memory systems can't make agents improve.

Memory Layers Remember 'What was Said', Not 'How Work was Done'

Tools like Mem0, Zep, and Memobase were designed with a specific purpose: to help an agent recall information from past conversations.

Each takes a slightly different approach: gist extraction, graph structures, and user profile modeling, but they all optimize for the same capability - remembering facts and preferences.

However, every useful agent relies on tools. Booking flights, running SQL, browsing the web, these are tool workflows, not dialogue.

If a system can't observe the thing the agent actually did, it can't learn from it.

This is the fundamental limitation of every memory solution today.

Self-Learning Requires Remembering Workflows, Not Sentences

If you ask a human to clean a database, they don't just store one or two lines in memory. They remember the procedure: the steps, the order, the tools, the checks, the edge cases. Over time, that procedure becomes refined into a predictable workflow.

We call that an SOP (Standard Operating Procedure).

It requires structure, context, execution history, and most importantly, awareness of the task itself.

A self-learning agent must be able to review a full trail of actions, reflect on what happened, understand the user's corrections, and preserve the successful workflow for future use. Traditional memory systems cannot even represent this information, let alone learn from it.

For agents, the most critical kind of memory is how to reach a goal using the available tools and the user's preferences. This requires memory that understands tool usage directly, but no existing memory system does this. They only store conversations, not the tools that actually complete the work.

Acontext Learns From Tasks, Not Text

Acontext treats an entire task: its objective, steps, corrections, and final success, as the unit of learning.

Instead of saving fragments of text, it distills workflows into structured blocks that say:

when a workflow should be reused
what user preferences shaped it
which tools were combined and how

This is why Acontext can update workflows when tools change, andwhy only confirmed successful executions become learnable skills↗.

{
    "use_when": "star a repo on github.com",
    "preferences": "use personal account. star but not fork",
    "tool_sops": [
        {
            "tool_name": "goto",
            "action": "goto github.com"
        },
        {
            "tool_name": "click",
            "action": "find login button if any. login first"
        },
        {
            "...": "..."
        }
    ]
}

Acontext makes this very clear. It knows which task a piece of experience belongs to, what tools or procedures the user preferred during that task, and how the agent used its tools to get the job done.

We also know developers change their tools over time, so Acontext includes APIs that update all related SOPs in one go: https://docs.acontext.io/learn/tool.

If you want an agent that truly gets better at doing work, today's memory systems will not get you there. Acontext is built specifically for that purpose. (And yes, we learned this the hard way when building Memobase.)

The Difference at a Glance


Dimension	Memory	Acontext
Position	Memory layer	Context as experience layer
Storage	User facts, preferences, conversation history	Sessions, tool calls, tasks, SOP skills
Memory unit	Semantic facts	SOP block (use_when, preferences, tool_sops)
How it's used	Added to prompts for personalization	Guides planning & execution directly
Applied Scenarios	Chatbots, customer support agents	Tool-using agents, workflows, automation
Main value	Better continuity and user recall	Higher task success rates & fewer running steps
Not designed for	Experience learning	Long-term user memory

If you have questions or want to discuss Acontext with the team and agent developers, feel free to join ourDiscord↗ or leave a message onX↗.

Acontext: Where Context Data Becomes the Foundation for Agent Learning

Acontext — Thu, 18 Dec 2025 03:24:25 +0000

Every AI agent developer has felt the same pain: your agent works beautifully in one run, and fails mysteriously in the next.

It doesn't remember what worked before.
It can't explain why it failed.
And even when it succeeds, you can't capture why.

We built Acontext to change that. It started with a simple question:
“What if an agent could observe, remember, and learn from every interaction it has, just like a human learning skills from its own past?”

Acontext's mission is to give agent developers the missing foundation for self-evolving agents: a context data platform that makes agents' execution observable, reusable, and learnable.

Why Do We Need Something like Acontext?

Today, an agent's context is scattered across memory stores, RAG pipelines, logs, and user feedback.
The result? Fragmented, transient, and nearly impossible to analyze over time.

This creates critical challenges for agent developers:

Integration Overhead and Local-to-Cloud Complexity: Agent developers spend excessive time merging data to maintain a consistent state. Local setups work fine, but when you move to production, your memory, files, and context systems don't scale seamlessly.
Complexity in Context Engineering: Reduction, compression, offloading, and "Claude Skills"-style capability building often become ad-hoc, brittle layers scattered across your stack.
Agent Stability: Getting an agent to work once is easy. Maintaining reliability over time is challenging. Developers struggle to track what the agent promised, whether users were satisfied, and why performance drifts.
Limited Experience Learning: Agents today don't learn from their successes effectively. "Memory" solutions only store text summaries, but true experience learning requires capturing the full task context: actions, tool calls, and solid SOPs, etc.

All these challenges stem from one root cause: context data is not treated as a first-class infrastructure.

We don't need another framework or database; we need a unified layer that makes context observable, persistent, and reusable.
That's what Acontext does.

What Acontext Brings to Your Agent Stack
Acontext is a context data platform that gives your AI agents context management, observability, and experience learning. Here's how it works:

Multi-Modal Context Storage Acontext acts as your storage backend, offering a simple API for unified storage and persistent management of multimodal conversation data.

It is designed like a filesystem for agents' artifact storage, enabling easy context offloading and cross-task collaboration, especially ideal for scenarios where a sandbox environment is not required.

Real-Time Context Observability Acontext provides a built-in dashboard, giving you a clear view of your agent's execution process:
Track all context sessions, monitor each task's objectives, execution process, and success or failure status.

Unlike LangSmith or Langfuse, which focus on latency or token usage, Acontext focuses on real-time, context-aware, task-level tracking. Every dynamic aspect of agent running is evident and actionable.

Memory Layer for Experience Learning Acontext is the memory layer your AI agent actually needs. It captures what your agent does well and turns those wins into reusable skills: Organized Workspace: Each agent has its own Notion-like workspace where skills are automatically organized and managed. Personalized Skill Library: Imagine you have 100,000 users, each with their own autonomous "Claude Skills" that collect past successful complex tasks. Every time your agent exceeds expectations and achieves a breakthrough, that success is captured and stored in Acontext. This means your agent's success rate is no longer a random occurrence, and the experience-based learning continues to grow and improve.

Customized Control: Use the full CRUD API to add custom experiences or manage workspace content manually, whenever you need.
Flexible and Precise Skill Retrieval: Acontext offers two search modes for quickly retrieving the skills and experiences you need:

Semantic Search: Fast and accurate retrieval of relevant skills.
Agentic Search: A progressive, multi-step skill organization and retrieval system, suitable for both auto-learned and manually customized content.

Built to Collaborate, not Compete

Acontext doesn't replace existing frameworks, databases, or observability tools. It's here to work alongside them, providing your agents with a shared layer where all their context data lives and evolves.

Acontext vs. Frameworks
Acontext is not an agent framework. Think of it as the place where your agent's data lives. Use OpenAI, Anthropic, LangChain, or any other stack. Acontext simply ensures agents' messages and artifacts are stored and reusable.

Acontext vs. Databases
Acontext is not a new type of database either. It builds on Postgres, S3, Redis, and other stack to store all the data your agent needs — text, code, PDFs, or images — in one place.

Acontext vs. Observability Tools
Acontext doesn't replace existing AI observability tools, but it reveals what they can't. Traditional tools can show errors, latency, and token usage, but they can't tell you whether your agent actually satisfied the user.
Acontext tracks the full context: capturing what really happened, whether it worked, and why.

What Acontext Means for Agent Developers

Imagine having a Supabase-like data platform, but purpose-built for AI agents.
That's what we want to create with Acontext.
Instead of juggling storage, logging, and context engineering, you get a clean API that tailors to your needs. No more wiring multiple systems, no more tedious bits.
You are the person to build agents to solve real problems, not to babysit context loops.
Let Acontext handle the memory, context, and skill learning underneath. You focus on delivering real value.

How to Use Acontext

Acontext is still in its early stage, and what you see today is just the first version of what it will become.
Currently, Acontext supports storing agents' context data using Postgres and S3, offers an intuitive local dashboard, and delivers one of the most effective agent self-learning experiences available today.
But there's much more on the roadmap, and we'd love for you to try Acontext in your POC and help shape what comes next.
So, how to get started?

Open-Source Release
We're currently in open-source mode, moving fast and gathering feedback from the community. Download our acontext-cli for a quick test drive:
curl -fsSL https://install.acontext.io | sh
With acontext docker up, you can quickly launch an Acontext instance on your local machine.
We provide Python and TypeScript SDKs, so you can easily push data in.
Acontext also supports storing OpenAI and Anthropic message formats directly.
You can explore a few examples to get a feel for how to use Acontext:
acontext create
If you'd like to look through more examples first, check out our example repo.

Join the Journey

We're building the Context Data Platform for AI agents together, through open source.
This is a new territory. No one exactly knows what a Context Data Platform should look like yet. But that's what makes it exciting: we get to figure it out together with the developers who are building the next generation of AI Agents.
Here's how you can get involved:

Join our Discord Community to connect with other builders
Try Acontext locally and share what you learn
Open issues, submit PRs, or tell us what's working (and what's not)
GitHub: http://github.com/memodb-io/Acontext We're at the beginning of something big: building a Data Platform for AI Agents. Let's build it together!

Forem: Acontext

The Missing Infrastructure for AI Agents: Unified Context

The Gap Between Tools and True Agents

Workflow Builders vs Agent Builders

The Heart of It All: Context Engineering

In-Session Context

External Context

Cross-Session Context

Why the Agent Era Needs a Context Data Platform

What Lives Inside Context Data?

Multi-Modal Messages

Artifacts

Plan & Task Observability

How to Improve Agents' Success Rates?

For the Visionaries Building What Comes Next

Native Per-User Resource Management for Multi-Tenant AI Apps

What's New

How It Works

Associate Resources with Users

Filter Resources by User

Cascade Delete Users

Use Cases

How to Handle Growing AI Context Without Endless Scripts

Why does context engineering become the real bottleneck?

A Simpler Pattern: Context Data as a Unified Layer

Acontext Simplifies Context Engineering in Two APIs

Code in Action: Context Editing On-the-fly

Why a Context Data Platform Matters for Production Agents

The Way Forward

Self-Learning Agents: From Prompt Evolving to Experience Learning

Acontext: User-level Experience Learning

Try Acontext

How Acontext Stores AI Messages?

The Problem: Format Fragmentation

The Solution: Unified Message Processing

Multi-Format Support

Complete Context Preservation

Efficient Hybrid Storage

Provider Flexibility

Architecture: Layered Design

Data Flow: From Request to Storage

Format Comparison: Provider Differences

Example: Same Message, Different Formats

Storage: Three-Tier Architecture (PostgreSQL + S3 + Redis)

Why Three-Tier Storage?

Content-Addressed Storage and Deduplication

Reference Counting for Safe Deletion

Redis Hot Cache for Performance

Parsing: Multi-Format Normalization

Using Official SDKs for Validation

The Unified Internal Format

Use Cases: Real-World Applications

Multi-Provider Agent Systems

Context Learning and Analysis

Large Payload Handling

Provider Migration

Built to Scale

Vision: Message Data as First-Class Infrastructure

References

Inside Acontext: How AI Agents Learn from Experience

🧩 Acontext Architecture: From Context to Skill

1️⃣ Multi-Modal Context: Capturing the Raw Stream

2️⃣ Extract Tasks and Feedback: Making Behavior Observable

3️⃣ Distill & Learn: Turning Execution into Experience

Step 1: Structured Data Extraction: Converting Executions into Training Signals

Step 2: Semantic Grouping to Identify Successful Patterns Across Runs

Step 3: Compress Successful Behavior into Reusable Skills

Skill Space: Organize, Retrieve, Reuse

Skill Retrieval

4️⃣ Act Smarter and Start the Next Loop

The Data Model in Acontext

⚙️ Key Design Principles

🌍 Join the Community

Further reading

Why Self-Learning Agent Needs More Than Memory

Memory Layers Remember 'What was Said', Not 'How Work was Done'

Self-Learning Requires Remembering Workflows, Not Sentences

Acontext Learns From Tasks, Not Text

The Difference at a Glance

Further reading