This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

What happens when a Python-based AI agent and a .NET-based AI agent need to work together?

That is the idea behind MAF-A2A-NVIDIA-NemoAgents (https://github.com/elbruno/MAF-A2A-NVIDIA-NemoAgents-private): a reference app that shows how to combine NVIDIA NeMo Agent Toolkit, Microsoft Agent Framework, Agent-to-Agent communication, and Aspire into one multi-agent workflow. The repo describes itself as a production-ready sample that demonstrates NVIDIA NeMo Agent Toolkit + Microsoft Agent Framework with A2A communication, orchestrated with Aspire.

And yes, this is exactly the kind of demo I like: different stacks, different responsibilities, one shared protocol. No “everything must be rewritten in my favorite framework” drama. Just agents talking to agents. Beautiful.

The scenario: analysis first, action second

The application models a practical enterprise workflow:

A NeMo Data Analysis Agent receives business or operational data, analyzes metrics, detects trends or anomalies, and generates insights. Then, when an action is needed, a MAF Action Agent can trigger alerts, generate reports, or execute remediation steps. The web UI acts as the human-facing chat surface where users can request analysis and trigger actions.

So the flow is simple:

User  
↓ Web Chat UI  
↓ NeMo Data Analysis Agent  
↓ Analysis result  
↓ MAF Action Agent  
↓ Alert / Report / Action

The interesting part is that these agents are not built with the same framework. The NeMo agent is Python-based. The MAF agent is .NET-based. The bridge between them is A2A, using JSON-RPC and agent discovery. The repo architecture describes A2A as the communication layer between the web UI, the NeMo agent, and the MAF agent, with Aspire providing health checks, service discovery, tracing, and startup orchestration.

Why two agents?

Because “one mega-agent to rule them all” sounds cool until you need to debug, scale, secure, or explain it.

This repo separates responsibilities:

• NeMo Agent: data analysis, trends, anomalies, metrics, recommendations.
• MAF Agent: actions, alerts, reports, remediation workflows.
• Web UI: chat experience, discovery, orchestration, response rendering.
• Aspire: local distributed app orchestration, health, logs, and OpenTelemetry traces.

The repo calls out this separation of concerns directly: data analysis expertise is not the same as action execution expertise. It also helps with scalability, reliability, and vendor flexibility.

Where A2A fits

A2A is the key enabler here. It gives agents a common way to expose capabilities and communicate across frameworks and languages.

On the Microsoft Agent Framework side, A2A support allows agents to be exposed over A2A endpoints and discovered through agent cards. Microsoft’s A2A docs show that Agent Framework can expose multiple agents with separate A2A endpoints, and the agent-framework-a2a package can both connect to external A2A-compliant agents and expose Agent Framework agents over A2A.

The .NET A2A pattern looks like this in the official MAF examples:

builder.AddA2AServer("weather-agent");
app.MapA2AHttpJson("weather-agent", "/a2a/weather-agent");
app.MapWellKnownAgentCard(new AgentCard
{
    Name = "WeatherAgent",
    Description = "A helpful weather assistant.",
    SupportedInterfaces =
    [
        new AgentInterface
        {
            Url = "https://your-host/a2a/weather-agent",
            ProtocolBinding = ProtocolBindingNames.HttpJson,
            ProtocolVersion = "1.0",
        }
    ]
});

That pattern matters because agent discovery is not a nice-to-have. In a multi-agent system, the orchestrator needs to know:

Who are you?
What can you do?
Where do I call you?
Which protocol do you speak?

That is where the Agent Card becomes useful.

NeMo as an A2A agent

On the NVIDIA side, NeMo Agent Toolkit can publish workflows as A2A agents. NVIDIA’s docs describe nat a2a serve as the command that starts an A2A server, publishes a workflow as an A2A agent, and exposes an Agent Card at /.well-known/agent-card.json.

In this repo, Aspire starts the NeMo workflow using the NeMo Agent Toolkit A2A server approach. The AppHost launches the NeMo agent as an executable, configures the workflow file, host, port, public base URL, NVIDIA API key, Azure OpenAI settings, and OpenTelemetry exporter.

A simplified version of that idea looks like this:

var nvidiaApiKey = builder.AddParameter("nvidia-api-key", secret: true);
var azureOpenAiEndpoint = builder.AddParameter("azure-openai-endpoint", secret: true);
var azureOpenAiApiKey = builder.AddParameter("azure-openai-api-key", secret: true);
var nemo = builder.AddExecutable(
        name: "nemo-agent",
        command: "powershell",
        workingDirectory: ".",
        args:
        [
            "-NoProfile",
            "-Command",
            "nat a2a serve --config_file .\\src\\NemoDataAnalysisAgent\\nemo\\workflow.yml"
        ])
    .WithHttpEndpoint(name: "http", env: "NEMO_PORT")
    .WithEnvironment("NEMO_HOST", "127.0.0.1")
    .WithEnvironment("NVIDIA_API_KEY", nvidiaApiKey)
    .WithEnvironment("AZURE_OPENAI_ENDPOINT", azureOpenAiEndpoint)
    .WithEnvironment("AZURE_OPENAI_API_KEY", azureOpenAiApiKey)
    .WithOtlpExporter();

The important idea: NeMo owns the analysis workflow, but it is exposed as an A2A-compatible service.

MAF as the action agent

The MAF side is a .NET service focused on action execution. The repo exposes endpoints for executing actions, triggering alerts, generating reports, and handling A2A JSON-RPC requests. The README describes the MAF Action Agent as responsible for pluggable action handlers, multi-level alerts, async report generation, health checks, A2A integration, and OpenTelemetry tracing.

A simplified version of the MAF action endpoint looks like this:

app.MapPost("/api/actions/execute",
    async (ActionRequest request, IActionExecutor executor) =>
    {
        var result = await executor.ExecuteActionAsync(request);
        return Results.Ok(result);
    });

And the A2A-facing endpoints follow this shape:

app.MapGet("/.well-known/agent-card.json", () =>
{
    return Results.Ok(new
    {
        name = "MAF Action Agent",
        description = "Executes actions based on NeMo analysis",
        version = "1.0.0",
        capabilities = new[]
        {
            "execute-actions",
            "trigger-alerts",
            "generate-reports"
        },
        endpoint = "/a2a/maf-action-agent",
        a2a_version = "1.0"
    });
});
app.MapPost("/a2a/maf-action-agent",
    async (HttpContext context, IA2ABridge bridge) =>
    {
        using var reader = new StreamReader(context.Request.Body);
        var body = await reader.ReadToEndAsync();
        var response = await bridge.ProcessA2ARequestAsync(body);
        return Results.Text(response, "application/json");
    });

That is the handoff: the agent advertises what it can do, then receives structured requests through the A2A endpoint.

The web UI as the orchestrator

The web chat interface is where the human interacts with the system. It discovers both agents, sends analysis requests to NeMo, and optionally sends action requests to MAF. The README calls out a NeMo-first routing pattern: chat responses come from NeMo analysis before optional MAF action execution.

A simplified orchestration pattern looks like this:

public async Task<ChatResponse> ProcessChatAsync(ChatRequest request)
{
    var message = request.Message.ToLowerInvariant();
    if (ShouldTriggerAction(message))
    {
        var action = new ActionRequest
        {
            ActionType = InferActionType(message),
            Parameters = new Dictionary<string, object?>
            {
                ["message"] = request.Message
            }
        };
        var actionResult = await orchestrator.ExecuteActionAsync(action);
        return new ChatResponse
        {
            RespondedBy = "MAF Action Agent",
            Content = actionResult.Details
        };
    }
    var nemoReply = await orchestrator.SendNemoMessageAsync(
        request.Message,
        request.SessionId);
    return new ChatResponse
    {
        RespondedBy = "NeMo Data Analysis Agent",
        Content = nemoReply
    };
}

That is a nice pattern for demos and real apps: default to insight, escalate to action only when the user explicitly asks for it.

A2A request shape

The architecture docs describe JSON-RPC 2.0 over HTTP as the protocol used between agents. The documented example sends a method such as analyze, passes parameters like metric, timeframe, and aggregation, and receives a structured result with trend, anomalies, forecast, and insights.

A simplified A2A-style request could look like this:

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "kind": "message",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Analyze quarterly revenue trends"
        }
      ]
    }
  },
  "id": "request-001"
}

