Post Syndicated from Aleksandar Matic original https://aws.amazon.com/blogs/devops/here-technologies-and-aws-accelerating-nds-live-with-agentic-ai/

NDS.Live development at HERE Technologies demands that dozens of interdependent schema definitions stay consistent with every customer requirement, and agentic AI is how we’re meeting that challenge. HERE’s mission is to deliver a unified map for our automotive customers, and central to this mission is the Navigation Data Standard (NDS). NDS is the global industry standard for map data formats. Major manufacturers like BMW and Volkswagen use it so that navigation, Advanced Driver Assistance Systems (ADAS), and automated driving systems speak the same language.

While NDS Classic focused on batch delivery for offline storage, the industry has shifted toward NDS.Live, a streaming-first standard. With NDS.Live, vehicles can pull high-definition map updates in real time through APIs. This transition significantly increases the burden on our Software Development Life Cycle (SDLC). Our map data delivery teams must now manage dozens of interdependent schema definitions. Teams must translate every customer requirement into precise engineering tasks with 100 percent architectural consistency.

Adding to the challenge, the automotive industry demands rigorous process compliance. Automotive SPICE (ASPICE), the process assessment model used across the industry, requires bidirectional traceability between system requirements, software requirements, and implementation artifacts. When teams create ticket hierarchies manually and inconsistently, demonstrating this traceability during audits becomes costly and labor-intensive. That effort diverts engineering time from product delivery.

Currently, product requirements arrive as high-level feature descriptions. Manually decomposing these into a structured Jira hierarchy is time-consuming and inconsistent across teams. That hierarchy runs from Product Requirement to Epic to Story to Task. Critical domain knowledge is often fragmented across repositories or stored only in the minds of senior architects. Specifically, the relationship between HERE’s internal source data models and the output NDS.Live schemas lacks a single source of truth. This context switching leads to structural errors in tickets, creating a quality bottleneck right before release.

The solution: An orchestrated multi-agent approach with Kiro

To address this, we’re proving the viability of an orchestrated, multi-agent approach built on Kiro. Kiro is a software engineering agent from AWS, available as an IDE, CLI, or web agent. Using Kiro, you can formalize technical requirements and system designs before any code is generated, using its spec-driven development model.

Why orchestration?

Rather than using a single, general-purpose AI assistant, we chose an orchestration model that mimics a high-performing engineering team. In complex systems, a single agent can suffer from context window saturation, where too much information leads to hallucinations or missed details. We use a Kiro workflow that routes specialized work to purpose-built step agents. Each step runs with exactly the context it needs, and the workflow sequences and parallelizes them rather than relying on one general-purpose agent to coordinate every sub-step. Each step agent is dedicated to one role. Six persona agents analyze each requirement in parallel: an Architect, a Product Owner, a Tech Lead, a Developer, a Quality Assurance (QA) Engineer, and a Data Modeler. Specialist agents then handle each ticket type.

Using Kiro powers

The core of this system is the Kiro power, a packaged capability that follows the open Agent Plugins format. Agent Plugins is a vendor-neutral specification, so powers built for Kiro also work across other compatible agent clients. With a Kiro power, you can give the AI agent instant expertise in a specific domain by bundling several elements:

1. Agent Skills: Task-specific instructions, scripts, and reference material that define conventions and guidelines, such as coding standards or architectural constraints. Skills load on demand, so the agent sees only the skill name and its activation trigger until a task needs it.
2. Model Context Protocol (MCP) servers: Connecting the agent to live data, such as Jira or HERE’s internal technical schema servers.

Automation with Kiro CLI

Developers work inside the Kiro IDE while writing code. This initiative needed automation that runs without a developer present, so we used the Kiro Command Line Interface (Kiro CLI). By using the CLI, we can integrate the agentic workflow directly into our continuous integration and continuous delivery (CI/CD) pipelines. A system event, like a Jira webhook, can automatically trigger the transition from a product requirement to a structured Jira backlog. No developer needs to manually coordinate every sub-step.

