AI agents can help space teams review requirements, inspect traceability, assess proposed changes, prepare verification work, compare interfaces and assemble evidence. Each workflow needs a defined input, a reviewable output and an engineering decision that remains with an authorised person. The useful starting point is a small programme question whose answer can be checked against identified records and revisions.
Define the task before choosing an agent
A request to “review the spacecraft” has no reliable completion condition. A request to list unresolved electrical inconsistencies affecting one payload interface in baseline BL-03 can have one. Specify the records the assistant may read, permitted tools, applicable configuration, allowed output location and conditions that require escalation. Also identify who will judge whether the returned evidence answers the question.
Some of these activities need a fixed query or rule. Others need a language model to interpret engineering text, or an agent to select follow-up searches. Anthropic distinguishes predefined workflows from model-directed agents and recommends adding complexity only where it improves the task. Its article supplies architecture guidance, not evidence of spacecraft engineering performance.
The six workflows below are original implementation examples. NASA's requirements-management guidance provides their process context: traceable requirements and assessed changes throughout the lifecycle. The examples explain how a team could organise assistance around those responsibilities; they do not prescribe a universal tool configuration.
Six workflows with different deliverables
| Workflow | Input | Reviewable output | Human decision |
|---|---|---|---|
| Requirements review | Requirement revision, source obligation and writing rules | Issue list with cited passages and proposed corrections | Whether an issue is real and its correction preserves intent |
| Traceability | Known records, relationship types and applicable baseline | Missing-link findings and separately labelled candidate links | Whether each relationship has the claimed engineering meaning |
| Impact analysis | Proposed difference and connected programme context | Affected-record list, calculations and unresolved dependencies | Whether the change is feasible and what must be reassessed |
| Verification planning | Requirement, configuration, method rules and existing plans | Draft verification activity with conditions and evidence needs | Whether the method and acceptance criteria are adequate |
| Interface review | Both sides of an interface and relevant operating modes | Compatibility questions and discrepancies assigned by boundary | Whether the parties agree on the interface and its changes |
| Evidence preparation | Approved scope, source records and review entry criteria | Revision-specific evidence index with gaps and exceptions | Whether the package is ready for the intended review |
1. Requirements review: make the question precise
Give the assistant the complete requirement, its rationale and source, not an isolated sentence stripped of context. Ask it to distinguish ambiguity, an apparent conflict, missing conditions and editorial style. An unspecified operating mode can affect a power limit; a preferred spelling normally cannot. Every finding should quote or locate the passage that triggered it and explain the engineering consequence.
A useful output says that the proposed peak-power wording lacks a measurement interval and asks the requirement owner to supply it. A weak output invents a convenient interval and presents the requirement as repaired. Reviewers should accept the problem and the proposed remedy separately. Sometimes the right action is to clarify the source obligation before drafting new text.
2. Traceability: separate a missing link from a missing obligation
Start with the relationship types the programme actually uses. “Allocated to,” “constrained by” and “verified by” describe different things. Have the assistant inspect existing links before proposing additional ones. A keyword match between two records is a search result; the relationship still needs a technical rationale.
Request a candidate's source identifier, target identifier, both revisions, proposed relationship and supporting passage. Ask what alternative interpretation was considered. If the record has no parent, determine whether its rationale explains a derived requirement before treating the gap as an error. The owner's decision should address the meaning of the link, not merely tidy a coverage display.
3. Impact analysis: expose the limits of the search
Provide an explicit difference and a baseline identifier. The agent can follow approved relationships, search related records and list likely follow-up work. Each affected item should explain how the change reaches it: a direct constraint, an allocated budget, a shared interface or evidence produced for an earlier configuration.
The output must also report scope boundaries. An inaccessible supplier model, missing operations scenario or unlinked thermal assumption can limit the conclusion. “No impact found in accessible records” is a useful statement when accompanied by the search scope. It is insufficient grounds for asserting that the entire spacecraft is unaffected.
4. Verification planning: draft the conditions, not a pass
Supply the requirement and the configuration it will apply to. Ask for a proposed method, measured or analysed quantity, acceptance criterion, test conditions, required equipment or model, evidence record and unresolved assumptions. The draft should distinguish an activity that is planned from one that has been executed and accepted.
NASA's product-verification guidance connects verification to the specified product requirements and configuration. In this workflow, the verification lead checks that the proposed activity can demonstrate the actual obligation. A familiar procedure name alone is not enough, especially when a revision changes the conditions under which a previous result was obtained.
5. Interface review: compare both owners' assumptions
A payload description and a power-system description may each be internally consistent yet disagree at their boundary. Ask the assistant to compare parameter meaning, units, operating mode, limits, measurement location and document revision. Include the owners' open questions so that an unresolved negotiation does not appear to be an approved agreement.
NASA's interface-management process addresses compatibility and responsibility across boundaries. The assistant's deliverable is a discrepancy list that both sides can resolve. It should not select whichever value appears most recently and silently replace the other side's obligation.
6. Evidence preparation: make omissions inspectable
Define the review's scope and entry criteria, then ask for an index connecting each required claim to an accessible record. Include identifiers, revisions, approval status, applicability and the exact location of the supporting result. Put missing evidence and unresolved anomalies beside the claims they affect.
An agent may draft a coherent review narrative from that index. The evidence owner should still open the referenced records and check that they support the narrative. An approved plan shows what the team intended to do; an execution log shows what happened; an accepted result records a disposition. Combining them into a single “complete” status hides useful distinctions.
Worked example: a payload power change from request to disposition
Fictional training example. Consider a 6U Earth-observation CubeSat at baseline BL-03. Requirement PAY-PWR-014 revision B limits payload peak power to 20 W. The current design uses 18 W. A proposal raises that design value to 24 W. Interface ICD-EPS-PAY-02 and verification activity VER-PWR-07 are the associated records in this example. None of these identifiers or numbers describes a customer programme.
Step 1: establish the comparison. The requester gives the agent a read-only task: prepare an impact note for the proposed 18 W to 24 W change against BL-03. The agent retrieves PAY-PWR-014 revision B and confirms that the applicable cap remains 20 W. It records the difference between an unchanged requirement and a proposed design change. It does not “fix” the conflict by raising the requirement.
Step 2: perform a transparent calculation. The proposed increase is 24 W minus 18 W, or 6 W. Assuming the relevant programme power margin is currently positive 5 W and all other quantities stay fixed in the same operating condition, the revised margin is 5 W minus 6 W, or negative 1 W. Separately, the proposed payload exceeds its requirement cap by 4 W. These are two different findings.
Step 3: follow the engineering consequences. The agent identifies ICD-EPS-PAY-02 for electrical power-system and payload-owner review. It identifies VER-PWR-07 because its setup and acceptance logic must be checked against any eventual approved configuration. It asks for evidence about duty cycle, transient behaviour, measurement boundaries and relevant thermal effects. The simple calculation neither answers those questions nor establishes that they are irrelevant.
Step 4: present a reviewable output. The note states the baseline, proposed difference, two numerical findings, cited record locations and outstanding questions. Its recommendation is to withhold change acceptance pending a feasible technical disposition. Options to investigate include retaining the existing design, reducing power elsewhere with supporting analysis, or changing the operating concept. None is declared feasible without evidence.
Step 5: record the human decision. In this worked outcome, the responsible authority returns the proposal for rework. The programme retains BL-03 and the 20 W cap. The returned note assigns follow-up analysis to the relevant roles and records why the proposal was not accepted. A later option would receive a new comparison and review. The agent has completed useful work even though no baseline changed.
Reusable output template: state the question and baseline; identify the proposed change; list confirmed findings with record revisions; separate calculations from assumptions; list unresolved dependencies; identify review owners; record the requested decision. Tailor these fields to the programme rather than treating the example as an approval form mandated by a standard.
Measure engineering usefulness at the handover
Evaluate a workflow with examples that include genuine issues, clean records and insufficient information. Check whether findings are correct, whether important issues were missed and how much effort reviewers spent resolving unnecessary suggestions. Record errors in identifiers and revision selection separately from errors in engineering interpretation. Those failures require different remedies.
For an impact task, an attractive prose summary matters less than finding the right constraint and exposing a missing dependency. For evidence preparation, invented support is more serious than an awkward sentence. NIST's Generative AI Profile recommends checking generated sources and avoiding broad conclusions from narrow assessments. Pilot results should therefore describe the tested workflow and its limits.
How these workflows connect to Arc
Arc's read-only and drafting agents can surface context, check programme records and propose work within configured permissions. Its bidirectional traceability exposes engineering context affected by requirement or interface changes. These capabilities provide a practical place to review a finding alongside the records it concerns.
Arc also connects verification planning, execution, results and evidence to requirements and configurations. The six examples explain possible working patterns around that context. Their suitability depends on the programme's data and configured permissions, and engineers retain responsibility for technical conclusions and controlled changes.
Frequently asked questions
Which systems engineering task is a sensible first AI agent use case?
A bounded review of known requirements or preparation of an evidence index is often easier to assess than a broad design task. Choose a workflow with accessible revisions, an engineer-reviewed reference and a clear owner for every finding.
Do all six workflows require an autonomous agent?
No. Fixed checks, conventional queries and a single retrieval-assisted response may cover much of the work. An agent is useful where the required searches depend on what earlier searches reveal, provided its tools and stopping conditions are controlled.
Can an AI-generated trace link be counted as approved coverage?
Only after the programme accepts the relationship through its review process. A candidate link should identify its source and target revisions, relation type and rationale; its existence does not prove that a requirement is satisfied.
Does a power-budget calculation verify a payload requirement?
It may support a specific analysis objective if the programme accepts the method and its assumptions. A preliminary arithmetic check alone does not establish electrical compatibility, test validity or requirement closure.
What should an agent do when an important record is unavailable?
Identify the missing record and the conclusions that depend on it, then stop or return a partial result according to the task contract. It should not interpret a permission restriction or retrieval failure as proof that no affected item exists.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.