Repository navigation
EN Core Concepts
한국어 | English
This page summarizes the concepts that recur throughout the AGS documentation.
A task contract is the baseline for the work.
It typically captures:
- goal,
- scope,
- completion criteria,
- risk,
- authority and constraints,
- and required validation.
As work becomes longer or more iterative, the original objective can drift away from the current implementation. The task contract keeps later decisions anchored to a stable frame.
A skill defines specialist guidance for a specific type of judgment.
Examples include:
task-contractchange-scope-guardianmutation-risk-preflightacceptance-evidence-validatorindependent-audit-gateblocker-diagnosticianrecovery-strategy-selector
A skill is more than a prompt fragment. It defines when a capability applies, what it should examine, and what kind of result it should produce.
The orchestrator connects specialist capabilities into an execution flow.
It selects relevant providers, orders them, connects required artifacts, and integrates their results.
It does not replace specialist judgment. It coordinates it.
A workflow is a structured execution that connects multiple specialist stages.
A typical lifecycle is:
plan_workflow
↓
start_guarded_workflow
↓
record_stage_result
↓
record_stage_result
↓
finalize_workflow
The runtime checks whether each stage is consistent with the frozen plan and the declared contracts.
A stage is one specialist step inside a workflow.
A stage result can include:
- status,
- structured output,
- evidence references,
- findings,
- blockers,
- and actor information.
Evidence is the current basis for a completion claim.
AGS deliberately separates assertions from evidence.
For example, the sentence "all tests passed" is weaker than a result tied to an actual execution record, artifact, file reference, digest, or receipt.
Audit is a separate review of requirements, changes, evidence, and failure modes.
For high-risk work, AGS supports separating the implementation role from the audit role so that completion does not depend entirely on the implementer's own judgment.
A peer session is an execution context that retains its own context and responsibility while collaborating with other sessions.
"Peer" does not mean that every session has identical authority or capability. It means the collaboration model is not restricted to a single parent-child delegation tree.
The session board provides a shared view of active responsibility.
A session entry can include:
- host,
- session ID,
- working directory,
- current task summary,
- and timestamps.
It helps one session discover which other session currently owns relevant work.
A PEER message carries actual collaboration content between sessions, such as:
- requests,
- discovered constraints,
- evidence references,
- audit findings,
- blockers,
- or work results.
Messages are tracked using system-issued message IDs.
ACK means message processing has been acknowledged.
It does not mean:
- the requested work is complete,
- the result passed review,
- execution was approved,
- or the user granted new authority.
The business result must be evaluated separately.
Wake is a host-specific mechanism for notifying an idle session that work may be available.
The message body and the wake signal are intentionally separate concepts.
Context continuity preserves selected task state across long-running work.
It can retain scope, decisions, unresolved issues, and verification references in a checkpoint.
Rather than blindly reinjecting an entire previous context, AGS is designed to restore only the state needed to resume the task frame.
A workflow receipt is a structured record of workflow state and validation.
The existence of a receipt does not automatically prove that every submitted claim is externally true. The runtime validates structure, sequencing, state, and configured gates; semantic correctness still depends on specialist reasoning, evidence quality, and audit.