AI agents, copilots and automation describe different aspects of engineering software. Automation can follow fixed rules; an agent can choose its next permitted step from what it discovers; a copilot describes how a person interacts with assistance. The categories overlap. Choose by the task’s uncertainty, evidence needs and action rights, then evaluate the output against the same engineering review standard.
A space team selecting software should ask what happens after a payload engineer submits a change, not whether the product uses the most ambitious label. Will the system run known checks, help an engineer investigate interactively, or investigate through several permitted steps itself? Can it only read, can it draft, or can it alter controlled records? Those questions reveal the operating model and the work left for reviewers.
Use definitions that describe observable behaviour
For this article, conventional automation means a repeatable process whose steps and rules are specified in advance. Examples include checking that every requirement has an owner, detecting a missing unit or generating a matrix from recorded links. A predefined AI workflow may also contain language-model calls, such as classifying a comment before routing it. Fixed orchestration does not require every individual output to be deterministic.
Anthropic’s engineering article distinguishes workflows with predefined code paths from agents whose models dynamically direct their process and tool use. That is a useful architectural distinction, not a universal engineering taxonomy. It tells us how the work proceeds; it does not say who has authority to approve the result.
Copilot is used here for an interaction style in which a person works alongside assistance, asking questions, examining suggestions and steering the next step. A copilot may retrieve a document once, invoke a fixed workflow or start an agent that follows several leads. An agent can therefore sit inside a copilot experience. Treating them as mutually exclusive product classes obscures how a real implementation behaves.
Keep execution flexibility separate from action rights. A read-only agent can investigate flexibly without changing anything. A nightly deterministic import can overwrite important records if its permissions allow that. The engineering consequence comes from the actual operation and its destination, not from whether the software is described as autonomous or intelligent.
Give all three approaches the same task
Fictional 6U Earth-observation CubeSat example. At BL-03, PAY-PWR-014 revision B caps payload peak power at 20 W. The present design estimate is 18 W; a proposal raises it to 24 W. Draft revision C has not been approved. The payload and electrical power system share ICD-EPS-PAY-02, and VER-PWR-07 is the relevant verification activity.
The assignment is to prepare an initial impact note. Its required contents are the applicable baseline, immediate requirement conflict, simple budget consequence, affected records and unresolved questions. All three approaches get the same accessible inputs and a read-only permission boundary. None may raise the cap, accept revision C or mark verification complete.
Assume an illustrative instantaneous programme power margin of 5 W before the change. With all other quantities fixed in the same condition, the 6 W demand increase changes that margin to negative 1 W. Separately, 24 W exceeds the 20 W cap by 4 W. These calculations belong in the common expected output. They do not establish that duty cycle, battery energy or transient effects have been analysed.
Approach one: a fixed workflow runs known checks
A fixed workflow retrieves the named baseline and compares the proposed design value with the applicable limit. It calculates the two differences, follows a predefined set of relationships and returns a report listing the interface and verification activity. It can also check whether the change package contains an operating mode, source revision and assigned owner.
This is a strong fit when the question and available data are structured. The team knows which comparisons must occur and can define what happens when an input is absent. A failed retrieval can produce a visible incomplete status. A missing unit can stop the numerical comparison. There is no benefit in asking a language model to improvise an arithmetic rule that the programme already understands.
The boundary appears when the important dependency is not in the predefined path. A supplier note might say that the new demand occurs only during an imaging mode whose name differs from the programme vocabulary. Unless the workflow accounts for that interpretation, it may list the note without recognising its significance. The report should state its checked scope so reviewers can see what remains outside it.
The deliverable can still be sufficient. If the team wants a repeatable first-pass completeness and limit check before an engineer performs the impact assessment, fixed automation may cover the need. Its success criterion is reliable execution of the defined checks, with transparent exceptions and a useful handoff.
Approach two: a copilot helps an engineer investigate
The engineer opens the proposal and asks for a comparison with BL-03. The copilot returns the two numerical findings with source references. The engineer then asks to inspect the power interface, sees an unresolved definition of peak measurement duration and directs the assistant to retrieve the corresponding supplier description.
Here the engineer supplies much of the investigation strategy. They can correct a misunderstanding early, add context that is not yet recorded and decide whether a search result deserves attention. The interaction may be particularly useful for a novel interface or a trade whose technical question is still being formed.
The cost is the engineer’s continuing attention. A sequence of short requests can create useful analysis, but someone must preserve the agreed scope and collect the supporting evidence into a coherent output. A conversation alone is an awkward engineering record if the final note does not identify which sources, revisions and assumptions actually support the conclusion.
Require the same impact-note structure used by the fixed workflow. The final deliverable should not depend on remembering the conversation. If the copilot used an adaptive agent internally to search the supplier material, disclose the resulting evidence and limitations in the note; the interface label does not remove the need to understand that behaviour.
Approach three: an agent chooses bounded follow-up steps
The agent receives the full assignment and a small set of permitted tools. It begins with the baseline comparison, follows the interface reference, notices the missing measurement-duration definition and looks for an approved source that resolves it. It may inspect the verification activity to determine whether the planned procedure uses the same definition.
Its path depends on what it discovers. The user does not have to request each lookup, but the task still needs boundaries. Set a permitted record scope, a maximum investigation budget and conditions for returning a partial result. If the supplier source is inaccessible, the agent should identify the missing dependency and explain which conclusion remains unresolved.
The final note combines confirmed conflicts, the applicable records and questions for the electrical, payload and verification owners. It can complete the task by saying that feasibility has not been established. Completing an investigation is different from accepting the proposed design. The agent should not keep searching merely to produce an affirmative answer.
Adaptive execution adds another evaluation concern: the route can vary. Reviewers need to see what was actually retrieved and checked, and the team needs examples that reveal missed dependencies or unproductive loops. If a simpler workflow repeatedly reaches an equally useful note with less review effort, the adaptive path has not yet justified its additional operating complexity.
Choose using the engineering task, not the label
| Task condition | Useful starting approach | Why | What to inspect |
|---|---|---|---|
| Known fields and fixed acceptance rules | Conventional automation | Explicit checks can be repeated consistently | Inputs, exceptions and rule coverage |
| Fixed sequence with a text-interpretation step | Predefined AI workflow | Language assistance fits inside a bounded route | Classification errors and downstream routing |
| Engineer is still defining the question | Interactive copilot | Frequent steering can resolve ambiguity early | Evidence retained from the conversation |
| Follow-up searches depend on discoveries | Bounded adaptive agent | The investigation path cannot be fully listed upfront | Search scope, missed paths and stopping behaviour |
| Controlled baseline change | Programme approval workflow around any approach | Execution style does not confer engineering authority | Reviewed revision, decision and permitted write |
Most useful implementations combine these approaches. A fixed rule identifies the power conflict, an agent prepares related context, and an engineer uses a copilot to examine a disputed assumption. The approved change then follows a controlled workflow. Decomposing the task this way lets each component have a narrow purpose and a measurable contribution.
Evaluate authority and quality independently
NASA’s configuration-management guidance describes proposed changes being justified, evaluated and incorporated after approval. Applied here, a useful control records the exact material reviewed before any accepted update reaches the baseline. Enforce that boundary in permissions and workflow state, not solely in a prompt telling the assistant to be careful.
Evaluate each approach on the same representative cases. Include a straightforward change, a stale export, a missing supplier record and a contradiction between a draft and an approved requirement. Define expected findings with responsible engineers before comparing outputs. Record missed issues, unsupported conclusions, false alarms and the time needed to reach a usable review package.
The NIST Generative AI Profile discusses risks including confabulation and human-AI interaction. In this evaluation, a plausible but unsupported explanation is a failure even if the final arithmetic happens to be correct. Review effort also matters: an output that creates many low-value findings can consume more attention than it saves.
Repeat the relevant cases after changing the model, retrieval configuration, tool permissions or workflow rules. Keep the evidence needed to explain a regression. Do not treat a successful demonstration on the clean CubeSat example as proof that the system understands every spacecraft interface or can safely execute a broader assignment.
How to assess these patterns in Arc
Arc’s public reference describes agents that work within configured permissions and reviewed changes before baseline merge. Use those as concrete evaluation points: inspect the proposed work, accessible context and approval boundary.
Ask a prospective setup to produce the common impact note, then examine the evidence and the engineering effort required to disposition it. The comparison does not assume that every described workflow is preconfigured in Arc. For additional task definitions, read six practical systems-engineering workflows; for the surrounding review process, use human-in-the-loop systems engineering.
Frequently asked questions
Is a copilot always less autonomous than an agent?
No. Copilot often describes an interface where a person works interactively with assistance. Behind that interface, the software may run fixed steps or an adaptive agent. Inspect the execution behaviour and permitted actions instead of inferring them from the product name.
Can conventional automation change an engineering baseline?
It can if its account and workflow are authorised to do so. Fixed execution does not imply low consequence. Review write permissions and approval rules for all software, including scheduled imports and conventional scripts.
When is an adaptive agent useful for engineering work?
It can be useful when the next information-gathering step depends on what the previous step discovers, such as following an unexpected interface dependency. The task still needs accessible evidence, constrained tools, a stopping condition and a reviewable deliverable.
Should a language model calculate engineering margins?
Use an established calculation method or a transparent deterministic calculation with identified inputs, units and assumptions. AI can help assemble inputs and explain a result, but the reviewer needs evidence of the operation actually performed and its limitations.
How can a team compare a copilot and an agent fairly?
Give each approach the same record scope, baseline, task and expected output. Measure missed issues, unsupported claims, false alarms and total engineering review effort. Include stale sources, unavailable records and contradictory revisions, not only clean examples.
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.