You Can't Give an AI a Job Until It Has a Lane

A developer argues that AI agents cannot function as employees until they are given a defined "lane" — a unit of work with context, memory, schedule, boundaries, and escalation rules — rather than being driven through a chat box. The post outlines a Lane data structure and a goal-tools-loop-lane-ownership pipeline, contending that durable state and human approval gates, not better prompts, are what turn an agent loop into real responsibility.

Most AI software still starts the same way. There is an empty box. You type something. The model responds. Then it stops. And waits for you again. That interface makes sense for an assistant. It makes less sense for an employee. An assistant is reactive by design. It waits for you. It executes one task. It returns control. An employee is different. It owns a lane. It runs on a schedule. It escalates only when needed. If you try to hire an AI by stuffing a better prompt into a chat box, you will keep getting assistant behavior. Fast answers. Impressive demos. Weak ownership. The missing piece is not more tools. The missing piece is a lane . An AI agent is a loop: goal observe → decide → act → repeat That loop is useful. But a loop is not a job. A loop can finish a task and disappear. A job needs continuity. To give an agent real responsibility, it needs more than a goal and a toolbelt. It needs: Stack those around the loop and the agent stops being a clever chat reply. It starts looking like ownership. Goal ↓ Tools + Loop ↓ Lane context + memory + schedule + boundaries + escalation ↓ Actual ownership Without the lane, you have a talented intern with no desk, no calendar, and no idea what "done for the week" means. A lane is the smallest unit of work you would trust a person to own without babysitting every click. Not "help with marketing." Something like: api/ A good lane has five properties: That last one matters more than people admit. Autonomy without boundaries is not empowerment. It is liability with a progress spinner. Chat optimizes for turn-taking. You ask. It answers. You ask again. Ownership optimizes for unfinished work across time. The employee should still know the lane on Tuesday even if nobody typed anything on Monday night. That requires durable state: type Lane = { id: string owner: string // human or AI employee outcome: string cadence: "cron" | "event" contextSources: string allowedTools: string memory: Record<string, unknown boundaries: string escalateWhen: string lastRunAt?: string lastResult?: string } The model can still reason inside the loop. The lane is what makes the loop mean something tomorrow. Say you want an AI content lead. Bad brief: Write social posts about AI agents. Better lane: Own the BHJR weekly essay pipeline. Every Sunday night, propose 3 angles in our voice domains, pick one after human approval, draft the long-form post, generate LinkedIn and X variants, and stop before publishing. Now the system has shape: That is not "an agent that writes." That is a role with a lane. If you are building agent products, stop starting with the model. Start with the job description. Ask: Then wrap a loop in that lane. The interesting software is not the prompt. The interesting software is the operating surface around responsibility: memory, permissions, schedules, audit logs, and the human approval gate. We spent years teaching people to talk to software. Now we are teaching software to take responsibility for work. That only works when the work has edges. No lane, no job. Just another empty box waiting for the next message. If you want useful AI at work, do not ask how smart the model is first. Ask whether you gave it a lane worth owning.