Onboard Agents as Your Teammates

The Intern Model

Every agent framework today works the same way. You describe a task. The agent executes it. You get a result. The agent disappears.

This is the intern model. Interns are useful — they do what you tell them. But you would never say an intern is your teammate. Teammates don't wait for assignments. They own things. They notice problems before you do. They generate work, not just consume it.

The entire industry is building increasingly sophisticated interns. Better tool use, longer context, multi-step reasoning, chain-of-thought planning. All of it in service of one pattern: human assigns, agent executes.

This is necessary but insufficient. The ceiling of the intern model is a very fast, very capable task executor that still requires you to be the brain. Every intent originates from you. Every "what should I do next?" is your problem.

That doesn't scale.

What Real Teammates Have

Think about what happens when you hire an infrastructure engineer. You don't hand them a task list on day one. You say: "You own deployments, staging, and CI/CD pipelines."

From that point forward, they:

• Notice when the pipeline is slow — without being told
• Fix the staging environment when it breaks — without a ticket
• Propose migration to a better deployment tool — without being asked
• Accumulate expertise about your specific infrastructure — without formal training

The work flows from their area of ownership. They don't need you to generate every intent. Their scope generates intents for them.

Now compare this to how we use agents today. We create a mission: "Optimize the CI/CD pipeline." An agent picks it up, does some work, reports back. Maybe it does a good job. But tomorrow, when a different pipeline problem surfaces, nobody notices until a human creates another mission.

The agent had no scope. It had a task.

The Missing Primitive: Scope

Scope is not a role. Roles in multi-agent frameworks are prompt decoration — "You are a senior backend engineer" prepended to a system message. The agent doesn't actually own backend. It just roleplays owning it for the duration of one conversation.

Scope is structural. It's a persistent definition of what an agent owns, watches, and acts on. It determines:

• What events wake the agent up — a frontend agent doesn't care about deployment failures; an infra agent does
• What the agent monitors — the scope defines the observation surface
• What intents the agent can generate — work flows from scope, not from assignment
• What authority the agent has — the infra agent can push to staging without asking; production requires approval

The hierarchy is clean:

Agent (persistent teammate)
  └── Scope (what they own)
       └── Intent generation
            ├── Task (small — just do it)
            └── Mission (big — plan, break down, execute)

Scope is the generative source. Tasks and missions are just intents of different sizes that flow from it. The agent itself decides whether something is a quick fix (task) or needs planning (mission).

This inverts the current architecture. Instead of missions creating agents, agents create missions from their scope.

The Agent Loop

A teammate doesn't poll a task queue. They respond to what happens in their domain. The agent loop is event-driven:

Event	Trigger
Heartbeat	Periodic (e.g. every 10 minutes) — scan your domain
TaskComplete	A task you spawned finished successfully
TaskFailed	A task you spawned failed
MissionComplete	A mission you created was completed
MissionFailed	A mission you created failed or got stuck

On each wake, the agent reviews three things: its scope, the event that woke it, and its accumulated experience (context, skills, past outcomes). Then it decides:

1. Create a task — something small needs doing
2. Create a mission — something big needs planning
3. Schedule recurring work — something needs to happen regularly (cron-like)
4. Do nothing — everything in the domain is fine

The agent is always alive. Not always running — but always present. It has continuity. It remembers what it tried last week. It knows which approaches failed. It builds judgment within its scope.

Three tools make this concrete:

• Task — spawn a small unit of work with acceptance criteria
• Mission — spawn a bigger effort that needs decomposition
• Schedule — create a recurring task ("run security audit every Monday")

These are the agent's hands. Scope is its eyes. The event loop is its heartbeat.

Acceptance Criteria: Contracts, Constraints, Transformations

Here's the hard problem: how do you know the work is correct?

In the intern model, the human reviews. That's the bottleneck we're trying to eliminate. If the agent generates its own work, it also needs to define — deterministically — what "correct" looks like.

Every task and mission carries acceptance criteria using the CCT framework:

Contracts define interface agreements. The shape of inputs and outputs. "This API endpoint accepts a JSON body with { userId: string } and returns { status: 'active' | 'suspended' }." Contracts are verifiable through type checks, schema validation, and API conformance tests.

