System Project Management with Sylang

5.1 Why project management belongs inside the engineering model

Three failures of the separated arrangement become acute under AI authorship. We'll take them one at a time. The Sylang artifact types in 5.2 and 5.3 address each one.

Failure 1: scope ambiguity

Ask an AI agent to extend the EPB project (add the auto-vehicle-hold feature, say). In the separated arrangement, it has no native way to tell whether that work is in scope for the current sprint, deferred, cancelled or never planned. That leaves it three options, none of them good:

Failure 2: traceability gaps between work and artifact

Say a Jira story is marked done, but the artifact it produced was never merged to trunk. Or the reverse: an artifact lands in trunk with no matching closed work item. Either way, the project's audit trail now has gaps. If you've ever had to chase one of these down before a release review, you'll recognize the problem.

A coverage query over the project can then answer three questions in seconds. Which tasks marked done have artifacts at their declared outputfile paths? Which artifacts aren't the outputfile of any task? And which tasks point at outputfile paths that don't exist?

Failure 3: opaque agent attribution

The third failure matters most for audit. Project tools attribute a work item to a user, and version control attributes a commit to a user. Both assume each user is a single human author, and that assumption breaks once AI agents commit on users' behalf.

Now an auditor asks, who authored this artifact? The answer has to be pieced together from scattered sources: the commit message (if someone bothered to note the agent's role), the chat transcript (if it was kept) and the project tool (if the work item even references the artifact). None of these is canonical, so the reconstruction is best-effort and the auditor's confidence in it is limited.

How the pipeline fits together

Expand

The MCP server exposes Sylang's ~60 structured operations as agent tools. The validator runs at parse time on every change, and git is the system of record. Together, the pipeline closes the loop from project scope to authored artifact to audit-grade attribution.

What the rest of the chapter builds

Sylang's answer to all three failures is a unified model. Project work items live in the same artifact set as the engineering artifacts they produce. They reference each other through typed relationships the validator enforces, and they get the same coverage analysis as any other artifact.

Subchapter 5.2 covers the .agt file type, and 5.3 covers the .spr file type. Subchapter 5.4 then shows the coordination patterns for running a real multi-agent engineering project.

Exercises

5.2 Agent definitions: the .agt file

The .agt file type declares the AI agents that take part in authoring your project. Each def agent clause names a specialist agent (the safety manager, the architecture lead, the test engineer) along with the metadata the agent loader uses to dispatch tasks. In this subchapter we'll look at the file type and at the conventions for designing a good agent set.

File structure

An .agt file declares a single agentset holding one or more def agent clauses. By convention there's one agentset per program, named after the program identifier (for example, EpbProgramAgents.agt). Each def agent carries a small, fixed set of properties: name, description, owner, role, specialization, expertise and context.

An agent definition carries no outward ref relationships. Agents are leaves in the project graph: references flow inward to them from work items in .spr files.

Here's a representative agent from the EPB project's agentset:

  def agent SafetyManager
    name "Functional Safety Manager"
    description """
      ISO 26262 lead. Owns the safety case, the ASIL allocation,
      and the hazard/safety-goal chain end-to-end.
    """
    role "Functional Safety Manager"
    specialization "Automotive Functional Safety (ISO 26262)"
    expertise """
      ISO 26262 part 3 hazard analysis (HARA)
      ISO 26262 part 4 technical safety concept
      ISO 26262 part 9 ASIL decomposition (Annex C)
      AIAG-VDA FMEA scoring with temporal logic
      Safety case construction (GSN, CAE)
      Notified body engagement and audit preparation
    """
    context """
      Automotive drivetrain and chassis programs
      ASIL-D items requiring full safety case
      Reviewing .haz / .sgl / .req / .flr / .fta artifacts
      Coordinating with notified bodies (TUV, Bureau Veritas)
    ""\

Design principles for the agent set

How well an agent set works comes down to three design principles. I drew them from my experience building the four anchor projects.

A complete agent set for the EPB program

How the Sylang Studio agent loader uses .agt

When you type a task into the agent chat, the Sylang Studio agent loader scans the project's .agt files. It matches your task against each agent's expertise first and context second. The agent whose expertise fits best gets the task.

That separation pays off in portability. The same artifact set works across agent runtimes and model providers, with no changes to the project's source files.

From declarations to assignments

The .agt file declares the agents. The actual assignment of work lives in the .spr (sprint) file, which Subchapter 5.3 covers. Together, agent declarations and sprint assignments are the whole project-management contribution to the Sylang artifact set. It's a small surface (perhaps 200 to 500 lines of Sylang for a typical program), but it delivers the benefits described in 5.1.

Exercises

5.3 Sprint planning: the .spr file

The .spr file type holds your project's iteration plan in a form that AI agents can read, the validator can enforce and the safety case can use as process-compliance evidence. In this subchapter you'll see the file's structure and walk through a sprint from the EPB anchor. You'll also pick up the patterns that make .spr-driven project management work in practice.

File structure

An .spr file declares a sprint (the file's hdef) containing a hierarchy of def epic → def story → def task. If you've used Jira, Linear or Azure DevOps Boards, the hierarchy will look familiar:

• Epic: a scope item that spans several sprints
• Story: a user-facing scope item that fits in one sprint
• Task: an engineering work item that produces a specific artifact

Each level carries properties for status (issuestatus), priority, a story-point estimate and assignedto, which references an agent from the project's .agt. Here's an abridged example from the EPB sprint:

use agentset EpbProgramAgents

hdef sprint EpbSprint01
  name "EPB Platform — Sprint 01"
  startdate "2026-05-01"
  enddate "2026-05-29"

  def epic SafetyChainDraft
    name "ISO 26262 Safety Chain Draft"
    assignedto ref agent SafetyManager
    issuestatus inprogress
    priority critical

    def story HazardAnalysisDraft
      name "Hazard analysis with ASIL assignment"
      assignedto ref agent SafetyManager
      issuestatus inprogress
      priority high
      points 8

      def task EnumerateMalfunctions
        name "List malfunctions of EPB top-level functions"
        assignedto ref agent SafetyManager
        issuestatus done
        priority high
        points 2
        outputfile "System/EpbHazards.haz"

      def task AssignAsil
        name "S x E x C scoring and ASIL determination"
        assignedto ref agent SafetyManager
        issuestatus inprogress
        priority high
        points 3
        outputfile "System/EpbHazards.haz\

How agents consume the sprint

An AI agent working on a Sylang project reads the current .spr at session start (or several .spr files, if the program runs concurrent sprints). It does this through the MCP tool sylang_get_sprint_tasks { agent: "SafetyManager" }. The agent finds the open tasks assigned to it and orders them by priority and issuestatus, so high-priority inprogress tasks come before lower-priority open ones.

1. The agent reads the sprint. An MCP call returns the agent's open tasks.
2. It picks the highest-priority task. It reads the task's name, description and outputfile.
3. It produces the artifact. It writes it through further MCP calls (sylang_get_symbol_by_id, sylang_validate_file, sylang_write_file).
4. It commits. The artifact and the updated .spr (task → done) go into a single atomic commit.
5. The audit trail follows. The commit history ties artifact production to agent attribution and task closure.

Reporting via .spec / .dash

Once the sprint lives in the model, status reporting becomes a coverage query instead of a separate chore. Chapter 16 covers reporting in detail. These are the main queries:

From single sprint to multi-sprint

So far we've looked at a single sprint. Real programs run many sprints over a development cycle, with cross-sprint dependencies, retrospective updates and the usual agile machinery. Sylang supports this by allowing many .spr files in one project (one per sprint, conventionally in a Sprints/ directory) and by letting outputfile references span sprints.

Subchapter 5.4 covers the patterns for multi-sprint coordination: retrospectives, cross-sprint backlog management and capacity planning across agents.

Exercises

5.4 Coordination patterns for multi-agent engineering teams

Picture a program with 5 to 15 named AI agents and three to seven human reviewers. It needs coordination patterns that fit that scale. Conventional agile habits (stand-ups, retrospectives, planning poker) were designed for human teams of a similar size and are still useful, but mixed human-agent teams need more. This subchapter covers the four patterns I consider most consequential.

Pattern 1: agent specialization without artifact siloing

When you design an agent set, it's tempting to specialize narrowly: one agent for hazard analysis, one for safety goals, one for safety mechanisms, each owning exactly one artifact type.

In practice, a hazard analysis task goes to SafetyManager, and so does the matching safety goals task. Requirements derivation goes to SafetyManager for safety requirements, or to RequirementsEngineer for functional ones. Agents then collaborate at the artifact level: SafetyManager and ArchitectureLead might both edit the requirements file in interleaved commits. The project's coherence comes out of that collaboration.

Pattern 2: explicit reviewer agents distinct from author agents

Your agent set should include at least one reviewer agent that never produces artifacts and only reviews them. Its expertise stresses consistency checking, coverage analysis and conformance to standards, not artifact production.

  def agent ReviewerAgent
    name "Cross-Cutting Reviewer"
    role "Engineering Reviewer"
    specialization "Multi-Standard Conformance + Coverage Analysis"
    expertise """
      ISO 26262 work-product clause-by-clause conformance
      ASPICE bilateral traceability completeness checks
      Coverage-report-driven orphan/broken-ref triage
      ASIL inheritance audits across the safety chain
      Pre-merge sanity sweeps on diff sets
    """
    context """
      Runs on every commit trigger
      Produces structured review comments
      Flags issues for human reviewer triage
      Never produces new artifacts — only annotates
    ""\

1. Focused triage for the human reviewer. The reviewer agent flags changes that look problematic, and the human looks at flagged items first.
2. An evidence trail of automated review. This adds to human review for audit. The auditor can see that every artifact passed automated consistency checks before acceptance, and exactly which checks ran.

Pattern 3: scheduled retrospective agents

At the end of each sprint, a specialized RetrospectiveAgent runs a structured analysis of how the sprint went. It looks at:

• Which tasks finished on time and which slipped
• Which agents delivered more or less throughput than estimated
• Which artifacts needed the most rework cycles
• Which review flags kept recurring during the sprint

Strictly speaking, you don't need a retrospective agent, because a human program manager could run the same analysis. What the agent adds is formality: the practice happens every sprint, and it happens the same way each time.

Pattern 4: human-in-the-loop for safety-relevant decisions

Some decisions should never be delegated to an AI agent. These are the main ones:

Sylang doesn't enforce these exclusions in the grammar; in principle, any agent can change an artifact's status property. The convention lives at the IDE and runtime level instead. Certain status transitions need an explicit human sign-off, captured in the commit message and checked by a CI rule.

Those transitions are draft → approved on a safety-critical artifact, ASIL escalation and residual-risk acceptance. You can configure your Sylang Studio installation to enforce this convention, and production installations typically do.

Closing Chapter 5

This chapter covered Sylang's project-management surface in enough detail for you to organize a real engineering program. You've seen the two file types (.agt and .spr), the design principles for agent sets, the dispatch and reporting workflows and the coordination patterns above. You've also seen the pipeline from 5.1: .agt → Sylang Studio agent loader → Hermes runtime → MCP server.

Together, these are the project-management contribution to the artifact set. The engineering-spine chapters that follow (6 to 11) build on them when they show how artifacts get authored, reviewed and integrated.

That completes Part II of the book, the foundations. From here we develop the language's substantive content: PLE in Chapter 6, functions in 7, architecture in 8, requirements in 9, tests in 10 and integration in 11. Then come safety engineering in 12 to 15, reactive documentation in 16 and the closing argument in 17.

Exercises