Agentic systems engineering uses AI agents to carry out bounded, multi-step engineering tasks with access to programme information and tools. For a hardware team, that might mean investigating a proposed payload change, finding affected interfaces and preparing a review package. The defining feature is adaptive task execution; responsibility for the spacecraft design, evidence and approved baseline stays with authorised engineers.
The term needs a practical boundary. This guide concerns agents assisting the people who engineer a system. It does not describe an onboard autonomous spacecraft, and it does not assume an AI system can take over a technical authority role. A useful implementation has a specific assignment, a limited set of actions and an outcome another engineer can inspect. Without those, the word agent tells a team little about the work or its consequences.
What makes an engineering workflow agentic?
Suppose a systems engineer asks for the likely effects of changing a payload power demand. A conventional report runs a known query and lists directly linked records. An agent may begin with that query, notice a reference to an electrical interface, retrieve the applicable interface revision, discover an unresolved operating-mode assumption and ask for it before proceeding. Its next step depends on the result of the previous step, within the tools and permissions the application provides.
This architectural distinction comes from AI engineering literature. Anthropic distinguishes predefined workflows from agents that choose their process and tool use dynamically. Its article also recommends adding complexity only when needed and limiting agent execution with stopping conditions. Those are AI implementation concepts. NASA's systems-engineering handbook is a source for engineering process, not the origin of this agent taxonomy.
Three choices therefore deserve separate answers: which engineering task needs assistance, how flexible the execution needs to be, and what changes the software may make. An adaptive investigator can have read-only access. A deterministic import can have substantial write access. Calling the former more autonomous does not make the latter less consequential. Evaluate action rights directly rather than inferring them from a product label or a maturity score.
For a fuller comparison of the interaction patterns, read AI agents, copilots and automation in systems engineering. Here the focus is the architecture required to make a bounded engineering assignment useful and reviewable.
Why hardware context changes the design of an agent
An engineering record has more meaning than its text. The same requirement identifier can appear in an approved baseline, a proposed revision and a supplier export created several weeks earlier. A power value may describe a peak, an orbital average, a design estimate or a measured result. A test may be relevant to the subsystem but belong to another hardware build. An agent that ignores those distinctions can give a coherent answer assembled from incompatible facts.
Hardware decisions also travel across organisational boundaries. The payload owner may propose a change but lack authority to reallocate spacecraft power. The electrical lead may accept a load but need input from thermal and operations teams. The test team may need to revise a procedure before the new design can be verified. The task is to expose those dependencies with enough context for a decision, rather than to make the records appear internally tidy.
NASA's technical-management guidance connects requirements management with traceability and baseline change evaluation. Applying that discipline to an agent means identifying the authoritative record set before analysing it. The practical controls below are our proposed implementation, tailored for engineering review; they are not a NASA-prescribed AI architecture.
A reference architecture for reviewable engineering work
Begin with six responsibilities. They can live in one application or several connected services. What matters is that each has a clear contract and can fail visibly. Treating all six as an unstructured prompt makes it difficult to tell whether a bad answer came from missing data, poor interpretation, an unsafe tool or a stale review.
| Responsibility | What it must establish | Concrete failure to prevent |
|---|---|---|
| Task definition | Question, permitted scope, deliverable and stop conditions | Investigating adjacent work indefinitely |
| Context retrieval | Record identities, revisions, relationships and access rights | Mixing approved and proposed configurations |
| Task execution | Allowed next steps and recorded tool results | Presenting a guessed result as a completed check |
| Tool boundary | Validated inputs, narrow actions and explicit errors | Turning a draft request into an authoritative update |
| Proposal assembly | Findings, source references, differences and unknowns | Burying assumptions inside persuasive prose |
| Review and recording | Human disposition tied to the material actually reviewed | Applying approval to a later, changed proposal |
Context retrieval should return both the content and its status. A useful result says that PAY-PWR-014 revision B belongs to baseline BL-03, while revision C is a proposal outside that baseline. It should also preserve the relationship being followed. A requirement that allocates power and a test that verifies power are different kinds of evidence. Semantic search can find a candidate document; the record system needs to establish whether it is the applicable document.
The execution component selects work, but the tool boundary determines what can happen. Give a review agent a way to retrieve a requirement or prepare a proposed link, rather than a general-purpose update operation that accepts arbitrary fields. Validate record identifiers, allowable states and write destinations. If a source is unavailable, return an explicit unavailable result. An empty successful response and a permission failure must not become the same conclusion that no relevant evidence exists.
Calculations should have their own observable inputs and outputs. If an established power-budget tool is available, record the configuration, units and assumptions submitted to it and the result it returned. If only a simple arithmetic illustration is being performed, label it accordingly. Language that sounds like an engineering analysis does not substitute for running the analysis. The reviewer should be able to reproduce the numerical step without trusting a narrative explanation of what the agent supposedly did.
Keep execution history useful to reviewers. They need the records consulted, relevant tool results, rejected sources, proposed changes and unresolved questions. They do not need a speculative transcript of the model's internal reasoning. Store a concise evidence trail that supports or limits each claim, and retain enough configuration information to investigate a bad output after the model, connector or programme record has changed.
Worked example: a payload power-change investigation
Fictional engineering example. Consider a 6U Earth-observation CubeSat. A payload design change increases its estimated peak electrical power from 18 W to 24 W at unchanged duty cycle. The approved allocation caps payload demand at 20 W. Requirement PAY-PWR-014 revision B belongs to BL-03; the proposal refers to revision C. The connected electrical interface is ICD-EPS-PAY-02 and the verification activity is VER-PWR-07. These identifiers and numbers describe an illustrative programme, not an Arc customer.
The request to the agent is narrow: prepare an initial impact note for the payload change. It may read BL-03 and the proposed change package, follow relevant links and draft findings. It may not change the payload allocation, accept the proposal or close verification. Completion means producing a reviewable note, even when that note concludes that critical analysis is missing.
- Resolve the record state. Retrieve revision B from BL-03 and keep revision C marked proposed. Identify the 20 W allocation as a requirement limit and 18 W as the prior design estimate, rather than treating those two numbers as competing versions of one fact.
- Check the immediate conflict. The proposed 24 W demand exceeds the 20 W cap by 4 W. That finding is supported by the two stated inputs. It is not authority to increase the cap.
- Expose the budget consequence. In an illustrative instantaneous power balance, the starting positive margin is 5 W. The additional 6 W makes that margin -1 W, all else fixed. This is arithmetic within the example, not a complete orbital energy or battery analysis.
- Follow affected context. Retrieve ICD-EPS-PAY-02 and VER-PWR-07. Ask the relevant owners to assess supply capability, applicable operating modes and whether existing verification remains relevant. Do not infer a thermal limit or battery result from the power delta alone.
- Return a proposal for review. Present the conflict, calculation, consulted revisions, missing analyses and suggested reviewers. Keep revision C outside the baseline while the engineers consider redesign, operational changes or a justified allocation change.
Unchanged duty cycle helps specify the proposal, but it does not make the power problem disappear. Peak supply capability and energy over an orbit are separate questions. A full assessment would require the programme's operating-mode timeline, generation assumptions, storage model and other loads. The agent should request or reference those inputs before making broader claims. It should also distinguish an absent analysis from a known adverse result.
The most useful output may be a short unresolved question: does the current electrical-interface record include the proposed payload operating mode? That question points to a concrete owner and decision. A long list of every spacecraft requirement, by comparison, pushes the investigation back onto the engineer. Review quality depends on the relevance and completeness of the affected set, not the number of records the agent can retrieve.
Reusable asset: an engineering-agent task contract
Write the assignment before choosing a model or adding tools. The following contract can be copied into a pilot brief and tailored to the organisation. It defines expected behaviour, not a certification scheme. Every field should be understandable to the engineer who will judge the result and the administrator who will configure access.
| Contract field | Example value for the fictional review |
|---|---|
| Purpose | Prepare an initial impact note for the payload peak-power proposal |
| Authoritative context | BL-03, PAY-PWR-014 revision B and applicable linked records; revision C clearly separated |
| Permitted actions | Read approved scope, follow relevant links, compare values and draft a proposal |
| Excluded actions | Approve changes, merge baselines, reallocate budgets or close verification |
| Required output | Source-backed findings, proposed affected set, assumptions, missing evidence and reviewer roles |
| Stop and escalate | Conflicting baseline identity, unavailable decisive source, permission boundary or exhausted execution limit |
| Review rule | Authorised engineer dispositions the exact proposal and records accepted, revised or rejected findings |
| Success evidence | Comparison with an engineer-reviewed reference case, including misses and correction effort |
Add a freshness rule. If BL-03 or an applicable interface changes while the investigation is running, the proposal should identify that its context has changed and require reconciliation before use. Repeating the entire task may be unnecessary; the team can inspect which findings depend on the changed records. The key is to prevent an approval from silently attaching to a different set of engineering facts.
Specify how the agent ends an incomplete task. A bounded result might say that it inspected the requirement and interface but could not retrieve the approved verification procedure. That is reviewable. Repeatedly searching other repositories until it finds a plausible replacement is a different action with different permission and applicability questions. Time and tool-call limits should end in an honest partial report, not a forced conclusion.
Evaluate the engineering result and the control boundary
The NIST Generative AI Profile describes confabulation, including unreliable answers and supporting citations, as a model risk. For this workflow, translate that concern into observable cases: a fabricated interface reference, a correct value drawn from the wrong revision, a claimed calculation with no tool result, or a proposed status change unsupported by evidence.
Use a reference set that contains both straightforward tasks and inconvenient cases. Include an unrelated requirement with similar wording, a missing interface, a withdrawn proposal, contradictory units and a document containing instructions to ignore the review boundary. The last case tests whether retrieved document text stays evidence to inspect instead of becoming authority to expand the task. Expected behaviour includes recognising uncertainty and refusing unavailable actions, not merely finding defects.
Measure correct findings, missed material effects, false alarms and the effort required to validate the report. Record unauthorised attempted actions separately from writing quality. A polished summary with one missed allocation breach should not pass because most sentences are correct. Conversely, an agent that abstains whenever the data is inconvenient may have few false claims while being of little practical use. Evaluate usefulness and restraint together, with acceptance criteria chosen before the pilot.
Review the human workflow too. Can the engineer open the cited revision, see the proposed difference and reject one suggestion without losing the rest? Does rejecting a suggestion require more effort than accepting it? Can a reviewer see why an affected record was included? A nominal approval button provides weak control if the evidence needed to make the decision is difficult to inspect. The companion guide to human review in AI-assisted systems engineering develops that operating model.
How this approach relates to Arc
Arc documents a connected programme model and human-controlled agents that read, check, draft and propose within configured permissions. Its change-control capability supports reviewing differences before baseline changes. These capabilities provide relevant foundations for the pattern described here.
Use the fictional payload case as an evaluation brief: ask which records the proposed setup reads, where draft work appears, how permissions are enforced and what the engineer reviews. Confirm any analysis-tool connection for the intended deployment. The article's six-part architecture is a design proposal for assessment, not a claim that every step is a preconfigured Arc workflow.
A sensible first assignment ends with better engineering context in a person's hands. Once the team can inspect the sources, reproduce the checks and disposition the proposal reliably, it has evidence for deciding whether a broader task is worthwhile. For other bounded assignments across spacecraft development, continue with systems-engineering use cases for AI agents.
Frequently asked questions
What does agentic systems engineering mean?
It means using AI systems that can select and sequence permitted steps in a systems-engineering task, respond to tool results and prepare a reviewable outcome. In this guide, the agent helps with engineering work while authorised people retain responsibility for baseline, design and verification decisions.
Does an engineering agent need permission to edit the baseline?
A read-only agent can already gather affected context and identify gaps. Drafting can be added in a separate proposal area. Controlled baseline changes should pass through the programme’s established review and approval route, with permissions enforced outside the model.
How is an agent different from an automated checklist?
A checklist follows predetermined checks. An agent can choose its next permitted step from what it finds, such as retrieving an interface after discovering an electrical dependency. Fixed rules remain a useful choice for known checks, including mandatory fields and numeric limits.
Is a digital twin required for agentic systems engineering?
No. A bounded agent can work with revision-controlled requirements, interfaces, verification records and approved analysis outputs. A simulation may be useful for a particular task, but permission to read records does not establish that a physical model is available or validated.
What should the first pilot produce?
Choose a repeatable review task and require an evidence-linked draft with its scope, source revisions, findings and unresolved questions. Compare the whole review workflow with the current process, including missed issues, false alarms and engineer correction effort.
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.