And the system can route that to the NeMo agent first. Later, a second request can trigger the MAF agent:

{
  "actionType": "trigger-alert",
  "parameters": {
    "message": "Trigger alert for high CPU usage",
    "analysisSummary": "CPU usage increased 35% over baseline."
  }
}

That second part is where things become useful. The action agent is not acting in isolation; it can act based on the previous analysis.

Why Aspire matters here

Aspire is doing a lot of the boring-but-important work.

The repo uses Aspire to coordinate startup order, service discovery, health checks, logging, and OpenTelemetry correlation across the NeMo agent, the MAF agent, and the web UI. The README describes Aspire as responsible for automatic agent endpoint registration, dependency management, continuous health checks, distributed tracing, unified logs, and NeMo pre-warm.

This is one of the hidden wins of the repo. Multi-agent demos often fail because they are hard to run. Here, Aspire gives the app a “one command, multiple services” developer experience:

aspire start

The README says that after starting the app, the web UI is available on port 5000, and the sample prompts include NeMo-only analysis, MAF-only alert triggering, and a combined NeMo + MAF workflow.

Why this repo is interesting

This repo is not just “another chat app.”

It demonstrates a few patterns that matter for real enterprise AI systems:

1. Cross-framework agents
   Python and .NET agents can collaborate without forcing everything into one stack.