Constraints define invariants and boundaries. Things that must remain true regardless of what changes. "No breaking changes to the public API." "Response latency under 200ms at p99." "All user data encrypted at rest." Constraints are verifiable through property-based tests, benchmark assertions, and invariant checks.

Transformations define the before-and-after delta. The actual state change the work should produce. "Given the current deployment takes 12 minutes, after this work it should take under 4 minutes." Transformations are verifiable through integration tests, diff checks, and measurable benchmarks.

CCT Dimension   →  Deterministic Verification
─────────────────────────────────────────────
Contracts       →  Type checks, schema validation, API conformance
Constraints     →  Property tests, invariant assertions, boundary checks
Transformations →  Input→output tests, integration tests, before/after diffs

The key insight: each CCT dimension maps directly to a class of deterministic tests. "Done" is not a human judgment call. It's a test suite passing. The agent defines what correct looks like before the work begins, generates tests from that definition, and uses test results to decide whether to continue or mark complete.

This closes the loop:

Agent wakes (event)
  → Reviews scope + context
  → Generates intent (task or mission)
  → Defines acceptance criteria (CCT)
  → Work executes
  → Tests generated from criteria
  → Tests run
  → Pass? → TaskComplete event → Agent wakes
  → Fail? → TaskFailed event → Agent wakes, adjusts approach

No human in the verification loop. The acceptance criteria are the governance.

What Changes

This isn't a feature addition to existing agent frameworks. It's a structural shift in what an agent is.

From ephemeral to persistent. Agents don't spin up for a task and vanish. They exist as long as their scope exists. They accumulate experience, build skills, develop judgment specific to their domain.

From assignment-driven to scope-driven. The human doesn't need to be the sole source of intent. Agents observe their domain and generate work proactively. The human becomes a peer who can assign work into an agent's scope, but isn't the only source of it.

From vibes-based to deterministic. "Looks good to me" is replaced by CCT acceptance criteria that compile down to runnable tests. Review becomes verification. Verification is automated.

From isolated to event-driven. Agents don't work in a vacuum. Task completion by one agent fires events that wake other agents. The infra agent deploys a new version; the QA agent's heartbeat picks up the change and runs regression tests. Work flows through the system like signals through a nervous system.

From skill-less to skill-accumulating. Each completed task within a scope adds to the agent's experience. The infra agent that has deployed 200 times knows things about your specific infrastructure that no fresh agent could. This experience is the agent's competitive advantage — and your organization's institutional knowledge.

The Onboarding Mental Model

Stop thinking about "configuring agents" and start thinking about "onboarding teammates."

When you onboard a new teammate, you:

1. Define their scope — "You own X"
2. Give them tools — access to systems, permissions, communication channels
3. Set expectations — what does good look like (acceptance criteria)
4. Let them ramp up — they start slow, build context, get faster
5. Trust them to self-direct — within their scope, they don't need permission for every action

This is exactly the model. The agent's scope is their job description. The tools (Task, Mission, Schedule) are their agency. CCT acceptance criteria are the shared definition of quality. The context store is their growing expertise. And the event loop is their presence — always there, always aware of their domain, always ready to act.

The question isn't "what task should I give my agent?" The question is "what should my agent own?"

Agent（持久化的队友）
  └── Scope（负责的领域）
       └── 意图生成
            ├── Task（小事——直接做）
            └── Mission（大事——规划、拆解、执行）

CCT 维度     →  确定性验证方式
─────────────────────────────────────────────
Contracts    →  类型检查、Schema 验证、API 一致性
Constraints  →  属性测试、不变量断言、边界检查
Transformations →  输入→输出测试、集成测试、前后差异对比

智能体被唤醒（事件）
  → 审视 Scope + 上下文
  → 生成意图（Task 或 Mission）
  → 定义验收标准（CCT）
  → 工作执行
  → 根据标准生成测试
  → 运行测试
  → 通过？ → TaskComplete 事件 → 智能体被唤醒
  → 失败？ → TaskFailed 事件 → 智能体被唤醒，调整方案