Skip to main content
job_type is the discriminator that selects how the worker handles a section. Every section in A profile’s config.yaml declares one, and the worker dispatches the section to the matching job-type implementation. For the user-level mental model of sections, sessions, and agents, see Concepts; this page is the specification of what the discriminator selects. A section’s job_type determines three things:
  • Required blocks — which job-type-specific blocks the section must declare under it (e.g. session_agent_harness requires a session block).
  • Top-level blocks — which additional top-level config blocks apply to the section (e.g. session_agent_harness consults the agents block for agent settings).
  • Runtime behavior — what the worker actually does with the section: what it attaches to, what it polls, and what it posts.
The generic start flow handles process startup, identity checks, config load, and section dispatch. Once a section is dispatched, the per-job-type implementation owns its lifetime — including recovery on restart.

​
Supported job types

Each job type has its own group under Specification containing its full notation: the session objects it drives, its filesystem layout, its workflows, and its reference (error codes and limitations). The generic config.yaml blocks are shared by all job types and documented once under Configuration.

​
Adding a new job type

Future job types land as their own navigation group alongside Session Agent Harness, following the same shape (overview, filesystem layout, session objects, workflows, reference). The generic Overview pages and the shared config.yaml reference do not change when a job type is added; only that job type’s sections shape and its top-level block usage are new.

​
See also