2. Clear agent responsibility boundaries
   One agent analyzes. One agent acts. That makes the architecture easier to explain, test, and evolve.
3. A2A as the interoperability layer
   A2A gives each agent a common communication contract.
4. Aspire as the local cloud-native dev loop
   Developers can run, observe, and debug the system locally before thinking about containers or cloud deployment.
5. Observability from the beginning
   The architecture includes OpenTelemetry tracing, structured logging, and health checks instead of treating them as “we’ll add this later” work. The repo’s architecture highlights call out distributed tracing, resilience patterns, scalability, and a future roadmap for TLS, mutual authentication, and authorization.

Final thoughts

The big takeaway for me: A2A makes heterogeneous agent systems feel much more realistic.

In real organizations, not every team will use the same language, same framework, same model provider, or same runtime. Some teams will build in Python. Some will build in .NET. Some will use NVIDIA tooling. Some will use Microsoft Agent Framework. Some will deploy locally first, then move to Azure.

And that is fine.

The goal is not to force every agent into one framework. The goal is to give them a shared way to discover each other, communicate, and collaborate.

That is what this repo demonstrates: NVIDIA NeMo for analysis, MAF for action, A2A for interoperability, and Aspire for orchestration.

Agents talking to agents.

Finally, in a way we can actually run, observe, and explain.

Babu Annamalai and I have been working very hard on JasperFx Software‘s officially curated AI Skills for the “Critter Stack,” and I’m very pleased to announce today that these skills are officially open for business! Many of our support clients already have access, but as of today anyone interested is able to purchase access to the skills online at https://jasperfx.net/our-products/#ai-skills.

Distribution is done through a private NPM or Nuget repository, and purchasing the skills will give you access to these feeds. For any support, contact us at support@jasperfx.net, use our new GitHub tracker for our products, or contact JasperFx through our Discord server.

To read more about what AI Skills we offer so far, see the documentation website.

And these skills will be curated, meaning that we’ll work to continuously improve and add to the skills. As a matter of fact, there will be a new revision as early as tomorrow to provide AI assisted conversions to the next major releases of Marten, Polecat, and Wolverine.

Teams often treat developer experience as work that competes with shipping the product. That is understandable, but it is also backwards. The local loop, setup, debugging, repeatable operations, and agent workflows are part of how the product gets shipped. When those things are slow or unclear, every feature pays the tax.

The tricky part is that this tax is easiest to ignore when you are farthest from the dev loop. The people making prioritization decisions often are not the ones resetting the database, chasing logs across terminals, fixing a broken local environment, or trying to get an agent enough context to reproduce a bug. The pain is real, but it is distributed across the team in small, forgettable cuts.

The hard part is not wanting better devex. The hard part is making it real. The real architecture of many systems lives in Slack threads, shell history, half-remembered README steps, and the senior engineer who knows the order to run things. Turning that into something repeatable, discoverable, safe, and obvious for humans, scripts, and agents is work.

