Skip to main content
AIDiveForge AIDiveForge
Visit Auto Learning Agents

Get This Tool

License: License: unverified
Local-run terms: Run locally with Docker using own API keys or local models; all data stays in local database.

Share This Tool

Compare This Tool
📋 Embed this tool on your site

Copy this code to embed a compact tool card:

Auto Learning Agents

FreeOpen SourceSelf-HostedAgentic

Pricing

Model
Free

Summary

Most self-hosted agent platforms give you uptime or memory — not both, and rarely learning that compounds across runs. Auto Learning Agents is an open-source platform built on Elixir/OTP that stores every conversation turn, tracks outcomes, and retrains on your own data on a schedule you control.

The platform runs anywhere Docker runs: clone, add keys, and agents come online with their own schedules, models, and instructions. Every turn is embedded and topic-classified; agents query that shared memory bank before acting, so behavior improves with use rather than resetting on each session. Approval queues guard any outward-facing work — you review before it ships — and a single toggle pauses all autonomous activity. The Elixir/OTP supervision tree handles restarts without manual intervention, which matters when you need agents running overnight without babysitting. The extension story is custom nodes and tools in code, so teams that need behavior the built-in config cannot express will be writing Elixir or wrapping external services.

Bottom line: The right pick for a team that needs persistent, self-improving agents running on their own infrastructure with full data control — and a harder fit when your organization has no appetite for owning the operational surface of a distributed Elixir system.

Community Performance Report Card

No community ratings yet. Be the first to rate this tool!

Best For: Users wanting full data control and self-hosting, Teams building agents that improve over time via memory, Developers extending with custom nodes and tools, Scenarios requiring fault-tolerant always-on operation

Community Benchmarks Community

No community benchmarks yet. Be the first to share a real-world data point.

  • Persistent, embedded memory across every conversation turn, so agents accumulate context about your domain rather than starting cold on each session — which eliminates the class of failures where an agent gives contradictory answers because it cannot recall what it said last week.
  • Outcome-based learning with scheduled local fine-tuning, so the model improves on your specific data without sending that data to a third-party trainer — directly addressing the compliance blocker that rules out SaaS agent platforms for regulated industries.
  • Built on Elixir/OTP's supervision tree, so agent processes restart automatically without operator intervention — which means overnight pipelines and always-on support agents do not require someone on call to restart a crashed Python worker.
  • Provider-agnostic model configuration covering cloud APIs and local Ollama, so switching away from a cloud provider when costs spike or a model is deprecated is a config-file change rather than a code rewrite.
  • Approval queues on outward-facing actions and a single global pause toggle, so you stay in the loop on anything consequential without having to disable agents individually when something goes wrong.
  • Custom nodes and tools require writing in Elixir — the same language as the supervision tree. Teams whose engineers work exclusively in Python or TypeScript face a steep ramp to extend behavior beyond what the built-in config expresses, and in practice those teams add a separate microservice layer, which means maintaining two systems.
  • The learning loop — outcome tracking, reward shaping, weekly fine-tuning — requires a running instance accumulating real traffic before it produces measurable improvement. Teams evaluating the platform on a short pilot window will not see the compounding benefit the architecture is built around, and may conclude the memory layer adds complexity without payoff.
  • There is no managed hosting option described on the page. Teams without the infrastructure capacity to own a persistent Docker deployment — patching, storage growth from the embedded memory database, model retraining compute — will hit an operational ceiling that pushes them toward a SaaS agent platform even if the data-control story is attractive.

Community Reviews

No reviews yet. Be the first to share your experience.

About

Platforms
Docker, self-hosted
API Available
No
Self-Hosted
Yes
Last Updated
2026-07-04T22:22:21.208Z

Best For

Who it's for

  • Users wanting full data control and self-hosting
  • Teams building agents that improve over time via memory
  • Developers extending with custom nodes and tools
  • Scenarios requiring fault-tolerant always-on operation

What it does well

  • Customer support automation
  • Marketing and social media outreach
  • Web scraping and research
  • Coding and content creation workflows
  • Voice agent and multi-agent coordination

Integrations

ClaudeGPTOllama

Discussion Community

No discussion yet. Sign in to start the conversation.

Compare Auto Learning Agents

Spotted incorrect or missing data? Join our community of contributors.

Sign Up to Contribute

Community Notes & Tips Community

Be the first to contribute. General notes, observations, gotchas, and tips from people who use this tool day-to-day.

Frequently Asked Questions

Is Auto Learning Agents free?
Yes — Auto Learning Agents is fully free to use. There is no paid tier.
Is Auto Learning Agents open source?
Yes. Auto Learning Agents is open source.
Can I self-host Auto Learning Agents?
Yes. Auto Learning Agents supports self-hosting on your own infrastructure.
What platforms does Auto Learning Agents support?
Auto Learning Agents is available on: Docker, self-hosted.

Hours Saved & ROI Stories Community

Be the first to contribute. Concrete time/cost savings, with context. e.g. "Cut my code review backlog from 4h to 45m per week."

Auto Learning Agents

Most agent platforms treat each run as stateless: day one and day one hundred look identical because nothing carries forward. Auto Learning Agents breaks that pattern by storing every conversation turn, embedding and classifying it, and giving agents a shared memory bank they consult before acting. The core workflow is a Docker Compose stack: clone the repo, drop in your API keys or point it at a local Ollama instance, and configure agents from a single settings file — each with its own schedule, model, and instructions. Approval queues sit in front of any outward-facing action, and one click pauses all autonomous behavior at once.

The differentiating feature is the learning layer. The docs describe a cycle where results are tracked, successful patterns become rewards, and a local model can be fine-tuned on accumulated data on a weekly schedule. That means an agent handling customer support tickets gets measurably better at your specific ticket vocabulary over time — not because the vendor updated a shared model, but because your instance trained on your outcomes. This is the architecture that justifies self-hosting: the data stays in a single local database, and the improvement compounds privately.

The platform is built on Elixir/OTP, and the docs explicitly reference a supervision tree and coordinated agent nodes designed for fault-tolerant uptime. Agents restart without manual intervention. That architectural choice pays off for always-on use cases — voice agents, overnight research pipelines, scheduled social outreach — where a Python-based stack would surface process crashes as silent failures. The tradeoff is that extending the platform with custom nodes or tools means working in that same Elixir codebase, which raises the onboarding bar for teams whose engineers live in Python or TypeScript.

The vendor states support for Claude, GPT, and local Ollama models configured from a single settings file. The docs cover browser automation, RAG, MCP integration, multi-agent coordination, and observability — each as a named section, suggesting distinct configuration surfaces rather than a single unified UI. Teams evaluating this should expect to read documentation before deploying non-trivial workflows.