Agents Universe
Open-source enterprise AI agent platform where agents onboard, work and accumulate experience like people, sharing project context across the whole team.
- Source repo
- agents-universe/agents-universe
- Stars
- ★ 825
- Last updated
- 1d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 68/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API · Claude API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A software team chats requirements into story cards with the Product Owner, has @Tech Lead deliver code and open PRs, and lets QA run Playwright regressions
- Not a fit if
- Teams that need a Slack/IM chatbot integration — the platform offers none
- Teams that require vector-embedding retrieval — this project deliberately loads full context without embeddings
- Source review
- 68/100 · Some gaps
What does this agent do, and when should you use it?
Agents Universe is an open-source (Apache-2.0) enterprise AI Agent platform built on Python 3.12 + FastAPI with a Codex-style three-pane Vue 3 UI, deployable in one command via Docker Compose or tried at agents-universe.com. It ships 10 ready-to-use agents; Product Owner, Tech Lead and QA form a complete requirements → implementation → verification pipeline that plugs into Jira and GitHub (including Enterprise) for story cards, coding, testing and PRs. Unlike a chatbot, agents act with a personal identity and least privilege: plan_task first, execute commands and code inside a dual-layer sandbox, with everything visible and auditable over WebSocket. The knowledge system uses no vector retrieval — selecting a project fully loads knowledge files, and agents continuously write lessons back via the knowledge_rw tool, turning experience into shareable skills, workflows and knowledge assets. It unifies Anthropic / OpenAI / Azure OpenAI / Gemini behind user-configured keys (AES-256-GCM encrypted) and offers Agent-as-a-Service publishing plus cron scheduled tasks.
On project selection, knowledge/loader fully loads primary knowledge files (no vector search); detail files are loaded and released on demand via knowledge_rw. The plan_task tool decomposes work into a task tree stored in agent_tasks, streaming thinking and tool calls over WebSocket. Tech Lead turns a single Jira card into clone repo → read code → implement → run tests → commit → create PR, with dirty worktree, non-fast-forward main and failing tests as hard gates; QA generates Playwright scripts (tests/generated/) that can run on daily cron regressions at zero token cost. The Office Assistant produces PPT/Excel/Word/reveal.js web decks/ZIP deliverables; the Penetration Tester runs whitelisted sqlmap/semgrep/bandit audits on authorized projects and emits PTES-structured reports. Every command and code snippet runs in a dual-layer sandbox (command whitelist + CPython audit-hook file guard), with secrets injected via env_refs so plaintext never enters LLM context.
- A software team chats requirements into story cards with the Product Owner, has @Tech Lead deliver code and open PRs, and lets QA run Playwright regressions
- A data analyst asks the Data Analysis expert to align metric definitions against project knowledge, explain anomalies and produce chart dashboards
- Operations staff use the Office Assistant to turn project knowledge into PPTs, Excel checklists or web demos where every number is traceable
- A security team runs authorized white-box penetration testing with PTES reports and remediation advice
- A support team deploys the Customer Service agent that answers strictly from project knowledge with human handoff
- Non-coders contribute PRs to this very project by chatting requirements with the Product Owner and @Tech Lead
How do you install or deploy this agent?
One-command Docker self-hosting (requires Docker & Docker Compose):
cp .env.example .env
cp docker-compose.example.yml docker-compose.yml
echo "SECRET_KEY=$(openssl rand -hex 32)" >> .env
docker compose up --buildThe web UI / API serves at http://localhost:8000 (health check /health). No LLM API Key is needed in .env; configure models per user after startup in Settings → AI Models (encrypted with AES-256-GCM). AUTH_BYPASS_ENABLED=true gives login-free local use only — disable it and configure OAuth SSO in production. First build includes Playwright and the pentest toolchain (10-30 min); if mirrors are unreachable, build against official sources:
docker compose build \
--build-arg NPM_REGISTRY=https://registry.npmjs.org \
--build-arg PIP_INDEX_URL=https://pypi.org/simple \
--build-arg APT_MIRROR_HOST=deb.debian.org \
--build-arg NODE_BASE_URL=https://nodejs.org/dist \
--build-arg PLAYWRIGHT_DOWNLOAD_HOST=https://cdn.playwright.dev
docker compose upLocal development needs Node.js 20+ and Python 3.12+. Start dependencies first:
docker compose up -d sqlserver redis
cd packages/api
python -m venv .venv
source .venv/bin/activate
pip install -e ../agent-core -e .
PYTHONPATH=src python -m uvicorn api.main:app --port 8000 --reload
cd ../web && npm install && npm run devDatabases: SQL Server (default) / PostgreSQL / MySQL / SQLite, switched via DATABASE_URL; run migrations with alembic upgrade head.
How do you use this agent?
- Open http://localhost:8000 or agents-universe.com and sign up; 2. In Settings → AI Models add your own LLM API key (Anthropic / OpenAI / Azure OpenAI / Gemini) and add your Git Token (custom GitHub Enterprise endpoints supported); 3. Create a project and pick a category (software / legacy modernization / data analysis / customer service / document knowledge base) to auto-initialize a domain knowledge skeleton; 4. Feed the agent Confluence pages, Swagger docs, PRDs to complete its 'onboarding'; 5. Discuss requirements with the Product Owner, then @Tech Lead to implement, @Quality Assurance to verify, @Office Assistant to produce deliverables; 6. Schedule scripts, Playwright tests or agent prompts on cron from the Scheduled Tasks tab. API usage example:
curl -N -X POST "$BASE/api/p/{publish_id}/stream" \
-H "Authorization: Bearer $PUBLISH_KEY" \
-H "Content-Type: application/json" \
-d '{"message": "Hello", "thread_id": "any-caller-thread-id"}'What are this agent's strengths and limitations?
- Agents execute with personal identity, least privilege and an auditable trail: all commands and code run in a dual-layer sandbox (command whitelist + CPython audit hook), secrets are AES-256-GCM encrypted and never enter LLM context
- Knowledge uses full-context loading with explicit [[slug]] cross-references instead of vector search, and experience becomes copyable, open-source-able skill/workflow/knowledge files
- Ten built-in roles form a PO → Tech Lead → QA pipeline wired to Jira and GitHub (incl. Enterprise) for a card-to-PR loop; QA's scheduled Playwright regressions run at zero token cost
- Agent-as-a-Service publishes any agent as an SSE streaming API or embedded page, with keys stored only as SHA-256 hashes
- Self-hosting is heavyweight: the Docker build bundles Playwright and the pentest toolchain (10-30 min first build) and needs SQL Server/Redis plus database migrations
- No embeddings means full-context loading may hit token budgets on very large knowledge bases; detail files are listed for on-demand reading only
- Documented sandbox boundaries exist: os.stat/os.access emit no audit events, Node.js has no runtime hook, and non-Python subprocesses of guarded Python escape the file guard outside strict mode
- No Slack/IM bot integrations — usage is through the web UI or your own published API endpoints
How does this agent compare with similar options?
Per its README: developer frameworks (Claude Code, VS Code AI) have a high ceiling but a steep barrier, with context locked in personal sessions; low-code platforms (Dify) are easy but reduce autonomous planning and execution to config nodes, lacking personal identity, least privilege and auditable trails. Agents Universe differentiates by sharing project context across the team, executing auditable sandboxed tasks as a person would, and turning experience into organizational assets.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Agents Universe This agent | 68 · Some gaps | Self-hosted serviceFree + model costs | ★ 825 | 1d ago | Python | OpenAI API · Claude API |
| Jumping Agent — Gamified Agent Builder | 43 · Major gaps | Web appFree + model costs | ★ 767 | 1mo ago | TypeScript | OpenAI API |
| DevAll | 41 · Major gaps | CLIFree + model costs | ★ 35k | 6d ago | Python | — |
| Warren | 76 · Good | Self-hosted serviceFree + model costs | ★ 513 | 19d ago | TypeScript | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README and SECURITY.md describe least privilege (per-user identity execution, project isolation), a user_confirm authorization flow (pentest requires scope confirmation before acting), AES-256-GCM key encryption, a two-layer sandbox, and command whitelisting. Deductions: the evidence set contains only README/test scaffolding — the actual sandbox and crypto source files are absent, so most security claims cannot be verified at source level; dependency_security is weak (pip-audit is mentioned but no lockfile/dependency manifest is in evidence, and default builds use in-country mirrors); rollback covers only knowledge-entry versioning (knowledge_versions), with no deployment/execution rollback story.
Internally consistent documentation: DB precedence, model fallback chains, and registry-mirror fallbacks are clearly specified; error-message design is concrete ([agent-guard] prefix, readable errors in non-interactive mode, 429/409 semantics). Deduction: all assertions are documentary; CI exists but pass status cannot be confirmed in a static review.
Strong audience/scenario coverage: 10 built-in roles, five project-category knowledge templates, dual paths for developers and non-coders. Deductions: capability boundaries are disclosed only for the sandbox; failure modes of the agents themselves (e.g., context overflow from full-load knowledge on very large projects) are under-addressed; trigger precision (@mentions, user_confirm) is described plausibly but without source corroboration.
Excellent information architecture (TOC, monorepo tree, anchors) and thorough install notes (PowerShell variants, SECRET_KEY generation, mirror fallback). known_limitations honestly lists three known sandbox gaps. Deductions: no CHANGELOG or version scheme (versioning_changelog=1); naming stability and examples/FAQ rest on the README alone; maintenance is claimed to be run by the project's own agents — novel but from an unverified publisher, with updates relying on GitHub private vulnerability reporting.
Output usability has concrete mechanisms (JWT-authorized media endpoint, SSE event frames, Excel formula verification) and the marginal-value claim (experience as shareable assets, token-free scheduled regression) is clear. Deductions: all effectiveness claims ('every number traceable', 'never fabricates') are unverifiable without execution; cost/benefit items (10–30 min builds, concurrency slots) are self-reported.
Moderate claim traceability: the README anchors many claims to code paths (sandbox.py, token_vault.py), but those implementation files are missing from the evidence; the CI workflow and SECURITY.md corroborate parts (job structure, test layering match the README's testing section). fact_inference_separation is acceptable — known boundaries and 'defense in depth, not absolute isolation' wording distinguish fact from inference — but the evidence surface is too thin for high confidence.
- This is a low-confidence static review: the implementation source for the sandbox, encryption, and user_confirm mechanisms is not present in the evidence, so those security claims are unverified at code level — do not treat them as validated.
- AUTH_BYPASS_ENABLED=true is the permissive out-of-box default; production deployments must disable it and enable SSO, otherwise you expose a platform that can execute commands, write files, and push code.
- The pentest agent ships offensive tooling (sqlmap, dirsearch, etc.); even with the authorization flow, deploy only in legally authorized, isolated environments.
- No CHANGELOG or versioning convention exists, making upgrade impact assessment difficult; missing dependency-lock evidence implies build reproducibility risk.
- Claims that the repository is maintained by its own agents with zero-code contribution are aggressive self-descriptions; contribution quality and review processes should be independently verified.