# Build brief — a focused alternative to AdaL

> **Verdict:** Partly, if you narrow it · **Buildability:** 63/100 · **Category:** Dev Tools
> **Source:** https://www.canitbevibecoded.com/adal
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from AdaL. Verify current pricing and capabilities before acting.

## Context

**AdaL** — Coding agent that routes work to specialized workers across frontier model families. It currently costs $20/mo.

The core loop is genuinely reachable: open-source agents already route across model families, run tools, and edit repos, and a focused implementation of wiring gets you a personal version. What does not fall out of a focused implementation is the harness around the model, which is where AdaL claims its numbers come from, plus browser-based verification, clustered code review, and the team controls. You end up with an agent that works and a noticeably worse recovery rate on long tasks.

This brief describes a focused, single-operator replacement for the part of AdaL that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

Wire a terminal agent to several provider APIs, give it file, shell and test tools, and let a planner sub-agent hand tasks to specialized workers in one session.

- Build the focused developer workflow you use repeatedly, with local configuration.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node 20 or Python 3.12.
- Git repo to work against.
- Playwright if you want the browser-verification worker.

### Data and integrations

- API keys for at least two providers in .env.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a multi-model coding agent CLI to replace AdaL, in an empty folder.
Stack: Python 3.12, one file per module, no framework.

- Providers: Anthropic, OpenAI and Google, behind a single `chat(model, messages, tools)`
  function. Keys from .env via python-dotenv, never hardcoded. A `--model` flag
  switches families mid-session without restarting.
- Tools the agent can call: read_file, write_file, list_dir, run_shell, run_tests.
  run_shell prints the command and waits for y/n unless I pass --yolo.
- An orchestrator loop: a planner call splits my request into numbered steps, then
  each step runs as a fresh sub-agent with its own context window and only the tools
  it needs. Sub-agent results append to a shared markdown scratchpad on disk.
- Persist every session as JSONL under .agent/sessions/ so I can replay or resume.
  A `--resume <id>` flag reloads the scratchpad and continues.
- After any step that edits files, automatically run the test command from
  pyproject.toml and feed failures back to the same sub-agent for one retry.
- Print a running token and dollar total per provider at the end of every turn.
- Out of scope, deliberately: browser automation, a GUI, team accounts, and any
  hosted service. Those are the parts the subscription is actually selling.
- README: setup, the .env template, how to add a fourth provider, and one honest
  paragraph on where this loses to a tuned commercial harness on long tasks.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Harness tuning: the planning, recovery and verification work that separates a demo agent from one that finishes long tasks.
- Browser-use verification of the app you just changed.
- Review clustering that groups a large diff into risk-ranked units.
- One bill across every frontier provider instead of six metered API accounts.
- SSO, SAML/SCIM, zero data retention and org-level model deny lists.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.
- Maintain every third-party integration as APIs and OAuth rules change.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

## Existing alternatives

Before building, compare these checked options:

- [OpenCode](https://opencode.ai/) — A terminal coding agent with no loyalty to any model vendor; you still pay the meter
- [Cline](https://cline.bot/) — An agent that lives in the editor you already use; the model bill is still yours
- [Goose](https://goose-docs.ai/) — A desktop and terminal agent with real extension support, and no pretence that the model is free

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [AdalFlow](https://github.com/SylphAI-Inc/AdalFlow) — The vendor's own open-source agent library; the building blocks are public even though the product is not
- [LiteLLM](https://github.com/BerriAI/litellm) — One API shape over every provider, which is the boring half of model routing

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/adal