How We Built Zelda: An AI Agent That Saves Hardware Engineers Hours of Manual Requirements Work
Engineers who build complex systems often spend hours keeping track of requirements. We created Stell to relieve that burden, and we believe AI can free up time for engineers to focus on work that actually requires human judgment.
That’s why, when we set out to build our AI agent, Zelda, we avoided integrating AI features arbitrarily and without clear purpose. We instead prioritized security; human oversight and verification; and a single, well-engineered interface. Read more about how Stell thinks about AI here.
Our goal is not to replace engineers. Requirements management has been manual, tedious, and error-prone for decades. AI can change that, but only if built carefully, with real respect for the data our customers trust us with.
An Interface Designed for an Agent
Stell already has a UI for human users to interact with their requirements data—but the experience is optimized for human navigation, not an AI model.
So we built a different layer.
For our traditional UI, the stack is:
Data → API → UI
For Zelda, it’s:
Data → API → tools → agent
The tools are essentially the equivalent of UI components, but designed for a Large Language Model (LLM) to use effectively.
An AI-friendly interface means Zelda operates within the same access controls as a human user. If someone logged into Stell can't access a certain program, Zelda can't either. There are no backdoors or special agent privileges; Zelda operates within the same security boundaries as the user.
How We Reduced Slop
LLMs will always attempt to respond to a prompt, even if the model lacks sufficient context to be accurate or helpful. This creates a problem when building an agent that can write to a production system.
With this in mind, we established a rule: If the model does not have what it needs to produce something useful, we do not let it try.
Early on, we considered having Zelda generate evidence record titles that suggest how an engineer would verify a requirement has been met. If the requirement says, “The engine shall withstand 10,000 degrees F,” the verification may be a hot fire test. However, LLMs don’t currently have the domain expertise to come to that conclusion today. Knowing this, we declined to build that feature. We would rather ship fewer capabilities that actually work than more capabilities that do not create real value.
What Zelda Can Actually Do Today
Zelda has access to everything a user does inside Stell. Using this context, Zelda’s capabilities generally fall into two categories: read actions and write actions.
Read actions
These actions retrieve and analyze information. Zelda can search across programs, filter by risk level or compliance status, and navigate parent-child relationships between requirements. Ask it questions like:
Can you show me all high-risk requirements that aren't compliant in this program?
Which requirements in this specification have no linked verification evidence?
Are there any missing parent/child links between these two specifications?
Write actions
Zelda executes actions on a user’s behalf, and can make real changes to requirements.
Since this is more consequential than a read action—and can have serious impacts on program compliance—we implemented permission gating. Zelda explains what it plans to do, and does not act until a user approves that action. It’s akin to working with a junior engineer who needs sign-off before making changes to the system of record.
Engineers can use Zelda to:
Create and delete requirement links (traceability between parent and child requirements)
Classify requirements by type (functional, performance, design, etc.), compliance status, and risk level
Author and manage requirements
Create and update evidence records
Some example prompts include:
Create a new power requirement under REQ-2.1 with a shall statement for maximum current draw during peak load
Create an evidence record for REQ-8.2, attach the thermal vacuum test report, and mark it as Test
Help me find and create parent links for the orphaned requirements in this specification.
A Real Example
A customer needed to link hundreds of requirements to their respective top-level and subsystem specifications. This is paramount for establishing traceability and maintaining compliance across the entire system.
Traditionally, this is tedious work. Engineers map out every link in an Excel spreadsheet, then manually create each entry in their requirements management system. This process typically takes hours for hundreds of links.
Instead, the customer provided the Excel sheet to Zelda. "Create all these links between the requirements from specification A and specification B."
Zelda read the spreadsheet, parsed the relationships, requested permission to create the links, and executed. After a single week with Zelda, the customer saved eight hours of manual work.
We’re not interested in false promises of AI magic—just taking the tedious parts of requirements management and making them disappear.
How We Handle Your Data
Data security is essential for aerospace and defense customers who operate under strict data handling requirements.
Zelda runs in AWS GovCloud’s FedRAMP High environment, the same security boundary as our main software product. When a user asks Zelda a question, the data is processed within AWS GovCloud, not an external service.
More importantly: Stell does not train on user data. The frontier model powering Zelda does not retain any requirements, specifications, or conversations, nor does it use any user data to improve its own models.
Where We're Heading
At present, a person logged into Stell can do more than Zelda can. That is an intentional engineering and design decision to enhance both security and usefulness.
In the future, we intend to expand Zelda’s interface. The agent will have access to more of the rich data model and business logic we’ve already built, supported by our agentic scaffolding for managing context and calling tools.
This will be accomplished iteratively, driven by customer need and feedback.
