Software execution belongs beside the developer

Developer tooling has settled into a strange shape. The work is local. The code lives on your machine. The terminal is yours. The editor is yours. The credentials and the running processes are yours. Most of the systems that automate developer work, however, run somewhere else and reach in through a detached interface.

The result is friction. You describe your local state to a remote system that does not have it. You wait. You copy. You paste. You context-switch. The system returns a suggestion, and you do the work of applying it back to the place where the work always was.

This is the wrong abstraction. Software execution should happen beside the developer. Planning, memory, permissions, execution, and review belong in the same environment as the repository, the terminal, and the credentials.

Cal is built on that premise. The interface is the device. The runtime is local. The environment is yours.

Capture, reason, act. The system listens, models project context against permissions and tools, then acts inside the development environment. The output is evidence of action. Terminal lines. Commits. Deployments. Observability signals. Not widgets to apply later.

Developers do not think in tools. They think in outcomes. Create, investigate, ship, operate. These are not four interfaces. They are one conversation with the system that already runs the code.

Tell Cal what you want. Not which tools to open.