1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
# awl Ideas
`awl` is a minimal coding agent inspired by `pi`, with a focus on performance, efficiency, correctness, and a small core that can be extended deliberately.
## Core architecture
- The core agent loop will be written in Zig for performance, efficiency, and a small runtime footprint.
- In addition to the CLI/application, the project should expose a `libawl` library through a C ABI so other programs can embed or build on the agent functionality.
## Extension system
- Extensions will initially be written in Lua, chosen for speed, simplicity, and low overhead.
- Because poorly written extensions can easily destabilize the host, `awl` should explore ways to improve extension correctness and crash protection.
- Future extension support should include loading shared object libraries through a C ABI, allowing extensions to be written in Zig, Rust, C, C++, or other native languages.
## Minimal built-in feature set
- `awl` should follow `pi`'s philosophy of avoiding unnecessary built-ins such as native subagents, MCP support, and permission systems.
- `awl` will go further by not building in AGENTS.md automation, skills, or customizable `/prompts`.
- Those features should be possible to implement as extensions rather than being part of the core runtime.
## Provider API support
- Provider support should be careful and conservative.
- The core should support Anthropic-shaped and OpenAI-shaped APIs with arbitrary base URLs.
- The goal is to avoid the common failure mode where provider integrations exist but only partially work, break important agent features, or crash the process.
## Server/proxy mode
- `awl` should support running as a server that exposes OpenAI-compatible and Anthropic-compatible APIs.
- In this mode, `awl` can act as a lightweight provider router/proxy to its configured backends.
- This is intended to provide the useful parts of tools like `omniroute` while avoiding excessive memory usage, fragile integrations, and runtime instability.
## Core tools as extensions
- Basic tools such as `read`, `write`, `edit`, and `bash` should be supplied by extensions rather than hardcoded into the core.
- These tools can be included in the standard distribution but should be individually disableable.
- Once shared object extension support exists, the standard core tools should be ported to Zig/native extensions.
|
