FAROS AutoResearch Runtime
Blueprint-driven AutoResearch runtime that orchestrates AI research from idea to experiment, paper, and review.
Evidence shows: package trust validation (TRUST.json, signature, integrity), rollback mechanism (backup/rollback), and external effect control (sandbox, execution backend). Deductions: least privilege not explicitly addressed, user confirmation unclear, data flow transparency limited, sensitive data handling not detailed, dependency security not audited, external effects not fully assessed, source attribution partial (publisher unverified).
Evidence shows: tests cover agent loop, failure classification, command discovery, repair service, good self-consistency. Deductions: dependency availability unverified (e.g., LLM provider), failure messages partial.
Evidence shows: targeted at LLM research scenarios, with blueprints, capabilities, profiles, multiple providers. Deductions: trigger precision (e.g., command discovery) limited, environment fit not fully tested.
Evidence shows: README, developer guide, TODO, install notes, examples. Deductions: license missing, versioning/changelog unclear, maintenance responsibility unclear.
Evidence shows: output artifacts (paper, code, review) usable, high marginal value (automated research workflow). Deductions: cost-benefit not assessed (e.g., LLM costs).
Evidence shows: tests and verification rules, but claim traceability limited, cross-source corroboration insufficient, fact-inference separation unclear.
- Publisher identity unverified, handle with caution.
- License missing, confirm legal terms before use.
- Dependency security not audited, especially LLM providers.
- Sensitive data handling details insufficient, check configuration.
- Cost-benefit not assessed, LLM calls may incur high costs.
What does this agent do, and when should you use it?
FAROS is a research workflow runtime for the LLM domain, built on four abstractions: Blueprints, Capabilities, Profiles, and Providers. It treats research automation as a runtime problem rather than a single-agent prompt stack. The current release candidate (1.1.0-rc1) ships the first runnable baseline, FAROS-LLM, implementing the complete 'idea -> experiment -> paper -> review' loop. The backend is Python (FastAPI) and provides a REST API for run management, blueprint/profile loading, and file-backed persistence for events, artifacts, and memory. The first blueprint, ml_paper, includes four capabilities: idea_refinement, experiment, paper_drafting, and reviewer_simulation. Paper generation supports venue-aware LaTeX templates (ICML, NeurIPS, ICLR, ACL, generic) with a fallback to simplified PDF rendering if LaTeX compilation fails. The frontend is Node.js, but the backend API is sufficient for standalone use. The project explicitly states what is not yet included: full DAG scheduling, parallel orchestration, real experiment execution, and a dedicated frontend console.
FAROS runtime loads blueprints and profiles, registers capabilities and providers, orchestrates execution, and persists run events and artifacts. A run is created via POST /api/faros/runs with a blueprintId (e.g., ml_paper), profileId (e.g., faros_llm), and optional executionMode 'plan' to only generate a plan. The workflow executes capabilities: idea_refinement generates ranked idea candidates; experiment scaffolds a code project and experiment record; paper_drafting produces a venue-aware LaTeX project and PDF; reviewer_simulation outputs a structured review with action items. Artifacts are stored as files in DATA_DIR. The REST API includes endpoints like /api/faros/blueprints, /api/faros/profiles, /api/faros/runs/{run_id}/events, and /api/faros/artifacts. LLM providers are configured via environment variables or provider_config.json, supporting multiple providers including minimax.
- A research team wants to automate initial paper drafting with venue-specific LaTeX formatting
- A researcher wants to validate a research idea by generating a plan without executing full LLM runs
- Researchers need a simulated peer review of a draft paper to receive structured feedback
- A developer wants to integrate research automation into their pipeline via the REST API
- A lab wants to scaffold code projects for LLM experiments as a precursor to real execution
What are this agent's strengths and limitations?
- Separates research automation into runtime concerns (blueprint, capability, profile, provider), enabling extensibility to new domains
- Provides a complete idea-to-review pipeline with venue-specific LaTeX paper generation
- Offers a REST API and plan mode for easy integration and low-cost validation
- Uses file-based persistence, avoiding the need for external databases
- Current release is LLM-domain only; experiment stage is a scaffold, not real code synthesis or execution
- Linear execution only; no DAG scheduling or parallel orchestration yet
- Provider configuration is via environment or config file, making provider switching non-trivial
- Only minimax is explicitly cited as a provider in the codebase, despite claims of multi-provider support
- No frontend console; management is API-only
How do you install or deploy this agent?
Install Python 3.11+ and Node.js 18+, plus latexmk and pdflatex for PDF compilation. Backend: cd backend && pip install -r requirements.txt. Frontend: cd frontend && npm install. Configure LLM provider API keys via environment variables or backend/data/provider_config.json; do not commit real keys.
How do you use this agent?
Start the backend: cd backend && uvicorn app.main:app --host 127.0.0.1 --port 8005 --reload. Start the frontend: cd frontend && npm run dev. Verify readiness: GET /api/system/version should report llm.configured=true. Create a run: use curl with POST /api/faros/runs. Example: curl -X POST http://127.0.0.1:8005/api/faros/runs -H 'Content-Type: application/json' -d '{"blueprintId": "ml_paper", "profileId": "faros_llm", "executionMode": "plan", "inputs": {"seedQuery": "Improve CPU efficiency in LLM workflows", "paperType": "system", "targetVenue": "generic"}}'. Then fetch run details via GET /api/faros/runs/{run_id} to inspect status and artifacts.