Multi-source context injection

We ground our agents in our specific domain using multiple methods:

• Internal MCP servers: These connect Kiro to live internal knowledge graphs, allowing agents to verify if the source data actually exists before committing to a design in NDS.Live. Additionally, they support alignment with internal architecture and system non-functional requirements.
• Kiro CLI knowledge indexing: This provides the agent with on-demand, token-efficient access to the thousands of pages of NDS.Live documentation.
• Code Intelligence: The built-in code understanding layer in Kiro indexes our repositories, supporting natural-language queries against the actual source code during ticket creation.

Persistent wiki memory

A significant challenge in agentic workflows is context loss between sessions. When a developer returns to a task days later, the AI assistant starts from scratch. It must re-learn project nuances, user preferences, and prior decisions. We addressed this by implementing a three-layer memory system inspired by cognitive science:

1. Semantic memory: Stored facts about the domain, including entity definitions, component relationships, and user preferences. The system remembers which Jira fields map to which schema concepts. It also remembers working preferences, such as a developer’s preferred diagram format for architecture documentation.
2. Episodic memory: Records of past sessions, capturing decisions, discoveries, and open items. When a new ticket references a component discussed three weeks ago, the agent recalls the architectural context from that earlier interaction without the developer repeating it.
3. Procedural memory: Learned workflows and task instructions that improve with each execution. When the agent encounters a pattern it has successfully executed before (such as evaluating a milestone against its test plan), it replays that procedure with increasing confidence.

This memory lifecycle is fully automated through Kiro hooks. A record-episode hook fires at the end of each meaningful session and distills the interaction into structured knowledge. A recall-memory hook loads relevant prior context at the start of every new interaction. The result: the AI agent compounds expertise over time, much like a new team member who gets better with each sprint.

Code Intelligence for architecture-aware tickets

Beyond documentation, our agents need to understand the actual implementation. Using the Code Intelligence feature in Kiro, we clone any relevant repository, index its source code, and make it queryable in natural language. Consider a task to “add error handling to the registry service.” The system does not guess at the current patterns. Instead, it queries the indexed code base: “What error handling patterns does this service currently use?” It then writes acceptance criteria that align with the real architecture.

This bridging of documentation and source code is critical. Tickets grounded in actual code patterns are accepted by developers with fewer revision cycles. The AI’s recommendations match existing code base conventions rather than imposing generic best practices.

Concrete outcomes and impact

By moving from manual decomposition to AI orchestration, we have transformed our ticket creation process. In our internal use to date, work that previously took hours or days of manual decomposition is completed in minutes.

The following diagram illustrates a typical output from the orchestrated workflow. A single high-level product requirement is automatically decomposed into a fully linked hierarchy. Each level inherits architectural context from the one above. Every ticket arrives with precise acceptance criteria grounded in the NDS.Live schema and verified against the source data model.

Key observations from this example: (1) Each ticket inherits the speed-limit label and architecture context from its parent. (2) Source data availability is verified at the Epic level. (3) Stories referencing implementation details are enriched through Code Intelligence queries against the actual repository. (4) QA stories are cross-referenced with the team’s test plan. In our runs, this consistency is produced in minutes rather than the days the manual process required.

Key results

Since adopting the orchestrated workflow, we have seen changes across five areas:

• Efficiency gains: Based on our initial internal measurements, we expect to decrease the investigation phase for new implementation tasks by more than 50 percent. This is a vital step toward HERE’s company-level goal to reduce developer toil.
• Born correct workflows: Every ticket is structurally sound, consistently named, and properly linked from the moment of creation. This significantly eases the backlog refinement process.
• Support for ASPICE traceability: The orchestrated workflow enforces parent-child linking and consistent labeling from the moment of creation. The resulting ticket hierarchy can help support ASPICE bidirectional traceability efforts, with linked artifacts produced as work is created rather than reconstructed before an audit. Adopting the workflow doesn’t replace a formal process assessment. Each organization remains responsible for validating outcomes against its own ASPICE assessment, and we recommend confirming the approach with your compliance team.
• Architecture-aware scoping: Before any tickets are generated, the system automatically assesses the architectural impact of a feature, identifying which components, services, and teams are affected. This early architecture consultation surfaces the true complexity and scope of a requirement upfront. It prevents the costly mid-sprint discovery that a seemingly minor feature actually touches five services across three teams.
• Knowledge persistence: The domain expertise of our senior architects is captured within the Kiro knowledge base and the wiki memory system. Project context persists and compounds, even as team members shift between tasks.

Together, HERE Technologies and AWS are demonstrating how agentic AI can turn a fragile, manual workflow into a consistent, knowledge-rich, and largely automated process. With this system, our engineers can focus on what they do best: building the future of location technology. To explore the capabilities behind this work, you can review the Kiro documentation at kiro.dev, which cover powers, steering files, hooks, and the Kiro CLI.

Lessons learned: Building an evolving agentic architecture

Building an agentic system that our teams depend on daily isn’t a one-shot effort. Our architecture has gone through several iterations, and we want to share what worked and what surprised us.

Progressive disclosure over always-on context

Our first iteration loaded all domain knowledge into every agent interaction: field definitions, workflow rules, portfolio structure. This worked for demos but degraded quality at scale, because the model had too much context irrelevant to the current task. We moved to a skills model where domain-specific instruction sets are loaded on demand, only when the task requires them. The agent sees only the skill name and a one-sentence activation trigger at startup. The full body is injected when needed. This reduced our always-on token cost significantly without losing any capability.

Confirmation gates prevent costly mistakes

In an automated ticket creation workflow, a single hallucinated field value can create dozens of incorrectly tagged tickets. We introduced explicit confirmation gates at three decision points. The first reviews the analysis before any ticket is written. The second selects the responsible team, which derives the reporter and assignee. The third approves the Story and Task plan before those tickets are generated. Each gate presents a summary with Approve, Modify, or Cancel options. This added seconds to the workflow but eliminated the undo 15 tickets scenario entirely.

Memory must be structured to be useful

Early attempts at session memory were simple: dump a summary at the end of each session. The recall side was the problem. Without structure, the agent could not efficiently retrieve what it needed. Organizing memory into three typed layers (semantic, episodic, procedural) with structured frontmatter and a lightweight index made retrieval fast and precise. In our testing, the system recalls relevant context in under a second, even with hundreds of stored pages.

Code Intelligence fills the “how is this actually built?” gap

Documentation tells you what should exist. Code tells you what does exist. We found that tickets written purely from documentation were often rejected during refinement because they assumed patterns that didn’t match the implementation. Adding Code Intelligence, the ability to clone a repo, index it, and query it in natural language, closed this gap. The agent now checks how the service is actually built before writing acceptance criteria, and the resulting tickets align with developer expectations.

Spec-driven development for the agents themselves

We used the spec-driven workflow in Kiro to design and implement improvements to the agentic system. Requirements were formalized with correctness properties, designs were reviewed against those properties, and implementation tasks were generated with traceability back to specific requirements. This recursive use, the tool improving itself through its own methodology, gave us high confidence that changes did not regress existing behavior.

Conclusion

HERE Technologies turned a fragile, manual workflow into a consistent and largely automated one. Kiro powers, headless automation through the Kiro CLI, a three-layer memory system, and Code Intelligence work together in this approach. NDS.Live requirements now arrive as linked Jira hierarchies, with traceability captured as the work is created.

Several lessons from this journey can guide other organizations. Load domain knowledge on demand rather than always-on. Place confirmation gates at the decision points that matter most. Structure agent memory so the agent can recall it precisely. Ground your agents in source code, not documentation alone. Above all, start with one well-defined workflow and let the system compound expertise over time.

---

About the authors