Aspire is built for that work.

Most modern apps are already distributed, even if teams do not describe them that way. A frontend, an API, a database, a cache, a queue, an auth provider, or another service is enough. Nobody sits down and says, “we are building a distributed system now”; the dependencies accumulate, and the local development experience gets harder every time.

Aspire’s bet is that a model for those dependencies makes devex easier to improve as the app grows. Humans use the dashboard. Agents and scripts use the CLI. Both are working from the same app model: the same resources, health, logs, relationships, and operations.

The adoption path is incremental. The dashboard can start standalone, the AppHost can begin as one file that describes what already exists, and commands can wrap scripts you already have. You do not have to throw away your README or current tooling to get value; Aspire gives those pieces a consistent model to hang off of.

Start with a place to look

The first pain is usually visibility. Something is broken, the API logged an error, the browser shows a failed request, the trace is somewhere else, and a developer is flipping between terminals, DevTools, and maybe a log aggregator. An agent can edit the code, but it has no structured way to understand what the running app is doing.

The smallest version of Aspire is just the dashboard.

aspire dashboard run

Run the standalone dashboard, wire your app to send OpenTelemetry data to it, and now you have a place to look before adopting the whole Aspire model. The signals your app already produces become something humans can inspect and agents can query through the CLI.

aspire otel logs api
aspire otel traces api

The first win is not “I modeled my whole system”; it is “I can see what is happening.” Logs and traces stop being scattered context and start becoming a queryable surface both humans and agents can use.

You can stop there for a while. For many teams, shared visibility is already a better local loop.

Give the app a shape

Once the team has a place to look, the next pain shows up: the dashboard can show what happened, but the app itself is still mostly implicit. That is when describing the application starts to matter.

aspire init

aspire init gives you the skeleton for an AppHost. This does not change your application; it describes it.

The AppHost is where Aspire starts to understand the shape of the system: this project talks to that database, this frontend depends on that API, this service should wait for that database, these resources belong together.

const builder = await createBuilder();

const db = await builder.addPostgres('db');
const api = await builder.addProject('api', '../api')
  .withReference(db).waitFor(db);

const web = await builder.addViteApp('web', './web')
  .withReference(api).waitFor(api);

await web.withBrowserLogs();
await builder.build().run();

Now the app stops being a collection of processes, ports, scripts, and tribal knowledge. It becomes a set of named resources with relationships, exposed consistently through the dashboard and CLI.

This is also why the model is code. Application modeling eventually needs real software engineering: reuse, composition, conditions, APIs, and extension points. Static manifests are useful, but once the model starts describing behavior and workflow, code is the more natural place for it to live.

A distributed app can be as simple as a browser calling an API; once that relationship is modeled, browser console logs and network requests can show up alongside backend logs, traces, resources, and health. The model gives the dashboard more context, and the local loop starts to feel different: you are operating the app as an app.

aspire start
aspire ps
aspire stop
aspire start --isolated
aspire wait api --status healthy --timeout 120

A script that waits for real health instead of sleeping for 30 seconds is not glamorous, but it is the kind of thing that makes a team faster every day.

Turn repeated work into operations

Then the next familiar pain shows up: the things everyone does, but nobody has really modeled. Seed the database, clear it, run migrations, issue a test auth token, create a test user, purge a queue, replay a webhook, run a smoke test, or open an admin UI.

Most teams eventually express these as scripts plus a README:

### Reset local database

Run `./scripts/db-reset.sh`, then `./scripts/db-migrate.sh`.
If you need a test token, run `./scripts/token.sh --user test@example.com`.
Make sure the API is already running first.

That works until it does not: the README drifts, the script names are inconsistent, the human knows the intent, and the agent sees a folder of shell scripts and guesses. Humans can compensate for undocumented systems with memory and experience; agents need structure.

Once Aspire knows about the resources, you can attach the common operations to the resources they affect.

await api
  .withCommand('migrate-db', 'Run migrations', runMigrations)
  .withCommand('reset-db', 'Reset local database', resetDatabase)
  .withCommand('issue-token', 'Issue test auth token', issueToken);

Those commands show up on the resource in the dashboard for humans. The same commands are available through the CLI for scripts and agents:

aspire resource api migrate-db
aspire resource api reset-db
aspire resource api issue-token

The implementation can still call existing scripts under the hood, but Aspire gives the operation a place in the application model: name, display text, resource context, dashboard affordance, CLI entry point, and a discoverable surface agents can invoke.

Commands are where developer experience stops being a paragraph in a README and becomes part of the application.

That is also where the agent story becomes concrete. An agent does not need to infer the reset flow from prose; it can see that api has a reset-db command, run it, wait for the API to become healthy, and inspect the logs if something fails.

This is when it starts to feel like a paved path

This is where the small pieces add up. Teams need shared visibility, repeatable operations, health checks, onboarding, debugging, and enough context for humans, scripts, CI, and agents to do useful work. Aspire connects those pieces through the app model: humans get the dashboard, automation gets the CLI, and both stay grounded in the same source of truth.

None of this replaces product work or the tools the team already likes. Scripts, traces, dashboards, editors, and CI can all still be useful. Aspire’s role is to connect those pieces through one model, so the team can start with visibility, add shape when the app needs it, codify repeated operations, and let the model grow only as far as the application needs it to grow.

Applications already exist as systems. Aspire makes those systems explicit, because explicit systems scale better than tribal knowledge.

The post Your dev loop is full of tribal knowledge appeared first on Aspire Blog.

Why does building complete UIs with AI still feel hard

Let’s clarify why many developers encounter obstacles even as tools promise speed. AI assistants have become highly effective at generating UI code quickly. However, friction arises when developers attempt to use that code in real applications:

• The layout looks correct at first, but fails across different screen sizes.
• Components render, while accessibility remains incomplete.
• The UI functions yet fall short of enterprise design standards.

The issue isn’t speed, it’s composition.

Enterprise UI development is not about individual components. It’s about:

• Assembling structure,
• Navigation,
• Content,
• Visual hierarchy,
• Responsiveness, and
• Usability into a single, cohesive experience.

Most AI tools generate parts but not the complete experience you need.

Introducing Syncfusion UI Builder: Turn your UI ideas into complete, production‑ready interfaces

With a clear understanding of what’s lacking in current AI-generated UIs, let’s explore how Syncfusion UI Builder provides a solution.

To bridge the gap, Syncfusion UI Builder is designed to compose complete UIs, not just generate code snippets. It is an AI-powered agent skill that turns high-level UI intent into complete, production-ready enterprise interfaces. By combining agent-based orchestration with verified Syncfusion component intelligence, the UI Builder helps developers build complete UI layouts, dashboards, admin panels, and complex pages, with greater confidence, correctness, and consistency.

It translates natural-language descriptions into:

• Structured page layouts: No more assembling pieces manually.
• Correctly configured components: Everything works out of the box.
• Responsive UI scaffolding: Ready for all devices.
• Accessibility built in: No retrofitting later.
• Design-system alignment: Consistent and enterprise-ready.

At its core, UI Builder is powered by Syncfusion Component Skills, which provide deep, component-level intelligence to the AI.

You can move from “generated code” to ready-to-use UI solutions.

Powered by Syncfusion Component Skills

The UI Builder does not rely on generic training data or assumptions about UI libraries.

Instead, it uses Syncfusion Component Skills, which are structured, component-specific playbooks that define:

• Correct component APIs and usage patterns.
• Required modules and feature injections.
• Supported properties and configurations.

These skills act as the foundation layer for UI Builder. When the builder selects a grid, chart, or other component, it applies to the corresponding component skill to ensure correctness. As a result, UI Builder delivers more complete and reliable UI output.

How UI Builder works differently

Traditional AI assistance focuses on what to generate, while our UI Builder focuses on how the UI comes together.

It coordinates multiple concerns simultaneously:

• Page and layout structure.
• Component selection using component skills.
• Feature configuration (sorting, paging, filtering, etc.)
• Design choices table, including CSS framework, Syncfusion theme, light/dark mode, and core design basics with default values.
• Theming and responsiveness.
• Accessibility enforcement.

This orchestration enables the AI assistant to operate at the same level as developers think when designing real-world apps.

Getting started: Building UIs with Agentic UI Builder (React)

With the background established, let’s see how to get started with the Agentic UI Builder for building React-based user interfaces.

Prerequisites

Before using Syncfusion UI Builder, ensure your environment meets the following requirements:

• Install and configure the Agent Package Manager (APM) in your development environment.
• Ensure that Node.js version 18 or later is installed.
• Use an AI-powered IDE or agent that supports Skills (VS Code, Cursor, Syncfusion Code Studio, etc.).
• Create a new React app or use the existing one.
• Obtain a valid Syncfusion license (Commercial, Community, or Free Trial).

Installing Syncfusion UI Builder (React)

Once APM is installed, you can quickly get started by installing the Syncfusion React UI Builder skill.

Refer to the following code.

# GitHub Copilot
apm install Syncfusion/react-ui-builder -t copilot

# Claude Code
apm install Syncfusion/react-ui-builder -t claude

# Cursor
apm install Syncfusion/react-ui-builder -t cursor

After installation, the skill and agent files will be added to your project along with the supported AI tools to automatically detect and load the builder.

Once installed, using UI Builder is entirely prompt-driven.

1. Open your supported IDE.
2. In the AI chat panel, select the syncfusion-react-ui-builder agent.
3. Describe the UI you want to build using natural language.

Example prompt

Design a full-viewport premium SaaS admin dashboard that feels fluid, spacious, and visually rich—avoid boxed or narrow layouts. Use a soft neutral background (#F8FAFC) with layered white surfaces, subtle shadows, soft borders, and light gradients to create depth. Include a floating glass-style header (logo, search, notifications, avatar dropdown) and a stylish collapsible sidebar with tinted background, smooth animations, and highlighted active states. Structure the main area with an asymmetrical, responsive grid layout using generous spacing (24–32px), featuring larger, visually dominant cards (with icons, gradients, trend indicators, and hover lift), charts (line/bar/pie in cards), and an enhanced data grid (sticky header, sorting, filtering, badges, hover states, pagination). Apply a modern design system (Inter font, 4/8px spacing, muted grays, indigo/blue accents, semantic colors) with smooth 150–250ms transitions, micro-interactions, tooltips, and high accessibility.

Refer to the following output UI.

What happens behind the scenes

• The UI Builder selects the correct Syncfusion components and icons.
• Then, the corresponding component skills are applied.
• After that, the required features, modules, and configurations are automatically applied.
• Finally, the layout, accessibility, and responsiveness are enforced.

The result is complete, production-ready UI code, not disconnected code fragments.

What changes when you use UI Builder

Here’s the difference developers notice immediately:

The same prompt delivers significantly better results because the AI operates on verified component knowledge.

Built for Essential Studio

The UI Builder is designed to work across the full range of frameworks and platforms supported by our Essential Studio, enabling consistent and accurate UI generation across your development stack.

Users can install the corresponding UI Builder using the following commands:

Built for real enterprise scenarios

The UI Builder excels in scenarios where accuracy and structure are critical:

• Dashboards
• Landing pages
• Portfolio

Component Skills ensure correctness, while UI Builder ensures overall UI cohesion.

Stop settling for “almost done”, start shipping complete UIs with confidence

Thanks for reading! From here on, you don’t have to deal with broken layouts, missing configurations, or endless UI fixes anymore.

Syncfusion UI Builder transforms how you build UIs. Instead of stitching together incomplete pieces, you can now create fully structured, enterprise‑ready interfaces, right inside your workflow.

 What does this mean for you:

• Build faster: Go from idea → working UI in minutes.
• Reduce rework: No more fixing half-generated outputs.
• Stay consistent: Enterprise-grade design, every time.
• Trust your output: AI that delivers usable results, not just starting points.

If you’re already using AI, this is your next leap: from “fast start” to “strong finish.”

 Ready to experience the difference?

• Already a Syncfusion user? Download the latest version from the License and Downloads page.
• New here? Start your 30-day free trial and explore everything hands-on.

Have questions or need help?
We’re here for you. Reach out anytime via the support forum,  support portal, or feedback portal.

Now it’s your turn: Build smarter, ship faster, and finally trust your UI output!