DEV Community: Vikrant Bagal

Using Prebuilt Agents with Coding Agents: A Complete Guide for Full-Stack .NET, Node.js & Frontend

Vikrant Bagal — Mon, 25 May 2026 18:29:44 +0000

The AI coding agent landscape has exploded in 2026. Tools like Claude Code, OpenCode, and Cursor are transforming how we build software, but the real power comes from integrating them with prebuilt agents that handle specialized tasks.

This guide covers everything you need to know about using prebuilt agents with coding agents for full-stack .NET, Node.js, and frontend development.

📋 What You'll Learn

Best Agents Available - Claude Code, OpenCode, Cursor, and specialized prebuilt frameworks
Efficient Usage Patterns - How to leverage each agent's strengths
Pitfalls to Avoid - Common mistakes that waste tokens and time
Context Saving Tips - Keep your sessions productive and cost-effective
Step-by-Step Setup - Complete configuration for your stack

🏆 Best Coding Agents in 2026

Quick Comparison Table

Feature	OpenCode	Claude Code	Cursor
Type	Terminal TUI	Terminal CLI	VS Code fork
Open Source	✅ Yes (MIT)	⚠️ Source-available	❌ Proprietary
LLM Providers	75+ via Models.dev	Claude only	Claude, GPT, Gemini
Multi-Model Routing	✅ Native	❌ No	⚠️ Manual switch
MCP Support	✅ Yes	✅ Yes	✅ Yes
Multi-Agent	10 agents (OmO)	Subagent spawning	Composer
Edit Tool	Hashline (OmO)	Built-in Edit	Inline diff
Price	Free + API costs	$20/mo (Pro)	$20/mo (Pro)
Best For	Power users, multi-model	Deep codebase work	Visual developers

1. OpenCode + Oh-My-OpenAgent

OpenCode is the open-source terminal powerhouse that routes to 75+ LLM providers. Combined with Oh-My-OpenAgent (OmO), it becomes a multi-agent system with 10 specialized agents.

Why Choose OpenCode?

Model Freedom: Use any provider, switch models per task, avoid vendor lock-in
Performance: Go binary with TUI means sub-second startup
OmO Ecosystem: 10 specialized agents, Hashline edits, automated model routing
LSP Integration: Real code intelligence via language servers
Cost Control: Pay only for API calls you make

Installation

# Install OpenCode
curl -fsSL https://opencode.ai/install | bash

# Verify installation
opencode --version
# Output: opencode version 1.4.0

# Install Oh-My-OpenAgent
git clone https://github.com/nicepkg/oh-my-openagent.git
cd oh-my-openagent
npm install && npm run setup

Configuration for Full-Stack Development

Create a configuration file for your stack:

# ~/.opencode/config.yml
providers:
  anthropic:
    api_key: ${ANTHROPIC_API_KEY}
  openai:
    api_key: ${OPENAI_API_KEY}
  google:
    api_key: ${GOOGLE_API_KEY}

routing:
  # Route tasks to appropriate models
  code_generation: "gpt-4o"      # Fast, cheap for simple code
  architecture: "claude-opus"    # Better reasoning for decisions
  refactoring: "claude-sonnet"   # Balanced for multi-file changes

omO_agents:
  enabled: true
  agents:
    - frontend
    - backend
    - database
    - testing
    - deployment

Usage Example for Full-Stack

# Start OpenCode in your project
opencode

# Within OpenCode, use OmO agents:
# @frontend - React components, CSS, state management
# @backend - .NET controllers, services, APIs
# @database - Entity Framework, migrations, queries
# @testing - Unit tests, integration tests

# Example prompt:
> @frontend Create a React component for user login form with validation

2. Claude Code

Claude Code is Anthropic's terminal-based agent built around Claude Opus 4.6, which achieves an 80.8% SWE-bench score (highest verified as of 2026).

Why Choose Claude Code?

Best Single-Model Performance: Opus 4.6 genuinely outperforms alternatives
Deep Git Integration: Commits, PRs, branch management built-in
Hooks System: Enforce quality gates automatically
Project Memory: CLAUDE.md persists context across sessions
Agentic Reliability: Handles complex multi-step tasks without losing track

Installation

# Install Claude Code
npm install -g @anthropic/claude-code

# Verify installation
claude --version

# Start a session in your project
cd /path/to/project
claude

Configuration for Full-Stack .NET + Node.js

CLAUDE.md (project-level memory file):

# Project: Full-Stack Application

## Stack
- Backend: .NET 8 / ASP.NET Core (Clean Architecture)
- Frontend: React 18 with TypeScript
- Database: PostgreSQL with Entity Framework Core
- API: RESTful with OpenAPI/Swagger

## Coding Standards
- Use async/await for all I/O operations
- Follow SOLID principles for .NET classes
- React components should be functional with hooks
- Unit tests: xUnit for .NET, Jest for React
- Code style: EditorConfig + Prettier

## Architecture Decisions
- Backend uses CQRS pattern with MediatR
- Frontend uses React Query for server state
- Authentication: JWT with refresh tokens
- Deployment: Docker + Azure

## Common Commands
- Build backend: `dotnet build`
- Run backend: `dotnet run --project src/API`
- Build frontend: `npm run build`
- Run tests: `dotnet test` and `npm test`

.claude/settings.local.json (per-user settings):

{
  "env": {
    "ANTHROPIC_API_KEY": "your-api-key",
    "DATABASE_CONNECTION": "your-connection-string"
  },
  "permissions": {
    "allow": ["Bash", "Glob", "Grep", "Write", "Edit"]
  }
}

Usage Examples

# Start Claude Code
claude

# Within Claude Code:

# 1. Create a new API endpoint
> Create a new API endpoint for user registration in src/API/Controllers/AccountController.cs

# 2. Implement a React component
> Create a React component for user profile display with edit functionality

# 3. Full-stack feature
> Implement a complete "forgot password" flow:
> - Backend: .NET controller, service, email template
> - Frontend: React form with validation
> - Database: Update user table with reset token

# 4. Use subagents for parallel work
> /subagent backend "Create EF Core migration for password reset tokens"
> /subagent frontend "Build password reset form component"

3. Cursor

Cursor is the VS Code fork that embeds AI directly into the editing experience.

Why Choose Cursor?

Full IDE Experience: Syntax highlighting, debugging, extensions, terminal
Visual Diff Review: See exactly what changes before accepting
Tab Completion: AI-powered autocomplete that learns patterns
Lower Learning Curve: If you know VS Code, you know Cursor
Multi-Model Access: Claude, GPT-4o, Gemini, custom models

Installation

Download from cursor.com
Import your VS Code settings
Sign in with your account

Configuration for Full-Stack Development

.cursor/rules/ (AI rules directory):

# .cursor/rules/dotnet.mdc
---
applyTo: "**/*.cs"
---
# .NET Coding Standards
- Use async/await for I/O operations
- Follow Clean Architecture patterns
- Use Entity Framework Core for data access
- Implement proper error handling with try-catch
- Write unit tests with xUnit

# .cursor/rules/react.mdc
---
applyTo: "**/*.{tsx,jsx}"
---
# React Coding Standards
- Use functional components with hooks
- Implement TypeScript interfaces
- Use React Query for server state
- Follow component composition patterns
- Write tests with Jest + React Testing Library

.cursor/indexing_allowlist (control what gets indexed):

src/**/*.cs
src/**/*.tsx
src/**/*.ts
!node_modules/**
!bin/**
!obj/**
!*.min.js

Usage Example

# Start Cursor and open your project folder

# Use Composer for multi-file changes:
# Cmd/Ctrl + I to open Composer

# Example prompt for full-stack feature:
"Add user profile feature:
- Backend: Update User entity, create ProfileController
- Frontend: Build profile page with form
- Tests: Add integration tests"

# Use Tab completion:
# Type function signature, Tab to auto-generate implementation

4. Prebuilt Agent Frameworks

Agent-Bober

A multi-agent harness for building applications autonomously with any LLM.

Installation:

npm install agent-bober

Configuration:

// agent-bober.config.js
module.exports = {
  pipeline: ["researcher", "planner", "curator", "generator", "evaluator"],
  models: {
    primary: "claude-3-5-sonnet",
    fallback: "gpt-4o"
  },
  mcpServers: {
    cursor: { enabled: true },
    windsurf: { enabled: true }
  }
};

Usage:

# Run full-stack development pipeline
npx agent-bober --task "Build user authentication system"

# The pipeline will:
# 1. Research: Gather requirements and best practices
# 2. Plan: Create architecture and implementation plan
# 3. Curate: Review existing codebase for integration points
# 4. Generate: Create backend (.NET) and frontend (React) code
# 5. Evaluate: Run tests and review code quality

Specialist-Agent

27+ specialized agents with 21 skills for different frameworks.

Installation:

npm install specialist-agent

Setup for .NET + React Stack:

// specialist-agent.config.js
const { SpecialistAgent } = require('specialist-agent');

const agent = new SpecialistAgent({
  stack: ['dotnet', 'react', 'nodejs'],
  frameworkPacks: ['react', 'nextjs']
});

// Use specialized agents
agent.use('dotnet-architect').planSolution('User Management');
agent.use('react-developer').createComponents('User Dashboard');
agent.use('nodejs-backend').buildApi('User API');

🎯 How to Use These Agents Efficiently

Agent Selection Strategy

Task Type	Best Agent	Why
Quick edits	Cursor	Visual diff, inline changes
Deep refactoring	Claude Code	Subagent planning, git integration
Multi-provider	OpenCode	Model routing, cost optimization
Autonomous builds	Agent-Bober	Full pipeline automation
Framework-specific	Specialist-Agent	Pre-built skills for your stack

Workflow Patterns

Pattern 1: Parallel Development

Claude Code (Main)
  ├─ Subagent: Backend (.NET)
  ├─ Subagent: Frontend (React)
  └─ Subagent: Database (EF Core)

All subagents work simultaneously, then merge results

Pattern 2: Sequential Pipeline

OpenCode with OmO
  ├─ Researcher: Gather requirements
  ├─ Planner: Create architecture
  ├─ Generator: Write code
  └─ Evaluator: Test and review

Pattern 3: Visual Review

Cursor Composer
  ├─ Describe feature
  ├─ Review visual diff
  ├─ Accept/reject changes
  └─ Iterate as needed

⚠️ Pitfalls to Avoid

1. Vague Prompts

❌ "Fix the login page"
✅ "Update src/components/LoginForm.tsx to add email validation using react-hook-form"

2. Full Context on Every Turn

❌ Asking agents to read entire codebase each time
✅ Use #file: references and scoped prompts

3. No Project Memory

❌ Starting fresh every session
✅ Use CLAUDE.md, .cursor/rules, or OpenCode memory files

4. Expensive Models for Simple Tasks

❌ Using Claude Opus for simple formatting
✅ Route simple tasks to cheaper models (GPT-4.1, Haiku)

5. Ignoring Git History

❌ Manual commits without context
✅ Let Claude Code handle commits with meaningful messages

6. No Testing Strategy

❌ Generating code without tests
✅ Always request tests alongside implementation

7. Context Rot

❌ Letting context window fill to 150K+ tokens
✅ Compact context before it degrades model performance

💾 Context Saving Tips

1. Context Engineering (Foojay.io's 8 Levers)

Lever A: Scope Your Asks

# Bad: "Refactor the order email"
# Good: "Refactor #file:src/Email/OrderConfirmationService.cs to use new template engine"

# Use #file: syntax in Claude Code
# Use @ in Cursor
# Use explicit paths in OpenCode

Lever B: Prompt Caching - Order Matters

Static at top (cached):
- Tool definitions
- System prompt
- Custom instructions
- Skills/rules

Dynamic at bottom:
- Retrieved files
- Conversation history

Lever C: Tool & MCP Hygiene

// .vscode/mcp.json - keep it short
{
  "servers": {
    "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem"] }
    // Disable servers you don't use
  }
}

Lever D: Custom Instructions

# CLAUDE.md or .github/copilot-instructions.md

## Rules
- Use async/await for all I/O
- Write tests for new features
- Follow Clean Architecture
- Use #file: for specific files
- Reply with diffs, not novels

Lever E: Model Routing

# Start cheap, escalate when stuck
routing:
  inline_completions: "gpt-4.1"      # 0x cost
  real_coding: "claude-sonnet"       # 1x cost
  long_refactor: "claude-sonnet-long" # 1x cost
  hard_reasoning: "claude-opus"      # 10x cost

Lever F: Output Discipline

# Bad: "Explain what you're about to do..."
# Good: "Reply with unified diff only, no commentary"

Lever G: Repo Hygiene

# Exclude from indexing
# .cursorignore or .opencodeignore
node_modules/
bin/
obj/
*.min.js

Lever H: Observability

# Monitor token usage
# Claude Code shows token count per turn
# OpenCode has --verbose flag
# Cursor shows in output panel

2. Session Management

For Long Sessions:

# Claude Code: Use /compact to reduce context
# OpenCode: Start new session with /new
# Cursor: Use @workspace for fresh context

For Multi-Day Projects:

# Create project memory files
echo "# Project Context" > CLAUDE.md
echo "Last updated: $(date)" >> CLAUDE.md

# Add key decisions and architecture notes
# This persists across sessions

3. Token Optimization Strategies

Strategy	Savings	Implementation
File scoping	50-70%	Use #file: references
Prompt caching	90% for static content	Order prompts correctly
Model routing	10x cost difference	Route simple tasks to cheap models
Output discipline	60-80%	Request diffs, not explanations
Context compaction	Prevents rot	Compact at 50K tokens

🔧 Step-by-Step Setup Guide

Step 1: Install Your Chosen Agent

Option A: Claude Code (Recommended for .NET + Full-Stack)

npm install -g @anthropic/claude-code
claude --version

Option B: OpenCode (For Multi-Model Flexibility)

curl -fsSL https://opencode.ai/install | bash
opencode --version

Option C: Cursor (For Visual Development)

# Download from cursor.com
# Import VS Code settings
# Install extensions

Step 2: Configure Project Structure

my-project/
├── .claude/                    # Claude Code config
│   └── settings.local.json
├── CLAUDE.md                   # Project memory
├── .cursor/                    # Cursor config
│   └── rules/
├── .opencode/                  # OpenCode config
├── src/
│   ├── API/                   # .NET Backend
│   ├── Web/                   # React Frontend
│   └── Shared/                # Common code
├── tests/
└── docker-compose.yml

Step 3: Set Up CLAUDE.md (For Claude Code)

# Full-Stack Project: My Application

## Stack Overview
- **Backend**: .NET 8 / ASP.NET Core / Clean Architecture
- **Frontend**: React 18 / TypeScript / Vite
- **Database**: PostgreSQL / Entity Framework Core
- **Auth**: JWT with refresh tokens
- **Testing**: xUnit (backend) / Jest (frontend)

## Project Structure
- src/API - ASP.NET Core Web API
- src/Application - Business logic (CQRS with MediatR)
- src/Infrastructure - EF Core, external services
- src/Web - React frontend
- tests/ - Unit and integration tests

## Coding Standards
- Use async/await for all I/O operations
- Follow SOLID principles
- Write tests for new features
- Use repository pattern for data access
- Implement proper error handling

## Common Commands
- Build backend: `dotnet build`
- Run backend: `dotnet run --project src/API`
- Build frontend: `cd src/Web && npm run build`
- Run tests: `dotnet test` and `cd src/Web && npm test`
- Run migrations: `dotnet ef database update`

## Architecture Decisions
- Backend uses CQRS pattern with MediatR
- Frontend uses React Query for server state management
- API follows RESTful conventions with OpenAPI documentation
- Authentication uses JWT tokens with refresh mechanism

Step 4: Configure Agent Settings

Claude Code Settings (.claude/settings.local.json):

{
  "env": {
    "ANTHROPIC_API_KEY": "your-key-here",
    "DATABASE_CONNECTION": "your-connection-string"
  },
  "permissions": {
    "allow": ["Bash", "Glob", "Grep", "Write", "Edit"]
  }
}

OpenCode Configuration (.opencode/config.yml):

providers:
  anthropic:
    api_key: ${ANTHROPIC_API_KEY}
  openai:
    api_key: ${OPENAI_API_KEY}

routing:
  code_generation: "gpt-4o"
  architecture: "claude-opus"
  refactoring: "claude-sonnet"

Cursor Rules (.cursor/rules/dotnet.mdc):

---
applyTo: "**/*.cs"
---
# .NET Standards
- Use Clean Architecture
- Implement CQRS with MediatR
- Write xUnit tests
- Follow async patterns

Step 5: Start Developing

Claude Code Workflow:

cd my-project
claude

# Prompt examples:
> Create user registration API in src/API/Controllers/AccountController.cs

> Build login form component in src/Web/src/components/LoginForm.tsx

> /subagent backend "Create EF Core migration for user table"
> /subagent frontend "Build user dashboard component"

OpenCode Workflow:

cd my-project
opencode

# Use OmO agents:
@backend Create user authentication service
@frontend Build login form with validation
@database Design user schema with EF Core

Cursor Workflow:

# Open project in Cursor
# Use Composer (Cmd/Ctrl+I)
# Describe feature, review diff, accept changes

Step 6: Monitor and Optimize

Check Token Usage:

Claude Code: Shows tokens per turn
OpenCode: Use --verbose flag
Cursor: View in output panel

Compact Context When Needed:

Claude Code: /compact command
OpenCode: Start new session with /new
Cursor: Use @workspace for fresh context

Review Session History:

# Claude Code: /history
# OpenCode: Session history in ~/.opencode/
# Cursor: Output panel logs

📊 Full-Stack Development Workflow

Daily Development Cycle

Morning: Planning

Claude Code Session:
1. Review CLAUDE.md for project context
2. Ask: "What should I work on today?"
3. Plan feature implementation
4. Create subagents for parallel work

Development: Implementation

Claude Code:
1. Create backend API endpoint
2. Build frontend component
3. Add database migration
4. Write unit tests

OpenCode:
1. Use @backend for .NET code
2. Use @frontend for React code
3. Use @testing for test generation

Review: Quality Assurance

Cursor:
1. Review visual diffs
2. Run tests
3. Check for edge cases
4. Refactor as needed

Evening: Cleanup

Claude Code:
1. /compact to reduce context
2. Commit with meaningful messages
3. Update CLAUDE.md with decisions

Feature Development Example

Task: User Profile Management

# 1. Backend (.NET)
> Create UserProfile entity with EF Core migration
> Build UserProfileController with CRUD endpoints
> Implement UserProfileService with business logic
> Write integration tests

# 2. Frontend (React)
> Build UserProfile component with edit functionality
> Create useUserProfile hook with React Query
> Add form validation with react-hook-form
> Write Jest tests

# 3. Integration
> Connect frontend to backend API
> Test end-to-end flow
> Add error handling
> Deploy to staging

🎯 Conclusion

Using prebuilt agents with coding agents transforms full-stack development from a solo effort into a collaborative team of AI specialists. The key is:

Choose the right agent for your workflow (Claude Code for deep work, OpenCode for flexibility, Cursor for visual development)
Use prebuilt frameworks like Agent-Bober or Specialist-Agent for repeatable patterns
Master context management to keep sessions productive and cost-effective
Follow the step-by-step setup to configure your environment properly

Start with Claude Code for .NET + Node.js + React stacks, integrate OpenCode for multi-model routing when needed, and use Cursor for visual review and debugging. Combine with prebuilt agent frameworks for autonomous development pipelines.

Ready to get started? Pick one agent, set up CLAUDE.md, and start building!

LinkedIn Profile: https://www.linkedin.com/in/vikrant-bagal

What Can Be Built with Durable Workflows in Microsoft Agent Framework

Vikrant Bagal — Mon, 25 May 2026 16:25:29 +0000

The Microsoft Agent Framework has revolutionized how we build AI-powered applications. With its April 2026 v1.0 release, developers now have a production-ready SDK for creating intelligent agents that can orchestrate complex multi-step workflows. But what exactly can you build with Durable Workflows? Let's explore the possibilities.

The Foundation: Understanding Durable Workflows

Durable Workflows in Microsoft Agent Framework allow you to build stateful, long-running AI orchestrations that survive process restarts and failures. Unlike in-process execution (which is great for development), durable workflows use the Durable Task Scheduler (DTS) to persist workflow state and coordinate execution across distributed systems.

Key Features of Durable Workflows

Stateful execution: Workflows survive process restarts and failures
Automatic checkpointing: Progress is saved after each step
Distributed execution: Executors can run across different machines
Long-running orchestrations: Workflows can run for minutes, hours, or even days
Observability: Built-in dashboard for monitoring workflow executions

1. Customer Support Systems with Specialized Agents

One of the most practical applications of Durable Workflows is building intelligent customer support systems. Instead of a single monolithic chatbot, you can create a network of specialized agents that work together.

The Architecture

User Query → Triage Agent → 
  ├─ Technical Issues → Technical Support Agent
  ├─ Billing Questions → Billing Agent
  ├─ Account Management → Account Agent
  └─ Escalation → Human Agent (HITL)

Why This Works

The Handoff Orchestration pattern allows agents to transfer complete control to another agent with full conversation context. This is different from the Agent-as-Tools pattern where a primary agent delegates subtasks while retaining overall responsibility.

Key Differences:

Aspect	Handoff	Agent-as-Tools
Control Flow	Agent transfers entire task	Primary agent delegates subtasks
Task Ownership	New agent owns the task	Primary agent retains responsibility
Context	Full conversation context transferred	Limited context to tools

Implementation Example

// Create specialized support agents
ChatClientAgent technicalSupport = new(client,
    "You are a technical support specialist. Help users troubleshoot software issues.",
    "technical_support", "Technical Support Agent");

ChatClientAgent billingSupport = new(client,
    "You handle billing inquiries, refunds, and payment issues.",
    "billing_support", "Billing Support Agent");

ChatClientAgent triageAgent = new(client,
    "Route customer queries to the appropriate specialist.",
    "triage_agent", "Triage Agent");

// Configure handoff rules
var workflow = AgentWorkflowBuilder.CreateHandoffBuilderWith(triageAgent)
    .WithHandoffs(triageAgent, [technicalSupport, billingSupport])
    .Build();

Benefits:

Each agent specializes in a specific domain
Customers get accurate, expert responses
Seamless handoffs with full context preservation
Durable execution across service restarts

2. Content Creation and Review Pipeline

Content creation workflows benefit enormously from durable execution, especially when dealing with long-running tasks like research, drafting, and review.

The Architecture

Content Request → Research Agent → 
  ↓
Draft Creation Agent → 
  ↓
Review Agent (Editorial) → 
  ↓
Approval Agent (Human-in-Loop) → 
  ↓
Publishing Agent

Implementation Pattern

// Define executors for each pipeline stage
internal sealed class ResearchExecutor 
    : Executor<ContentRequest, ResearchData>("Research")
{
    public override async ValueTask<ResearchData> HandleAsync(
        ContentRequest request, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Gather information from multiple sources
        var sources = await ResearchSourcesAsync(request.Topic);
        return new ResearchData(sources, request.Topic);
    }
}

internal sealed class DraftExecutor 
    : Executor<ResearchData, DraftContent>("Draft")
{
    public override async ValueTask<DraftContent> HandleAsync(
        ResearchData research, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Generate draft content
        return await GenerateDraftAsync(research);
    }
}

internal sealed class ReviewExecutor 
    : Executor<DraftContent, ReviewResult>("Review")
{
    public override async ValueTask<ReviewResult> HandleAsync(
        DraftContent draft, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Editorial review with feedback
        return await ReviewContentAsync(draft);
    }
}

internal sealed class ApprovalExecutor 
    : Executor<ReviewResult, ApprovalStatus>("Approval")
{
    public override async ValueTask<ApprovalStatus> HandleAsync(
        ReviewResult review, IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Queue for human approval
        return await RequestHumanApprovalAsync(review);
    }
}

// Build the workflow
var contentPipeline = new WorkflowBuilder(researchExecutor)
    .WithName("ContentCreationPipeline")
    .WithDescription("Research → Draft → Review → Approval → Publish")
    .AddEdge(researchExecutor, draftExecutor)
    .AddEdge(draftExecutor, reviewExecutor)
    .AddEdge(reviewExecutor, approvalExecutor)
    .Build();

Why Durable Matters Here:

Research can take hours across multiple sources
Drafting and review may span multiple days
Approval workflows can involve multiple stakeholders
Workflow state survives server restarts and failures

3. Multi-Agent Translation Pipeline

A practical example from Microsoft's documentation shows how to build a translation pipeline using multiple specialized agents.

The Architecture

Input Text → French Translator → Spanish Translator → English Translator → Output

Implementation

// Create translation agents for different languages
AIAgent frenchAgent = await GetTranslationAgentAsync("French", aiProjectClient, deploymentName);
AIAgent spanishAgent = await GetTranslationAgentAsync("Spanish", aiProjectClient, deploymentName);
AIAgent englishAgent = await GetTranslationAgentAsync("English", aiProjectClient, deploymentName);

// Build sequential workflow
var workflow = new WorkflowBuilder(frenchAgent)
    .AddEdge(frenchAgent, spanishAgent)
    .AddEdge(spanishAgent, englishAgent)
    .Build();

// Execute with streaming to observe real-time updates
await using StreamingRun run = await InProcessExecution.RunStreamingAsync(
    workflow, 
    new ChatMessage(ChatRole.User, "Hello World!"));

await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

await foreach (var evt in run.WatchStreamAsync())
{
    if (evt is ExecutorCompletedEvent completed)
    {
        Console.WriteLine($"{completed.ExecutorId}: {completed.Data}");
    }
}

Key Features:

Sequential agent chaining with type safety
Real-time streaming updates
Each agent specializes in translation between specific languages
Durable execution for long-running translations

4. Enterprise AI Orchestration with Microsoft 365

For enterprise scenarios, Microsoft Agent Framework enables sophisticated multi-agent workflows integrated with Microsoft 365 services.

The Architecture

Enterprise Request → 
  ├─ HR Agent (Employee data, policies)
  ├─ Finance Agent (Budgets, expenses)
  ├─ IT Agent (System access, troubleshooting)
  └─ Compliance Agent (Policy verification)

Diamond Orchestration Pattern

Enterprise workflows often use a diamond orchestration pattern where multiple agents work in parallel, then results are merged and processed further.

var workflow = new WorkflowBuilder(inputAgent)
    // Fan-out to multiple specialized agents
    .AddFanOutEdge(inputAgent, [hrAgent, financeAgent, itAgent, complianceAgent])
    // Wait for all to complete
    .AddFanInBarrierEdge([hrAgent, financeAgent, itAgent, complianceAgent], mergeAgent)
    // Process merged results
    .AddEdge(mergeAgent, finalProcessingAgent)
    .Build();

Benefits for Enterprises:

Specialized agents for different business domains
Parallel processing for faster response times
Integration with existing Microsoft 365 infrastructure
Distributed execution across Azure resources

5. Order Processing Systems

A practical example from the Microsoft blog shows how to build a durable order processing workflow.

The Architecture

Order Request → Order Lookup → Order Cancel → Send Email → Complete

Implementation

internal sealed class OrderLookup 
    : Executor<OrderCancelRequest, Order>("OrderLookup")
{
    public override async ValueTask<Order> HandleAsync(
        OrderCancelRequest message, 
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Lookup order from database
        await Task.Delay(TimeSpan.FromMilliseconds(100), cancellationToken);
        return new Order(
            Id: message.OrderId,
            OrderDate: DateTime.UtcNow.AddDays(-1),
            IsCancelled: false,
            CancelReason: message.Reason,
            Customer: new Customer("Jerry", "jerry@example.com"));
    }
}

internal sealed class OrderCancel 
    : Executor<Order, Order>("OrderCancel")
{
    public override async ValueTask<Order> HandleAsync(
        Order message,
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        await Task.Delay(TimeSpan.FromMilliseconds(200), cancellationToken);
        return message with { IsCancelled = true };
    }
}

internal sealed class SendEmail 
    : Executor<Order, string>("SendEmail")
{
    public override ValueTask<string> HandleAsync(
        Order message,
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        return ValueTask.FromResult(
            $"Cancellation email sent for order {message.Id} " +
            $"to {message.Customer.Email}.");
    }
}

// Build workflow
var cancelOrder = new WorkflowBuilder(orderLookup)
    .WithName("CancelOrder")
    .WithDescription("Cancel an order and notify the customer")
    .AddEdge(orderLookup, orderCancel)
    .AddEdge(orderCancel, sendEmail)
    .Build();

Running with Durable Execution

// Add durable packages
dotnet add package Microsoft.Agents.AI.DurableTask --prerelease
dotnet add package Microsoft.DurableTask.Client.AzureManaged
dotnet add package Microsoft.DurableTask.Worker.AzureManaged

// Configure durable workflow
IHost host = Host.CreateDefaultBuilder(args)
    .ConfigureServices(services =>
    {
        services.ConfigureDurableWorkflows(
            workflowOptions => 
                workflowOptions.AddWorkflow(cancelOrder),
            workerBuilder: builder =>
                builder.UseDurableTaskScheduler(dtsConnectionString),
            clientBuilder: builder =>
                builder.UseDurableTaskScheduler(dtsConnectionString));
    })
    .Build();

// Start the host and run workflow
await host.StartAsync();

IWorkflowClient workflowClient = 
    host.Services.GetRequiredService<IWorkflowClient>();

var request = new OrderCancelRequest("12345", "Wrong color");
var run = await workflowClient.RunAsync(cancelOrder, request);

string result = await run.WaitForCompletionAsync<string>();
Console.WriteLine($"Workflow completed: {result}");

Durability Benefits:

State persists across process restarts
Automatic checkpointing after each step
Observable execution timeline in DTS Dashboard
Can resume from failure without losing work

6. Human-in-the-Loop Approval Workflows

For sensitive operations, Durable Workflows enable human approval checkpoints integrated into the automation pipeline.

Use Cases

Financial transactions requiring manager approval
Content publishing requiring editorial review
Data access requests requiring security approval
Contract negotiations requiring legal review

Implementation Pattern

internal sealed class HumanApprovalExecutor 
    : Executor<ApprovalRequest, ApprovalResponse>("HumanApproval")
{
    public override async ValueTask<ApprovalResponse> HandleAsync(
        ApprovalRequest request,
        IWorkflowContext context,
        CancellationToken cancellationToken = default)
    {
        // Queue approval request to external system
        var approvalId = await QueueApprovalRequestAsync(request);

        // Wait for human response (could be hours/days)
        var response = await WaitForHumanResponseAsync(approvalId, cancellationToken);

        // Return approval result to workflow
        return new ApprovalResponse(request, response.Approved, response.Notes);
    }
}

Key Features:

Workflows can pause for hours or days
State persists across server restarts
Seamless integration with external approval systems
Full audit trail of approval decisions

7. Parallel Processing with Fan-Out/Fan-In

For tasks that require parallel execution, the fan-out/fan-in pattern enables efficient processing.

Example: Document Analysis

var workflow = new WorkflowBuilder(inputAgent)
    // Fan-out: Process input in parallel
    .AddFanOutEdge(inputAgent, [
        researchAgent,      // Researches the topic
        analysisAgent,      // Analyzes data
        summaryAgent,       // Creates summary
        citationAgent       // Generates citations
    ])
    // Fan-in: Wait for all to complete
    .AddFanInBarrierEdge([
        researchAgent,
        analysisAgent,
        summaryAgent,
        citationAgent
    ], mergeAgent)
    // Process merged results
    .AddEdge(mergeAgent, finalOutputAgent)
    .Build();

Benefits:

Reduces processing time through parallelism
Each agent specializes in a specific task
Automatic synchronization at merge point
Scalable across multiple machines

Running Durable Workflows Locally

For development, you can run the DTS emulator locally:

docker run -d --name dts-emulator \
  -p 8080:8080 -p 8082:8082 \
  mcr.microsoft.com/dts/dts-emulator:latest

Access the Dashboard:

API Endpoint: http://localhost:8080
Dashboard UI: http://localhost:8082

Conclusion

Durable Workflows in Microsoft Agent Framework enable you to build sophisticated AI-powered applications that:

Survive failures - State persists across restarts and crashes
Run for extended periods - Workflows can execute for minutes, hours, or days
Scale horizontally - Executors can run across multiple machines
Provide observability - Built-in dashboard for monitoring and debugging
Integrate with enterprise systems - Works with Azure, Microsoft 365, and more

Whether you're building customer support systems, content pipelines, enterprise orchestrations, or approval workflows, Durable Workflows provide the foundation for reliable, production-ready AI applications.

Ready to get started? Check out the Microsoft Agent Framework GitHub repository and the official documentation for more examples and tutorials.

This article is based on Microsoft's official documentation and blog posts from May 2026. All code examples are adapted from the official Microsoft Agent Framework samples.

Additional Resources

About the Author

This article was researched and written as part of a comprehensive technical blog series exploring the latest developments in .NET and AI agent frameworks.

LinkedIn Profile: https://www.linkedin.com/in/vikrant-bagal

Azure Functions vs Durable Functions: 2026 Use Cases and Performance Guide

Vikrant Bagal — Wed, 20 May 2026 21:19:14 +0000

Azure Functions

Azure Functions offers serverless event-driven computing with multiple hosting plans, while Durable Functions adds stateful orchestration for complex workflows. Choose Consumption for sporadic workloads, Premium for predictable performance, and Durable Functions for multi-step processes requiring reliability and checkpointing.

Introduction

Building distributed systems used to mean wrestling with infrastructure management, scaling policies, and server maintenance. What if you could focus purely on writing business logic while the platform handled everything else? That's the promise of Azure Functions in 2026 — but when should you use a basic function versus its Durable cousin? Understanding the differences can save you from cold start nightmares, budget overruns, and architectural regrets.

Azure Functions: Core Concepts and Triggers

Azure Functions is Microsoft's serverless compute service that enables you to run code in response to events without managing infrastructure. At its heart, every function requires a trigger — a specific event that initiates execution. Common triggers include HTTP requests for building APIs, timers for scheduled tasks, queue messages for asynchronous processing, and blob storage events for file processing pipelines.

The real power comes from bindings, which act as declarative connectors to other Azure services. Instead of writing boilerplate code to read from storage queues or send emails, you configure bindings that automatically handle the plumbing. Multiple input and output bindings can be combined in a single function, making it easy to build complex data flows with minimal code.

When to Use Basic Azure Functions

For straightforward, event-driven tasks that complete quickly, standard Azure Functions are ideal. Consider these common scenarios:

File Processing: Trigger when images are uploaded to blob storage, automatically generating thumbnails
API Endpoints: Create RESTful APIs that respond to HTTP requests
Queue Processing: Handle background tasks like sending emails or processing orders
Scheduled Maintenance: Run cleanup scripts on a cron-like schedule
Real-time Data Transformation: Modify streaming data before it reaches your database

[Function("HttpExample")]
public MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
{
    return new MultiResponse 
    {
        HttpResponse = new OkObjectResult("Success"),
        Messages = new string[] { "message" }
    };
}

public class MultiResponse 
{
    [QueueOutput("outqueue", Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }

    public IActionResult HttpResponse { get; set; }
}

Source: Microsoft Azure Functions documentation, basic function patterns

Durable Functions: Stateful Orchestration for Complex Workflows

When your workflow spans minutes, hours, or even days, basic functions fall short. Durable Functions is an extension that adds stateful coordination to the serverless model, enabling long-running workflows without managing infrastructure.

The Orchestrator Pattern

Durable Functions introduce three key function types:

Orchestrator Functions: Control the flow of execution, deciding which activities run and when
Activity Functions: Execute individual, stateless tasks within the workflow
Entity Functions: Manage state and enable actor-style programming for distributed objects

The magic lies in Durable Functions' ability to checkpoint execution state after each step. If a function fails or the app recycles, the workflow resumes exactly where it left off — no manual state management required.

Real-World Orchestration Use Cases

Order Processing Pipeline: Validate payment → Reserve inventory → Ship product → Send confirmation email
Data ETL Workflows: Extract from multiple sources → Transform with business logic → Load to data warehouse
Multi-step Approval Processes: Route document through managers → Collect signatures → Archive final version
IoT Data Aggregation: Collect sensor readings → Detect anomalies → Generate reports → Alert on critical issues
Customer Onboarding: Verify identity → Create accounts → Send welcome series → Schedule training sessions

[Function("OrderProcessingOrchestrator")]
public static async Task RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var order = context.GetInput<Order>();

    await context.CallActivityAsync<bool>("ValidatePayment", order);
    await context.CallActivityAsync<bool>("ReserveInventory", order);
    await context.CallActivityAsync<bool>("ShipProduct", order);
    await context.CallActivityAsync<bool>("SendConfirmation", order);
}

Source: Microsoft Azure Durable Functions documentation, orchestrator patterns

Choosing the Right Hosting Plan for 2026

Your hosting plan dramatically affects performance, cost, and functionality:

Consumption Plan

Best for: Sporadic workloads with unpredictable traffic
Pricing: Pay per execution with automatic scaling
Performance: May experience cold starts (5-10 seconds)
Limitations: Maximum 10-minute execution time per function

Premium Plan

Best for: Production applications requiring consistent performance
Features: Pre-warmed instances, VNET integration, faster cold starts
Pricing: Fixed cost per instance with premium features
Performance: Sub-second response times even after inactivity

Dedicated Plan

Best for: Enterprise workloads with strict compliance requirements
Features: Runs in your existing App Service Environment
Control: Full infrastructure control and predictable scaling
Cost: Higher base cost but predictable for large-scale deployments

For most new applications starting in 2026, the Consumption Plan remains the recommended entry point due to its cost efficiency and automatic scaling.

Common Pitfalls and How to Avoid Them

Even experienced developers encounter challenges with serverless architectures:

Cold Start Issues: Functions in Consumption Plan may experience latency on first execution. Mitigate this by using Premium Plan for latency-sensitive applications or implementing warm-up triggers.

Timeout Limitations: Consumption plan functions timeout after 5 minutes by default (maximum 10 minutes). For longer processes, use Durable Functions with orchestration or switch to Premium/ Dedicated plans.

State Management: Stateless functions require external storage for state persistence. Durable Functions solve this elegantly by checkpointing workflow state automatically.

Cost Management: Without proper monitoring, serverless functions can lead to unexpected costs. Implement Azure Budgets and monitor execution counts and duration closely.

Debugging Complexity: Distributed serverless applications are harder to debug. Leverage Azure Application Insights and structured logging from day one.

Best Practices for Production Deployment

Choose the Right Hosting Plan: Match your workload requirements — Consumption for variable traffic, Premium for predictable performance
Implement Comprehensive Error Handling: Functions should gracefully handle exceptions, implement retry logic, and provide meaningful error messages
Keep Functions Focused: Single responsibility functions are easier to test, debug, and scale
Leverage Bindings: Use input/output bindings instead of direct SDK clients for better performance and simpler code
Monitor Everything: Implement Azure Monitor and Application Insights for full observability
Use Durable Functions for Complex Workflows: Orchestrator functions provide reliability for multi-step processes
Test Locally: Azure Functions Core Tools enable local development and testing before deployment
Implement CI/CD: Automated deployment ensures consistency across environments and rapid rollback capabilities

Conclusion

Azure Functions continues to evolve as a powerful platform for event-driven serverless architecture in 2026. Whether you need simple HTTP endpoints or complex multi-day workflows with state management, there's a pattern that fits your needs. Start with basic functions for straightforward tasks, but don't hesitate to leverage Durable Functions when your workflows demand stateful coordination and reliability.

The key is understanding your specific requirements — traffic patterns, execution duration, state management needs, and cost constraints — before choosing your implementation approach.

What Azure Functions challenges have you encountered in your projects? Have you found Durable Functions essential for certain workflows, or do you prefer the simplicity of basic functions? Share your experiences in the comments below.

Connect on LinkedIn: https://www.linkedin.com/in/vikrant-bagal

Azure Functions: Complete Guide to Types, Use Cases & Differences (2026 Edition)

Vikrant Bagal — Tue, 19 May 2026 13:55:34 +0000

Microsoft's Azure Functions has evolved significantly since its launch. In 2026, developers have more hosting options than ever, each designed for specific workloads and scaling requirements. This comprehensive guide explores Azure Functions hosting plans, use cases, and how it compares to other serverless platforms.

What Is Azure Functions?

Azure Functions is Microsoft's serverless compute platform that enables developers to run event-driven code without managing infrastructure. You write your function code, deploy it, and Azure handles everything else—scaling, patching, and resource management.

The core promise remains unchanged: write code, deploy, and let the platform handle the rest. No servers to manage, no capacity planning, and you only pay for actual execution time.

Hosting Plans: Five Options for Every Scenario

Azure Functions offers five hosting options in 2026, each serving different needs and budgets.

1. Flex Consumption Plan (Recommended - Generally Available)

The Flex Consumption plan is the new recommended serverless hosting option that builds on the classic Consumption model while adding enterprise-grade features.

Key Features:

Reduced Cold Starts: Always-ready instances significantly improve startup latency
Virtual Network Integration: Connect to private resources securely
Per-Function Scaling: Each function scales independently for efficient resource allocation
Flexible Memory Options: Choose from 512 MB, 2,048 MB, or 4,096 MB instances
Azure Files Mounts: Mount file shares directly to access large binaries without packaging them
Maximum 1,000 Instances: Scale up to 1,000 instances (up from 200 in classic Consumption)

When to Use:

Serverless pay-as-you-go billing with enterprise requirements
Virtual network connectivity for secure access to Azure resources
Variable workloads with event-driven scaling needs
Custom compute memory optimization

Operating System: Linux only

Important: The classic Consumption plan is being phased out. For new serverless applications, use Flex Consumption instead.

2. Premium Plan (Generally Available)

The Premium plan provides pre-warmed workers that eliminate cold starts and offer more powerful instances.

Key Features:

Always-Warm Instances: Prewarmed workers run continuously, eliminating cold start latency
More Powerful Compute: Access to more CPU and memory than Consumption plans
Virtual Network Support: Full VNet connectivity for enterprise scenarios
Linux Container Support: Deploy custom container images
Unlimited Execution Duration: No maximum timeout (within practical limits)
Scale: 20-100 instances (Linux) or 100 instances (Windows)

When to Use:

Function apps that run continuously or nearly continuously
High number of small executions with execution-based billing concerns
Need more CPU or memory options than Consumption plans
Code requiring longer execution times
Virtual network connectivity requirements
Custom Linux container images

Operating System: Linux and Windows

3. Dedicated Plan (Generally Available)

The Dedicated plan runs functions within an App Service plan at regular App Service plan rates.

Key Features:

Predictable Billing: Fixed monthly costs regardless of execution volume
Manual or Autoscale: Full control over scaling behavior
Larger Compute Sizes: Access to bigger VM sizes
App Service Environment (ASE): Full compute isolation and secure network access
Maximum 30 Instances (100 with ASE)

When to Use:

Existing underutilized VMs running other App Service instances
Fully predictable billing requirements
Running multiple web apps and function apps on the same plan
Large compute size requirements
High memory usage and scale scenarios

Operating System: Linux and Windows

4. Container Apps (Generally Available)

Container Apps enables deploying containerized function apps in a fully managed environment.

Key Features:

Container-Only Deployment: Full control of container images
Microservices Integration: Run alongside other microservices, APIs, and websites
Custom Libraries: Package custom libraries with your function code
GPU Compute: Access to GPU resources for intensive workloads
Maximum 300-1,000 Instances

When to Use:

Full control over container images
Migrating from on-premises or legacy applications
Avoiding Kubernetes cluster complexity
High-end processing with GPU requirements

Operating System: Linux only (container-only)

5. Consumption Plan (Legacy - Being Retired)

The original Consumption plan offers pay-as-you-go billing with automatic scale.

Important Notes:

⚠️ Linux Consumption retiring September 30, 2028
⚠️ v3 runtime on Linux stops running after September 30, 2026
Maximum 200 instances (Windows) or 100 instances (Linux)

Recommendation: Migrate to Flex Consumption plan for new serverless applications.

Operating System: Windows (legacy) / Linux (retiring)

.NET Execution Models

Azure Functions for .NET supports two execution models, with important differences in 2026.

In-Process Model (Ending Support)

The in-process model runs function code in the same process as the Functions host.

Status: Support ends November 10, 2026

Key Characteristics:

Only supports .NET 8 for runtime v4.x
Uses Microsoft.NET.Sdk.Functions package
Simpler model but limited to LTS .NET versions

Isolated Worker Model (Recommended)

The isolated worker model runs function code in a separate .NET worker process.

Key Characteristics:

Supports .NET 8, 9, 10, and .NET Framework 4.8
Uses Microsoft.Azure.Functions.Worker and Microsoft.Azure.Functions.Worker.Sdk
Middleware support
Improved dependency injection
Supports .NET Aspire (Preview)
Required for Flex Consumption plan

Migration Required: All .NET applications should migrate from in-process to isolated worker model before November 10, 2026.

Runtime Versions

Azure Functions currently supports two runtime versions:

Version 4.x (Recommended)

General Availability (GA)
Recommended for all languages and scenarios
Supports latest language versions

Version 1.x (Ending Support)

Support ends September 14, 2026
Only for C# apps using .NET Framework 4.8
Maintenance mode only

Retired Versions

Version 2.x and 3.x are out of support
Linux v3 apps in Consumption plan stop running: September 30, 2026

Key Concepts

Cold Start: The latency when a function hasn't been invoked recently and the platform needs to spin up a new execution environment.

Always-Ready Instances: Configured instances that are always running to reduce cold start latency (available in Flex Consumption and Premium plans).

Per-Function Scaling: Flex Consumption feature where each function scales independently based on its workload.

Execution Time: The amount of time your function code is actively running.

GB-Seconds: Billing unit representing memory (GB) multiplied by execution time (seconds).

Real-World Use Cases

1. File Upload Processing

Scenario: Validate, transform, and process files uploaded to blob storage.

Example: A retail solution where partners submit product catalog files. A blob-triggered function automatically validates, transforms, and processes the files into the main system.

Triggers: Blob Storage trigger (Event Grid based)

Code Example:

[Function("ProcessCatalogData")]
public static async Task Run(
    [BlobTrigger("catalog-uploads/{name}", Source = BlobTriggerSource.EventGrid,
     Connection = "StorageConnection")] Stream myCatalogData,
    string name, ILogger log)
{
    log.LogInformation($"Processing blob: {name}, Size: {myCatalogData.Length} Bytes");

    using (var reader = new StreamReader(myCatalogData))
    {
        var catalogEntry = await reader.ReadLineAsync();
        while(catalogEntry != null)
        {
            // Process catalog entry
            catalogEntry = await reader.ReadLineAsync();
        }
    }
}

2. Real-Time Stream Processing

Scenario: Process data from cloud applications, IoT devices, or networking devices in near real-time.

Example: Hot path processing of event streams with output to Cosmos DB for analytics dashboards.

Triggers: Event Hubs, Kafka, Event Grid

Code Example:

[Function("ProcessorFunction")]
public static async Task Run(
    [EventHubTrigger("%Input_EH_Name%", Connection = "InputEventHubConnectionSetting",
     ConsumerGroup = "%Input_EH_ConsumerGroup%")] EventData[] inputMessages,
    [EventHub("%Output_EH_Name%", Connection = "OutputEventHubConnectionSetting")]
     IAsyncCollector<SensorDataRecord> outputMessages,
    PartitionContext partitionContext, ILogger log)
{
    var debatcher = new Debatcher(log);
    var debatchedMessages = await debatcher.Debatch(inputMessages, partitionContext.PartitionId);

    var xformer = new Transformer(log);
    await xformer.Transform(debatchedMessages, partitionContext.PartitionId, outputMessages);
}

3. Machine Learning and AI

Scenario: Build intelligent applications with AI integration using Azure OpenAI.

Features:

Azure OpenAI binding extension
Retrieval-Augmented Generation (RAG)
Model deployment
Custom MCP servers

Example: Image classification with TensorFlow or PyTorch models, text summarization using AI Cognitive Language Service, or semantic search integration.

4. Web APIs

Scenario: Build event-driven web APIs that react to critical events.

Triggers: HTTP trigger

Example: RESTful APIs with database integration, database changes, or event streams.

5. Database Changes

Scenario: React to changes in Cosmos DB or other databases.

Triggers: Cosmos DB trigger

Example: Real-time data synchronization and change feed processing.

Azure Functions vs AWS Lambda vs Google Cloud Functions (2026 Comparison)

Runtime Support

Feature	AWS Lambda	Azure Functions	Google Cloud Functions
Languages	Node.js, Python, Java, Go, Ruby, .NET, Custom	Node.js, Python, Java, C#, PowerShell, TypeScript, Custom	Node.js, Python, Go, Java, Ruby, PHP, .NET
Custom Runtimes	Lambda Layers	Custom Handlers	Limited support
Max Timeout	15 minutes	Unlimited (Premium)	60 minutes (2nd gen)
Max Memory	10,240 MB	14 GB (Premium)	32 GB (2nd gen)
Deployment Size	250 MB (unzipped)	1.5 GB	500 MB

Cold Start Performance (2026)

AWS Lambda:

Node.js: 200-400ms cold starts
Java: 2-3 seconds (improved with SnapStart)
Provisioned Concurrency available (expensive)

Azure Functions:

Consumption plan: Similar to AWS
Premium plan: Pre-warmed instances eliminate cold starts
Flex Consumption: Reduced cold starts with always-ready instances

Google Cloud Functions 2nd Gen:

Built on Cloud Run
Python/Node.js: Under 200ms cold starts
Minimum instances feature keeps functions warm

Deployment Models

AWS Lambda: Deploys all functions in Lambda environment on Amazon Linux servers. Function deployment limited to Lambda service.

Azure Functions: More flexible - deploy code directly or run inside Docker containers. Can deploy to Windows or Linux servers.

Google Cloud Functions: Functions stored in Google Container Registry and executed as containers.

Observability

AWS CloudWatch: Basic monitoring, X-Ray for tracing, often requires third-party tools

Azure Monitor + Application Insights: Superior out-of-the-box observability with automatic instrumentation and KQL query language

Google Cloud Operations Suite: Excellent monitoring with Cloud Trace and Profiler

VPC/Networking

AWS Lambda: VPC integration improved, minimal cold start penalty, VPC endpoints available

Azure Functions: VNet integration only in Premium and Container Apps plans (not in Consumption)

Google Cloud Functions: VPC connectors available, straightforward setup but adds cost

Decision Guide: Which Plan Should You Choose?

Choose Flex Consumption If:

You're starting a new serverless application
You need virtual network connectivity
You want reduced cold starts with always-ready instances
You need per-function scaling
You're building on Linux

Choose Premium Plan If:

Your function apps run continuously or nearly continuously
You need more CPU/memory options than Consumption plans
You require unlimited execution duration
You need VNet connectivity
You want custom Linux containers

Choose Dedicated Plan If:

You have existing underutilized VMs
You need fully predictable billing
You want to run multiple web apps on the same plan

Choose Container Apps If:

You need full control over container images
You're migrating from on-premises applications
You need GPU compute resources

Choose AWS Lambda If:

You're already invested in AWS ecosystem
You need the broadest range of event sources
You need the most mature serverless platform

Choose Google Cloud Functions If:

You value simplicity
You want excellent cold start performance
You're building on Google Cloud Platform

Migration Strategies

When switching between platforms or plans:

Abstract business logic from platform-specific code using the adapter pattern
Keep functions small and focused for easier migration
Use environment variables for configuration rather than platform-specific features
Consider Serverless Framework for multi-cloud deployments
Test under realistic load before migrating production traffic
Use feature flags for gradual traffic shift with quick rollback capability

Important Dates to Remember (2026)

September 14, 2026: Azure Functions v1.x runtime support ends
September 30, 2026: v3 runtime on Linux Consumption stops running
November 10, 2026: In-process model support ends
September 30, 2028: Linux Consumption plan retires

Conclusion

Azure Functions in 2026 offers mature, flexible serverless computing with multiple hosting options for every scenario. The new Flex Consumption plan represents the future of serverless on Azure, combining pay-as-you-go economics with enterprise features like VNet integration and per-function scaling.

When choosing between Azure Functions, AWS Lambda, and Google Cloud Functions, consider your existing cloud ecosystem, specific feature requirements, and team expertise. Azure Functions excels for .NET developers, observability, and scenarios requiring unlimited execution duration on Premium plans.

The key to successful serverless adoption is starting small, understanding pricing models, and continuously monitoring performance and costs.

Useful Resources:

This guide was researched and written in May 2026 using the latest Microsoft documentation and serverless platform comparisons.

How to structure your project folder to use, Coding Agents like Claud code, open code more efficiently

Vikrant Bagal — Fri, 15 May 2026 22:57:57 +0000

How I Structure Project Folders So Coding Agents Actually Work

TL;DR: The difference between an agent that feels like a senior teammate and one that hallucinates broken imports comes down to four things: an AGENTS.md file, progressive disclosure of context, feature-localized folder structure, and agent-specific config folders. Skip these and you'll burn tokens on re-explaining your stack every session. Adopt them and you'll cut rephrasing by 25% and framework errors by 90%.

Introduction

Six months ago, I watched a demo where someone told Claude Code to "add a user profile page" and it built the route, the component, the database migration, and the tests in one shot without being told the tech stack. I tried the same thing on my project and got back a file written in Vue when I use React, a database query against a table that doesn't exist, and a test framework I don't have installed. The difference wasn't the tool—it was the project structure.

Coding agents are only as good as the context you give them. And the most efficient way to give them context isn't to type it out each session—it's to bake it into your folder layout. Here's exactly how I do it.

1. Start with an Agent Instruction File (`AGENTS.md`)

Every agent needs a persistent memory file at the project root. For OpenCode it's AGENTS.md; for Claude Code it's CLAUDE.md. This file is read automatically at session start, telling the agent your tech stack, folder conventions, build commands, and rules—so you never have to repeat yourself.

Here's the structure I use, adapted from the official Claude Code best practices:

# Project conventions
- Language: TypeScript strict
- Framework: Next.js 15 App Router
- Tests: Vitest + Testing Library
- Style: Prettier + ESLint flat config

# Code rules
- No TypeScript `any`
- Functional components only
- File names in kebab-case

# Commands
- Build: `npm run build`
- Dev: `npm run dev`
- Test single: `npx vitest run --reporter=verbose`
- Lint: `npm run lint`

# Architecture
- Components in `src/components/`
- API routes in `src/app/api/`
- Database schema in `prisma/schema.prisma`
- Shared utils in `src/lib/`

The impact is measurable. According to the SFEIR Institute, a well-structured instruction file reduces time spent rephrasing by 25%, eliminates 90% of framework-related errors, and improves code style consistency by 70%. Those aren't marketing numbers—they're from teams that measured before and after.

⚠️ Watch the 200-line ceiling. If your AGENTS.md exceeds 200 lines, split it into imported files. Otherwise you're eating into the agent's context window before it even starts working.

2. Use Progressive Disclosure to Avoid Context Bloat

The biggest mistake I see is dumping everything into a single instruction file. Agents have a limited context window, and past 40% capacity, output quality degrades considerably—I've seen this called the "40% Rule" in practice.

Instead, structure your context in layers:

Root AGENTS.md — lightweight, points to more detailed files

# Project conventions
[tech stack, rules, commands — keep under 100 lines]

# Detailed references (load on demand)
- API patterns: `docs/guides/api-patterns.md`
- Database conventions: `docs/guides/db-conventions.md`
- Component standards: `docs/guides/components.md`

When the agent needs to implement a feature, it reads the pointer file, then fetches only the relevant deep reference. The rest stays out of the context window.

One developer I know (Mike Bayly) had a vault-level instruction file that consumed 2,000 tokens every session—even when editing a single file. Restructuring with progressive disclosure eliminated that waste entirely.

3. Layout Code by Feature, Not by Layer

This is the structural change with the highest payoff. Instead of this:

src/
  controllers/
  services/
  models/
  routes/

Use vertical slices:

features/
  users/
    users.controller.ts
    users.service.ts
    users.model.ts
    users.routes.ts
  billing/
    billing.controller.ts
    billing.service.ts
    billing.model.ts
    billing.routes.ts

Why it matters for agents: When you ask an agent to "add a payment method to billing," it needs to read the billing slice. If you use layer-based structure, the agent has to read controllers/billing.ts, services/billing.ts, models/billing.ts, and routes/billing.ts from three directories away. With vertical slices, everything lives in one folder. That's fewer file reads per task, which means less token consumption and faster completions.

Tim Deschryver rewrote an entire ASP.NET API + Angular frontend using this approach with AI agents. He explicitly credits the pre-defined folder structure (Vertical Slice Architecture) as critical to success. Sid Saladi, who reviewed dozens of Claude Code projects, calls messy folder structure the top reason agents behave like "confused interns."

⚠️ Don't take this advice halfway. A hybrid structure (some features grouped, others layered) confuses agents more than a consistent layered layout. Pick one pattern and enforce it.

4. Create Agent-Specific Configuration Folders

Your main source code shouldn't be cluttered with agent configuration. Use hidden directories at the project root:

.claude/
  commands/
  skills/
  agents/
  rules/
  output-styles/

Or for OpenCode:

.opencode/

And for Cursor:

.cursor/
  rules/

These folders keep agent configuration version-controlled and shareable across the team, separate from source code. I keep reusable skills there—security review prompts, SEO analysis workflows, component audit templates—that I can invoke by name during a session.

Ran Isenberg, an AWS Serverless Hero, rebuilt his entire consulting brand website using Claude Code and structured his project this way. He found that MCP servers could be replaced entirely by well-written .md skill files in .claude/skills/—more transparent and easier to audit.

5. Run `/init` to Bootstrap, Then Refine

Both Claude Code and OpenCode ship a /init command that scans your project's package.json, folder structure, lint configs, test frameworks, and git history, then auto-generates a starter AGENTS.md or CLAUDE.md.

Start every new project with:

/init

Then refine the output. Delete what's irrelevant. Add your specific rules. Split long files as described above. The command gives you a 70% complete first draft, and you finish the last 30% by hand.

The Proven Template

After reviewing dozens of agent-friendly projects (including Anthropic's internal engineering teams and the community skills ecosystem), here's the layout I now reach for on every new project:

project-root/
  AGENTS.md              # < 200 lines, lightweight pointer
  src/
    features/            # vertical slices
      users/
      billing/
      notifications/
  docs/
    guides/              # deep reference files for agents
  .claude/
    skills/              # reusable skill files
    commands/
  .cursor/
    rules/               # scoped rule files for Cursor

Over 160,000 repositories now contain a CLAUDE.md file and over 25,000 contain .cursorrules as of mid-2025. The ecosystem is converging on this pattern because it works.

What to Try Next

Stop treating your agent like a search engine that you describe your codebase to each session. Instead, treat your project structure as the permanent briefing document. Spend one hour setting up AGENTS.md, vertical slices, and .claude/ folders. Then measure how many fewer iterations you need to complete a task.

If you've already tried this, I want to know: what rule in your AGENTS.md saved you the most time? Drop it in the comments—I'm always looking for new patterns to steal.

Connect on LinkedIn: https://www.linkedin.com/in/vikrant-bagal

MCP (Model Context Protocol) for .NET Devs — What It Is and Why You'll Be Using It Soon

Vikrant Bagal — Fri, 15 May 2026 19:02:52 +0000

Every major AI tool is adopting MCP. If you build .NET APIs, this is the integration pattern coming your way.

What Is MCP?

MCP (Model Context Protocol) is an open-standard protocol designed to standardize integrations between AI applications and external tools and data sources. Think of it as the universal language that allows AI assistants to safely and securely connect to your .NET applications, databases, and APIs.

Originally developed by Anthropic in partnership with Microsoft, MCP provides a structured way for AI systems to:

Discover capabilities across different systems
Execute actions through external tools
Exchange structured context without custom integrations

The protocol is built on JSON-RPC 2.0, ensuring interoperability across platforms and tools.

Why MCP Matters for .NET Developers

If you're building APIs, microservices, or AI-powered applications with .NET, MCP is becoming the de facto standard for AI-tool communication. Here's why:

1. Microsoft's Full Backing

Microsoft is actively supporting MCP across its ecosystem:

Copilot Studio now supports MCP integrations
Visual Studio Code with GitHub Copilot agent mode uses MCP
Agent Framework integrates with MCP servers
Azure Functions supports remote MCP servers

This means your .NET applications can now communicate with AI agents in a standardized way.

2. Standardized AI Communication

Before MCP, every AI tool required custom integration code. MCP eliminates this by providing:

Unified protocol for all AI tools
Security-first design with explicit user consent
Composable architecture allowing multiple servers
Progressive enhancement for adding new features

3. Production-Ready .NET SDK

The official MCP C# SDK is available through NuGet and maintained by Microsoft in collaboration with Anthropic:

dotnet add package ModelContextProtocol --prerelease

This gives you everything you need to create MCP clients and servers in .NET.

The MCP Architecture

MCP follows a client-host-server architecture that's familiar to .NET developers:

Host

The host is your AI application (like GitHub Copilot in VS Code). It:

Creates and manages client instances
Handles security policies and user consent
Coordinates AI integration and sampling

Client

The client connects to MCP servers. It:

Establishes stateful sessions per server
Handles protocol negotiation
Routes messages between host and server

Server

The server exposes your .NET application's capabilities. It:

Provides tools, resources, and prompts
Operates independently with focused responsibilities
Can be local processes or remote services

Building Your First MCP Server in .NET

Creating an MCP server is surprisingly straightforward. Here's a basic stdio-based server:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);
builder.Logging.AddConsole(consoleLogOptions =>
{
    consoleLogOptions.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class EchoTool
{
    [McpServerTool, Description("Echoes the message back to the client.")]
    public static string Echo(string message) => $"Hello from C#: {message}";
}

What's happening here?

Host.CreateApplicationBuilder - Sets up dependency injection and hosting
AddMcpServer() - Registers the MCP server with DI
WithStdioServerTransport() - Configures stdio communication
WithToolsFromAssembly() - Auto-discovers tools marked with attributes
McpServerToolType - Marks a class as containing MCP tools
McpServerTool - Marks a method as an MCP-accessible tool

The Description attribute becomes part of the tool's metadata, helping AI models understand what each tool does.

Exposing Your .NET APIs with MCP

Let's say you have a Monkey API (because everyone needs one 🐒). Here's how to expose it via MCP:

public class MonkeyService
{
    private readonly HttpClient httpClient;
    public MonkeyService(IHttpClientFactory httpClientFactory)
    {
        httpClient = httpClientFactory.CreateClient();
    }

    public async Task<List<Monkey>> GetMonkeys()
    {
        var response = await httpClient.GetAsync("https://api.example.com/monkeys");
        // ... process and return monkeys
    }

    public async Task<Monkey?> GetMonkey(string name)
    {
        var monkeys = await GetMonkeys();
        return monkeys.FirstOrDefault(m => m.Name == name);
    }
}

[McpServerToolType]
public static class MonkeyTools
{
    [McpServerTool, Description("Get a list of all monkeys.")]
    public static async Task<string> GetMonkeys(MonkeyService service)
    {
        var monkeys = await service.GetMonkeys();
        return JsonSerializer.Serialize(monkeys);
    }

    [McpServerTool, Description("Get details for a specific monkey.")]
    public static async Task<string> GetMonkey(MonkeyService service, 
        [Description("The name of the monkey")] string name)
    {
        var monkey = await service.GetMonkey(name);
        return JsonSerializer.Serialize(monkey);
    }
}

Now AI assistants can query your monkey database through a standardized interface!

HTTP Transport for ASP.NET Core

For web APIs, you can use HTTP transport:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddMcpServer()
    .WithHttpTransport(options =>
    {
        options.Stateless = true;
    })
    .WithToolsFromAssembly();

var app = builder.Build();
app.MapMcp();
app.Run("http://localhost:3001");

This is perfect for exposing your existing ASP.NET Core APIs to AI tools without major refactoring.

Real-World Integrations

The MCP ecosystem already includes servers for:

Git - Version control operations
GitHub - Repository management
Playwright - Browser automation
Filesystem - Local file operations
Databases - SQL/NoSQL queries
Azure Services - Storage, Cosmos DB, etc.

You can also build custom MCP servers for your specific APIs, databases, or internal systems.

Security Considerations

MCP is designed with security first:

Explicit User Consent - Every tool invocation requires user approval
Data Privacy - Resources only share what's explicitly permitted
Tool Safety - Arbitrary code execution with proper safeguards
Sampling Controls - Users control LLM interaction parameters

As a .NET developer, you should:

Always implement proper authorization
Use least-privilege access for resources
Log and audit all tool invocations
Follow security best practices for your specific domain

Deployment Options

Local Development

Use stdio transport for local processes or ASP.NET Core HTTP servers.

Cloud Deployment

Azure Container Apps - Managed container hosting
Azure Functions - Serverless MCP servers
Docker - Multi-arch container images

Publishing a containerized MCP server:

<PropertyGroup>
    <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
    <ContainerRepository>myorg/mcp-server</ContainerRepository>
    <ContainerFamily>alpine</ContainerFamily>
    <RuntimeIdentifiers>linux-x64;linux-arm64</RuntimeIdentifiers>
</PropertyGroup>

Then deploy with:

dotnet publish /t:PublishContainer

The Future Is Here

MCP isn't just another API standard—it's becoming the universal protocol for AI-tool communication. Every major AI platform is adopting it:

GitHub Copilot
Claude
Cursor
Windsurf
And many more

As a .NET developer, learning MCP now positions you perfectly for the AI-integrated future. Whether you're building APIs, microservices, or AI-powered applications, MCP provides the standard interface that makes your .NET code accessible to AI agents.

Getting Started

Install the SDK: dotnet add package ModelContextProtocol --prerelease
Read the docs: Microsoft Learn - Get started with .NET AI and MCP
Explore examples: MCP C# SDK samples
Build your first server: Start with a simple echo tool and expand from there

The MCP revolution is happening now. Are you ready to join it?

Connect with me on LinkedIn: https://www.linkedin.com/in/vikrant-bagal

.NET Design Patterns Deep Dive: What Still Matters in 2026

Vikrant Bagal — Thu, 14 May 2026 15:44:02 +0000

Design patterns have been a cornerstone of object-oriented software development for decades. Yet, with the evolution of .NET — from .NET Framework to .NET 10, C# 14, and the rise of cloud-native architectures — the relevance of each pattern has shifted dramatically. This deep dive explores which design patterns remain essential in modern .NET development, which have become anti-patterns, and how to apply them effectively for performance, maintainability, and scalability.

Why Design Patterns Still Matter

In 2026, the .NET ecosystem is richer than ever. From high‑performance services to AI‑driven applications, the underlying principles of good software design remain constant: separation of concerns, testability, and adaptability. Design patterns provide a shared vocabulary and proven solutions to recurring problems. However, blindly applying “textbook” patterns can lead to over‑engineered, rigid systems. As the industry has matured, we now recognize that context is king — the right pattern depends on the problem, the scale, and the team’s expertise.

The Three Pillars of Design Patterns

1. Creational Patterns

These patterns control object creation, aiming to increase flexibility and reduce coupling.

Singleton – Ensures a single instance exists globally.
Factory Method – Delegates instantiation to subclasses.
Abstract Factory – Creates families of related objects.
Builder – Separates construction from representation.
Prototype – Creates objects by cloning.

2. Structural Patterns

These patterns define how objects are composed to form larger structures.

Adapter – Bridges incompatible interfaces.
Decorator – Adds responsibilities dynamically.
Facade – Simplifies complex subsystems.
Proxy – Controls access to another object.
Composite – Treats individual and composite objects uniformly.

3. Behavioral Patterns

These patterns manage communication and responsibility between objects.

Strategy – Encapsulates interchangeable algorithms.
Observer – Notifies dependents of state changes.
Command – Encapsulates requests as objects.
State – Alters behavior when internal state changes.
Chain of Responsibility – Passes requests along a chain.

Patterns That Matter in 2026

Singleton: Still Useful, But Use Sparingly

The Singleton pattern is still relevant for resources that truly require a single instance (e.g., logging, configuration). However, modern .NET encourages dependency injection (DI) as the default mechanism for managing lifetimes. Overusing Singleton can break testability and introduce hidden dependencies. Best practice: Use DI containers (like Microsoft.Extensions.DependencyInjection) to register services as singletons when appropriate, rather than implementing a manual Singleton.

Factory Method & Abstract Factory: Essential for Extensibility

With plug‑in architectures and runtime polymorphism, Factory patterns remain vital. In .NET, they’re often implemented via interfaces and DI. For example, a payment gateway factory can switch between Stripe, PayPal, or a mock implementation based on configuration.

public interface IPaymentProcessor { Task<PaymentResult> ProcessAsync(decimal amount); }
public class StripeProcessor : IPaymentProcessor { /* ... */ }
public class PayPalProcessor : IPaymentProcessor { /* ... */ }

public class PaymentProcessorFactory
{
    private readonly IServiceProvider _serviceProvider;
    public IPaymentProcessor Create(string provider) => 
        provider switch
        {
            "Stripe" => _serviceProvider.GetRequiredService<StripeProcessor>(),
            "PayPal" => _serviceProvider.GetRequiredService<PayPalProcessor>(),
            _ => throw new ArgumentException("Unknown provider")
        };
}

Builder: Fluent APIs and Immutable Objects

The Builder pattern shines when constructing complex objects, especially immutable ones. Modern C# records and init‑only properties pair perfectly with builders. Entity Framework Core’s DbContextOptionsBuilder is a prime example.

Repository & Unit of Work: Overused, Still Valuable

The Repository pattern (abstracting data access) and Unit of Work (transaction management) are ubiquitous in .NET applications. However, they are often misapplied — adding business logic inside repositories violates separation of concerns. Use repositories only as a data‑access abstraction; keep business rules in the domain layer.

Strategy: Dynamic Behavior at Runtime

Strategy is one of the most powerful patterns for modern applications. It eliminates long if‑else chains and enables runtime behavior changes. Discount calculations, caching strategies, and serialization formats are classic use cases.

Observer: Event‑Driven Architectures

With the rise of event‑driven systems, the Observer pattern is more relevant than ever. .NET events, IObservable<T>, and message brokers (RabbitMQ, Azure Service Bus) all leverage this pattern for loose coupling.

Decorator: Cross‑Cutting Concerns

Decorator is ideal for adding cross‑cutting concerns like logging, caching, and authentication. ASP.NET Core middleware uses a similar concept, and the HttpClient pipeline employs DelegatingHandler (a decorator‑like pattern) for retries and circuit breaking.

Performance‑Oriented Patterns

High‑performance .NET applications require patterns that minimize allocations, improve cache locality, and reduce GC pressure.

Pooling (ArrayPool, MemoryPool)

Allocating arrays and buffers in hot paths can cause GC pressure. ArrayPool<T> and MemoryPool<T> provide shared pools of reusable buffers. Benchmark results show 50% reduction in allocations and 30% faster execution when using pooled arrays instead of new byte[].

var pool = ArrayPool<byte>.Shared;
byte[] buffer = pool.Rent(4096);
try
{
    // Use buffer
}
finally
{
    pool.Return(buffer);
}

Struct of Arrays (Data‑Oriented Design)

When processing large collections, an “array of structs” leads to poor cache locality. A “struct of arrays” (SoA) layout can improve performance by 10×. This pattern is used in high‑performance game engines and scientific computing.

public class CustomerRepositoryDOD
{
    private double[] _scoring;
    private double[] _earnings;
    private bool[] _isSmoking;
    // ...
}

Stack‑Based Allocation

stackalloc, Span<T>, and ref struct allow stack allocation, eliminating GC overhead. They are essential for parsing, serialization, and network protocols.

Span<byte> buffer = stackalloc byte[256];
// Process buffer without heap allocations

Zero‑Copy Slicing

Span<T> and Memory<T> enable zero‑copy slicing of arrays, strings, and unmanaged memory. This pattern reduces memory copies and improves throughput in high‑volume scenarios (e.g., HTTP request processing).

Real‑World Usage Examples

Microsoft C# Dev Kit – Replaced C++ with C# for Node.js addons using Native AOT, leveraging design patterns for interop and performance.
ASP.NET Core – Uses ArrayPool for Kestrel’s request/response buffers, reducing GC pauses by 80%.
Entity Framework Core – Implements Unit of Work and Repository patterns internally, with DbContext as the unit of work.
.NET Aspire – Employs microservice patterns (service discovery, health checks) with minimal configuration.
Roslyn – Uses object pooling for syntax nodes, dramatically reducing memory allocation during compilation.

Common Pitfalls and Anti‑Patterns

Singleton overuse – Leads to hidden dependencies and hinders testing.
Repository abuse – Placing business logic in repositories creates “fat repositories” and violates domain‑driven design.
Pattern shopping – Applying a pattern because “it sounds cool” without a concrete problem.
Ignoring performance patterns – Allocating excessively in hot paths causes GC‑induced latency spikes.
Neglecting dependency inversion – Tight coupling between layers makes swapping implementations difficult.

Best Practices for Modern .NET

Prefer composition over inheritance – Use interfaces and DI to assemble objects.
Leverage dependency injection – Let the container manage lifetimes; avoid manual Singletons.
Follow the Dependency Inversion Principle – Depend on abstractions, not concretions.
Choose patterns contextually – Use Singleton for truly single resources, Factory for extensibility, Strategy for runtime behavior.
Measure before optimizing – Use profiling tools (dotTrace, PerfView) to identify bottlenecks.
Embrace modern C# features – Span<T>, Memory<T>, ref struct, and record types enhance pattern implementations.
Document pattern usage – Ensure team members understand the why and how.
Continuously refactor – Patterns should evolve with requirements; don’t let them become constraints.

Conclusion

Design patterns are not obsolete — they have evolved. In 2026, the .NET developer’s toolkit includes powerful frameworks, high‑performance primitives, and cloud‑native patterns. By understanding which patterns still matter and applying them judiciously, you can build maintainable, scalable, and performant systems.

The key is to start with the problem, not the pattern. Let the problem guide your choice, and always consider the trade‑offs. With the right patterns, you can harness the full potential of modern .NET.

Connect with me:
[www.linkedin.com/in/vikrant-bagal]

10 .NET Open Source Libraries Every Developer Should Know in 2026

Vikrant Bagal — Thu, 14 May 2026 15:41:55 +0000

The .NET ecosystem keeps evolving, and 2026 is no exception. Whether you're building APIs, CLIs, or cloud-native microservices, the right open source library can save you weeks of work. Here are 10 libraries that are dominating NuGet downloads and GitHub stars this year—spanning battle-tested essentials to rising stars you'll want on your radar.

1. Polly — Resilience Made Fluent

If your app talks to external services, you need Polly. It provides retry, circuit breaker, timeout, bulkhead isolation, and fallback policies—all composed in a fluent API.

var pipeline = new ResiliencePipelineBuilder<HttpResponseMessage>()
    .AddRetry(new RetryStrategyOptions<HttpResponseMessage>
    {
        MaxRetryAttempts = 3,
        Delay = TimeSpan.FromMilliseconds(500),
        BackoffType = DelayBackoffType.Exponential
    })
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions<HttpResponseMessage>
    {
        FailureRatioThreshold = 0.5,
        SamplingDuration = TimeSpan.FromSeconds(30)
    })
    .Build();

Why it matters: Distributed systems fail. Polly makes your app survive those failures gracefully instead of cascading errors to users.

GitHub: App-vNext/Polly

2. Serilog — Structured Logging That Actually Makes Sense

Forget text-based logging. Serilog emits structured events with properties you can query, filter, and aggregate in tools like Seq, Elasticsearch, or Datadog.

Log.Information("Order {OrderId} placed by {UserId} for ${Total:C}", 
    order.Id, order.UserId, order.Total);

Why it matters: In production, you don't need "something went wrong." You need which order, which user, and what amount. Structured logging gives you that.

GitHub: serilog/serilog

3. FluentValidation — Validation as Code, Not Attributes

Data annotations are fine for simple rules. FluentValidation handles the complex ones—cross-field checks, async database lookups, and reusable rule sets.

public class OrderValidator : AbstractValidator<Order>
{
    public OrderValidator()
    {
        RuleFor(x => x.Items).NotEmpty().WithMessage("Order must have at least one item");
        RuleFor(x => x.Total).GreaterThan(0);
        RuleFor(x => x.ShippingAddress)
            .NotNull().When(x => x.RequiresShipping);
    }
}

Why it matters: Clean validation logic lives in its own class, testable and reusable—not scattered across controllers.

GitHub: FluentValidation/FluentValidation

4. MediatR — Decouple Your App with the Mediator Pattern

MediatR implements the mediator pattern, enabling CQRS-style separation without ceremony. Commands and queries flow through a single pipeline.

// Controller stays thin
[HttpPost]
public async Task<IActionResult> Create(CreateOrderCommand cmd)
    => Ok(await _mediator.Send(cmd));

// Handler lives in its own file
public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(CreateOrderCommand request, CancellationToken ct)
    {
        var order = new Order(request.UserId, request.Items);
        await _repo.AddAsync(order, ct);
        return order.Id;
    }
}

Why it matters: Controllers stay thin. Business logic stays isolated. And pipeline behaviors give you cross-cutting concerns (logging, validation) for free.

GitHub: jbogard/MediatR

5. Dapper — When EF Core Is Too Much

Dapper is a micro-ORM that extends IDbConnection with simple mapping methods. It's nearly as fast as raw ADO.NET—because it barely adds overhead.

var products = await connection.QueryAsync<Product>(
    "SELECT * FROM Products WHERE CategoryId = @catId",
    new { catId = 5 });

Why it matters: For high-throughput read scenarios, reporting queries, or when you want full control over your SQL, Dapper is the lightweight choice.

GitHub: DapperLib/Dapper

6. Spectre.Console — Beautiful CLIs Without the Pain

Building console apps used to mean fighting with Console.ForegroundColor. Spectre.Console changes everything with tables, progress bars, trees, prompts, and markup formatting.

AnsiConsole.MarkupLine("[bold green]Build succeeded![/]");
var table = new Table().Border(TableBorder.Rounded);
table.AddColumn("Project");
table.AddColumn("Status");
table.AddRow("API", "[green]✓[/]");
table.AddRow("Worker", "[red]✗[/]");
AnsiConsole.Write(table);

Why it matters: If you're building CLI tools, deployment scripts, or developer utilities, Spectre.Console makes them look professional with minimal effort.

GitHub: spectreconsole/spectre.console

7. TickerQ — Source-Generated Task Scheduling

TickerQ is a new entrant that's rapidly gaining traction. It's a reflection-free background task scheduler built with .NET source generators, EF Core integration, and a real-time dashboard.

[TickerTask("daily-report", Cron = "0 8 * * *")]
public class DailyReportTask : ITickerTask
{
    public async Task ExecuteAsync(CancellationToken ct)
        => await GenerateAndEmailReportAsync(ct);
}

Why it matters: No reflection overhead at runtime. Compile-time validation of cron expressions. And a built-in dashboard to monitor task execution.

GitHub: Arcenox-co/TickerQ

8. TUnit — The Modern .NET Test Framework

TUnit is a source-generated test framework designed to replace xUnit and NUnit. No reflection, no AppDomain complexity—tests are discovered at compile time.

[Test]
public async Task Calculator_Adds_TwoNumbers()
{
    var result = Calculator.Add(2, 3);
    await Assert.That(result).IsEqualTo(5);
}

Why it matters: Faster test discovery, parallel execution by default, and a fluent assertion API that reads naturally.

GitHub: thomhurst/TUnit

9. Facet — Source-Generated DTOs and Mappings

Facet generates DTOs, mappings, constructors, and LINQ projections from your domain models at compile time. No runtime reflection, no runtime mapping overhead.

[Facet(typeof(User))]
public partial class UserDto;
// Generates: UserDto with mapped properties, ToDto(), and LINQ projection support

Why it matters: AutoMapper's runtime mapping has a cost. Facet moves that cost to build time, and gives you LINQ projection support out of the box.

GitHub: Tim-Maes/Facet

10. RazorConsole — Agentic TUIs with .NET

RazorConsole is a 2026 standout. It combines .NET Razor templates with Spectre.Console to build interactive terminal UIs—including agentic TUIs that LLMs can drive.

Why it matters: As AI agents increasingly need to interact with developer tools, having a Razor-based TUI layer means agents can render rich output in terminals programmatically.

GitHub: RazorConsole/RazorConsole

The 2026 Trend: Source Generators Win

Notice the pattern? TickerQ, TUnit, and Facet all leverage .NET source generators instead of runtime reflection. This means:

Zero reflection overhead at runtime
Compile-time validation of configurations
Better AOT compatibility for Native AOT scenarios
IDE IntelliSense for generated code

If you're picking libraries in 2026, prefer the source-generated approach. It's the direction the entire .NET ecosystem is moving.

Which of these libraries are you already using? What did I miss? Drop a comment—I'd love to hear what's in your csproj this year.

Process API Improvements in .NET 11

Vikrant Bagal — Wed, 13 May 2026 22:04:36 +0000

Process Control Made Robust: How .NET 11 Revolutionizes Process Management

As a backend .NET developer who's spent too much time wrestling with process management, I'm thrilled to share how .NET 11 transforms what was once a major pain point. Remember those nights spent debugging deadlocked processes or hunting resource leaks? The .NET team has listened to our struggles and delivered a comprehensive overhaul to the System.Diagnostics.Process API that brings much-needed rigor and consistency to process handling.

The Pain Points of Process Management in .NET (Previous Versions)

Before diving into .NET 11's improvements, let's acknowledge the challenges we've faced:

Synchronous blocking calls: I've lost count of how many times stdout/stderr buffering has deadlocked my application
Insecure pipe handling: Missing explicit control over pipe resources in cross-platform scenarios
Inconsistent cross-platform behavior: CreateNoWindow = true acting differently across OSes
Process lifecycle tracking: Fragile HasExited implementation with race conditions
Resource leaks: Forgotten disposables leading to orphaned pipes and process handles

.NET 11: A Comprehensive Overhaul

The .NET 11 SDK introduces a radical redesign of the System.Diagnostics.Process namespace with four strategic improvements:

Enhanced pipe management with low-level control
Native async stream operations
Meaningful cancellation support
Cross-platform consistency

These improvements address real pain points with concrete implementations that replace workarounds and archaic patterns from previous .NET versions.

Pipe Management: From Chaos to Control

The largest upgrade comes in pipe management with the introduction of SafeFileHandle integration. This allows explicit ownership and manipulation of pipe resources through proper safe handle semantics.

SafeFileHandle Revolution

// Before .NET 11 - Legacy approach
process.StartInfo.RedirectStandardInput = true;

// After .NET 11
SafeFileHandle inputHandle = process.StandardInput.SafeFileHandle; 
SafeFileHandle outputHandle = process.StandardOutput.SafeFileHandle;

This unlocks powerful scenarios:

// Demonstrating raw pipe access for advanced scenarios
[DllImport("kernel32.dll")]
static extern bool SetNamedPipeHandleState(
    IntPtr hPipe, 
    ref uint lpMode, 
    IntPtr lpMaxCollectionBytes, 
    IntPtr lpCollectData);

// In your process handling code
SafeFileHandle pipeHandle = process.StandardInput.SafeFileHandle;
uint newMode = FILE_MODE.BACKGROUND; // Custom flag

if (SetNamedPipeHandleState(
        pipeHandle.DangerousGetHandle(),
        ref newMode,
        IntPtr.Zero, 
        IntPtr.Zero))
{
    // Pipe configuration successful
}

Non-Seekable Handling

The new ReadAsync(byte*, int) and WriteAsync(ReadOnlyMemory<byte>) methods enable direct memory operations through pipes:

// Efficient raw byte processing
await process.StandardOutput.ReadAsync(buffer, token);
await process.StandardInput.WriteAsync(payload, token);

Stream Operations: Asynchronous Excellence

The new ReadToEndAsync() and WriteAsync() methods with cancellation tokens are game-changers. I've heard from multiple teams who migrated from StreamReader.ReadToEndAsync() over due to thread pool starvation issues.

Practical Example: Streaming Process Output

using var process = new Process
{
    StartInfo = new ProcessStartInfo
    {
        FileName = "my-batch-cli",
        RedirectStandardOutput = true,
        RedirectStandardError = true,
        UseShellExecute = false
    }
};

// Handle process exit
process.Start();
Task outputTask = process.StandardOutput.ReadToEndAsync();

// Progress monitoring with cancellation
await foreach (string line in MonitorProcessOutput(process.StandardOutput))
{
    Console.WriteLine($"PROCESS: {line}");
}

await outputTask;

async IAsyncEnumerable<string> MonitorProcessOutput(StreamReader reader)
{
    while (true)
    {
        string? line = await reader.ReadLineAsync();
        if (line == null) break;
        yield return line;
    }
}

Exit Event Handling: Ending in Style

The new awaitable WaitForExitAsync() and improved ProcessExited event eliminate race conditions we've dealt with for years:

// Before (.NET Core 3.x)
process.WaitForExit();
// Problematic race condition

// After (.NET 11)
await process.WaitForExitAsync();
// Proper awaitable operation

Best Practices: How to Leverage the New API

Always use using blocks Automatic disposal eliminates the most common resource leaks:

   using (Process process = new Process { ...})
   {
       // Safe handling guaranteed
   }

Prefer async over sync

The ReadToEndAsync() pattern prevents thread pool starvation in high-throughput scenarios. I've seen applications using the sync versions crash under load due to eventual thread pool exhaustion.
Use cancellation tokens

Integration with .NET's cancellation infrastructure is now core:

   using (var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10)))
   {
       await process.StandardOutput.ReadToEndAsync(cts.Token);
   }

Combine with the new pipe APIs Access the low-level handles when you need advanced pipe configuration:

   SafeFileHandle pipe = process.StandardOutput.SafeFileHandle;

Real-World Caveats and Solutions

Memory Pressure in Stream Processing

Problem: Large process outputs (>1MB) can cause memory pressure:

string output = await process.StandardOutput.ReadToEndAsync(); // Dangerous for large outputs

Solution: Process streams element-by-element:

var output = new StringBuilder();
await foreach (string line in ReadLinesAsync(process.StandardOutput))
{
    output.AppendLine(line);
}

async IAsyncEnumerable<string> ReadLinesAsync(StreamReader reader)
{
    while (true)
    {
        string? line = await reader.ReadLineAsync();
        if (line is null) break;
        yield return line;
    }
}

The Windows Compliance Quirk

Problem: CreateNoWindow = true sometimes fails on Windows when UseShellExecute = true：

ProcessStartInfo startInfo = new()
{
    FileName = "app.exe",
    CreateNoWindow = true,      // May not work on Windows
    UseShellExecute = true     // Conflict here
};

Solution: The .NET 11 docs now strongly warn against this combination. Always set UseShellExecute = false when using window options.

Race Conditions in Process Exit Handling

Problem: The legacy Process.GetExitCode() implementation had race condition bugs in asynchronous scenarios.

Solution: Use the new awaitable API:

await process.WaitForExitAsync();
int exitCode = process.ExitCode; // Now consistently reliable

The Road Forward

The .NET team's approach to process management improvements shows how they're addressing real developer pain points. By:

Embracing safe handle semantics
Ditching cloneable thread pool starving methods
Building cancellation into streaming interfaces
Standardizing across platforms

This represents a philosophy shift toward safer resource management that's consistent with modern .NET patterns.

Conclusion: Take Control of Your Processes

After years of patching around process management shortcomings, the .NET 11 redesign gives us the tools to implement robust process orchestration. The integration with SafeFileHandle, the async streaming, and cancellation support transforms what was once a fragile practice into a first-class concern.

Have you implemented any new process management patterns with .NET 11? I'd love to hear your experiences in the comments! Have questions about specific pipe scenarios? Come share - let's build better cross-shell experiences together.

What process management nightmares are you most excited to solve with .NET 11? Share your thoughts below 👇

TypeScript 7.0 Beta: The 10x Faster Revolution Built on Go

Vikrant Bagal — Mon, 11 May 2026 13:40:16 +0000

TypeScript 7.0 Beta has arrived, and it's not just an incremental update—it's a complete architectural revolution. Built on a new Go foundation, Microsoft claims a 10x performance improvement over TypeScript 6.0. After testing the beta extensively, I can confirm: the speed gains are real, and they're game-changing for large-scale TypeScript projects.

The Big Rewrite: TypeScript in Go

For over a decade, TypeScript has been bootstrapped in TypeScript itself, compiling to JavaScript. While this worked well, it had fundamental limitations when it came to parallelization and raw performance.

TypeScript 7.0 changes everything by rewriting the compiler in Go. This isn't just a language switch—it's a complete architectural overhaul that leverages:

Native code speed: Go compiles to machine code, eliminating JavaScript interpreter overhead
Shared-memory parallelism: Multiple type-checkers can run simultaneously without conflicts
Deterministic output: New stable type ordering ensures consistent results across runs

As Daniel Rosenwasser, TypeScript Product Manager, stated: "The new Go codebase was methodically ported from our existing implementation rather than rewritten from scratch, and its type-checking logic is structurally identical to TypeScript 6.0."

Performance Benchmarks: The Numbers Don't Lie

Let's look at real-world benchmarks from developer testing:

Project	TypeScript 6.0	TypeScript 7.0 Beta	Speedup
Material-UI	42.3s	4.1s	10.3x
VS Code	127.8s	12.4s	10.3x
React	89.2s	8.7s	10.2x

These aren't synthetic benchmarks—they're real codebases with thousands of files being type-checked. For teams waiting minutes for CI builds, this is transformative.

Parallel Compilation: The Secret Sauce

TypeScript 7.0 introduces two new flags that unlock multi-core performance:

{
  "compilerOptions": {
    "checkers": 4,    // Number of parallel type-checker workers (default: 4)
    "builders": 2,    // Number of parallel project builders (default: 1)
    "singleThreaded": false  // Disable for debugging
  }
}

--checkers: Splits type-checking work across multiple workers, each with its own view of the program
--builders: Builds multiple project references simultaneously, perfect for monorepos
--singleThreaded: Forces single-threaded operation for debugging and comparison

For a monorepo with 8 projects and --checkers 4 --builders 4, you can theoretically run up to 16 parallel type-checkers!

Getting Started with TypeScript 7.0 Beta

Installation

npm install -D @typescript/native-preview@beta

Using the New Compiler

# Check your version
npx tsgo --version

# Compile your project
npx tsgo -p tsconfig.json

Note: The package name will eventually be typescript, but for now it's @typescript/native-preview.

VS Code Integration

For the best editor experience, install the TypeScript Native Preview extension:

TypeScript Native Preview - VS Code Marketplace

This extension uses the same Go-based foundation, bringing 10x speed improvements directly to your editor—faster autocompletions, quicker error detection, and snappier refactoring.

Breaking Changes: What You Need to Know

TypeScript 7.0 adopts TypeScript 6.0's new defaults and introduces stricter settings. Here's what changed:

New tsconfig.json Defaults

Setting	Old Default	New Default	Impact
`strict`	`false`	`true`	Enables all strict type-checking options
`module`	`commonjs`	`esnext`	Modern module resolution
`target`	Varies	Stable ECMAScript	Consistent JavaScript output
`rootDir`	Auto-detected	`./`	May need explicit setting
`types`	`["*"]`	`[]`	Global types must be listed explicitly
`libReplacement`	`true`	`false`	Different lib handling

Migration Checklist

If you're upgrading to TypeScript 7.0, here's what to check:

Update tsconfig.json:

{
  "compilerOptions": {
    "strict": true,           // Explicitly set if you want strict mode
    "rootDir": "./src",       // Add if tsconfig is outside src/
    "types": ["node"],        // List global @types packages
    "module": "esnext",       // Modern modules
    "target": "es2024"        // Stable ECMAScript
  },
  "include": ["./src"]
}

Review type errors: Stricter defaults may reveal previously hidden issues
Test in CI first: Run TypeScript 7.0 in your CI pipeline before production

Parallelization in Action

Let's look at a practical example of parallel compilation:

// tsconfig.json for a monorepo
{
  "compilerOptions": {
    "checkers": 6,      // 6 parallel type-checkers
    "builders": 3,      // Build 3 projects simultaneously
    "incremental": true // Faster incremental builds
  },
  "references": [
    { "path": "./packages/ui" },
    { "path": "./packages/api" },
    { "path": "./packages/shared" }
  ]
}

For a project with 6 CPU cores and 32GB RAM, this configuration can achieve:

2x faster builds with --checkers 6
3x faster monorepo builds with --builders 3
Combined effect: Up to 6x total improvement

Memory Considerations

Parallelization comes with a memory tradeoff. Here are recommended settings:

System RAM	Recommended --checkers
8GB	2
16GB	4
32GB	6-8
64GB+	8-12

If you encounter OOM errors, reduce --checkers or switch to --singleThreaded mode.

Real-World Adoption

Major companies are already testing TypeScript 7.0 Beta:

Bloomberg: Reduced build times from 3+ minutes to 18 seconds in their 500K+ line financial codebase
Vercel: Achieved 9.8x faster type-checking in CI pipelines
Notion: Improved editor responsiveness by 40% with the native preview extension
Slack: Reduced monorepo build time by 85% using parallel builders

Running TypeScript 7.0 Side-by-Side with 6.0

Want to test TypeScript 7.0 without replacing your current setup? Use the compatibility package:

npm install -D typescript@npm:@typescript/typescript6

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0"
  }
}

This allows you to run both compilers simultaneously:

tsc uses TypeScript 6.0
tsgo uses TypeScript 7.0 Beta

Best Practices for Production Adoption

1. Start with TypeScript 6.0 First

TypeScript 6.0 is the bridge release that prepares your codebase for 7.0. Adopt 6.0 and address any deprecation warnings before moving to 7.0.

2. Test in Development First

Run TypeScript 7.0 Beta on your development machines and CI pipeline before considering production use.

3. Monitor Build Performance

Track actual build times and memory usage. Adjust --checkers and --builders based on your infrastructure.

4. Leverage Project References

For monorepos, use TypeScript project references to maximize parallelization benefits.

5. Plan for Breaking Changes

Review the new defaults and update your tsconfig.json accordingly.

What's Next for TypeScript 7.0

The TypeScript team has shared their roadmap:

TypeScript 7.0 RC: Expected mid-June 2026
TypeScript 7.0 Stable: Expected late July/early August 2026
Stable Programmatic API: Coming in TypeScript 7.1
Watch Mode Improvements: More efficient incremental compilation

Conclusion

TypeScript 7.0 Beta represents a massive leap forward for TypeScript performance. The 10x speed improvement isn't marketing hype—it's a real, measurable improvement that transforms the development experience for large codebases.

The Go-based foundation opens new possibilities for parallelization that simply weren't feasible before. Combined with the stability of the existing type-checking logic, TypeScript 7.0 offers the best of both worlds: blazing speed and rock-solid type safety.

If you're working on a large TypeScript project, now is the time to start testing TypeScript 7.0 Beta. The performance gains are too significant to ignore.

Try TypeScript 7.0 Beta today:

npm install -D @typescript/native-preview@beta
npx tsgo --version

Resources:

Follow me on LinkedIn for more technical content and insights!

Copilot Studio gets faster with .NET 10 on WebAssembly

Vikrant Bagal — Fri, 08 May 2026 14:46:54 +0000

Blazing Fast AI: How Copilot Studio is Leveling Up with .NET 10 and WebAssembly 🚀

Let’s be honest: we’ve all been there. You open a powerful low-code tool or a complex AI orchestrator, and you spend the first thirty seconds staring at a loading spinner or feeling that slight "input lag" as you drag a node across a canvas.

When you're building complex conversational flows in Copilot Studio, fluidity is everything. If the UI stutters, the creative flow breaks. For a long time, the trade-off was simple: you either had the flexibility of the web (JavaScript/TypeScript) or the raw power of native code.

But the gap is closing. With the evolution of .NET 10 and WebAssembly (Wasm), Copilot Studio is pushing the boundaries of what "web-based" performance actually feels like. As a developer who has spent years wrestling with browser memory limits and JS heap overflows, seeing .NET run at near-native speeds in the browser is nothing short of magic.

The Magic Sauce: Why .NET 10 + WebAssembly?

To understand why this matters, we have to talk about the architecture. Traditionally, complex logic in the browser is handled by JavaScript. While JS engines (like V8) are incredibly fast, they still struggle with heavy computational tasks—like the graph rendering and state management required for an AI Copilot's orchestration canvas.

Enter WebAssembly (Wasm). Wasm allows us to run compiled code (like C#) in the browser at speeds that rival native applications.

.NET 10 takes this further by optimizing the runtime specifically for the browser environment. We aren't just talking about "running C# in the browser"; we're talking about:

Reduced Binary Size: Faster initial loads (less time staring at that spinner).
Enhanced AOT (Ahead-of-Time) Compilation: Code is pre-compiled to Wasm, removing the "warm-up" time typical of interpreted languages.
Improved Interop: The bridge between the .NET logic and the browser's DOM is now significantly thinner and faster.

Breaking Down the Performance Gain

If you're wondering how this actually translates to the Copilot Studio experience, think about the Canvas. When you have a Copilot with 50+ nodes, variables, and complex trigger logic, the browser has to constantly recalculate positions and state transitions.

In the "Old World" (Standard JS/Wasm), every time you moved a node, the bridge between the logic layer and the UI layer created a slight overhead. With .NET 10's optimizations, the execution loop is tighter.

The Conceptual "Speed-Up" Flow:

Standard Web App: UI Event $\rightarrow$ JS Engine $\rightarrow$ Logic Processing $\rightarrow$ DOM Update
.NET 10 Wasm: UI Event $\rightarrow$ Highly Optimized Wasm Binary $\rightarrow$ Direct Memory Access $\rightarrow$ Optimized UI Update

A Glimpse Under the Hood: Working with Wasm

While Copilot Studio handles the heavy lifting for you, if you're building your own high-performance web tools using .NET 10, you'll likely be interacting with Microsoft.AspNetCore.Components.WebAssembly.

Here is a simplified example of how a high-performance calculation (like a node-positioning algorithm for a flow chart) looks in a .NET Wasm project:

// This logic runs in the browser via WebAssembly
public class FlowCanvasEngine
{
    public Point CalculateNodePosition(Node node, List<Node> siblings)
    {
        // Complex math that would typically choke a JS main thread
        // .NET 10 leverages SIMD (Single Instruction, Multiple Data) 
        // for lightning-fast vector calculations in Wasm.
        var offset = siblings.Count * 150;
        return new Point(node.Id * 10, offset);
    }
}

And the way we call this from the UI remains seamless:

@page "/canvas"
@inject FlowCanvasEngine Engine

<div class="canvas-container">
    @foreach (var node in Nodes)
    {
        var pos = Engine.CalculateNodePosition(node, Nodes);
        <NodeComponent X="@pos.X" Y="@pos.Y" />
    }
</div>

Real-World Impact: What this means for the User

For the average Copilot Studio creator, this isn't about "C# vs JS." It's about the UX.

Instantaneous Node Manipulation: Dragging and dropping complex logic blocks feels "snappy."
Faster Project Load Times: Thanks to .NET 10's leaner runtime, your massive Copilots load faster, even on lower-spec machines.
Complex Logic Validation: When the system checks your flow for errors in real-time, that validation happens in milliseconds, not seconds.

Common Pitfalls to Watch Out For

Even with the power of .NET 10, there are things to keep in mind if you're implementing similar Wasm architectures:

The "Payload" Problem: While .NET 10 is smaller, Wasm binaries are still larger than a few lines of JS. Always implement lazy loading for your heavy modules.
DOM Access: Wasm cannot access the DOM directly; it has to go through JS interop. If you call InvokeInterOp 1,000 times a second, you'll kill your performance. Batch your updates!
Memory Management: Wasm has its own memory heap. Be mindful of large object allocations to avoid browser-side memory pressure.

Pro-Tips for Maximum Performance 🛠️

If you're leveraging .NET 10 for your web-based AI tools, follow these best practices:

Use AOT Compilation: Enable Ahead-of-Time compilation in your .csproj to maximize execution speed.
Leverage SIMD: If you're doing heavy math (like AI token processing or layout engines), use System.Numerics to take advantage of hardware acceleration in the browser.
Profile with Browser DevTools: Don't guess. Use the "Performance" tab in Chrome/Edge to see exactly where the Wasm execution is spending its time.

Final Thoughts: The Future of Low-Code

The marriage of .NET 10 and WebAssembly is a game-changer for tools like Copilot Studio. It proves that we no longer have to choose between the reach of the web and the power of the desktop.

By moving the "heavy lifting" into an optimized Wasm runtime, Microsoft is essentially turning the browser into a professional-grade IDE for AI orchestration. For us developers, it's a signal that the boundary between "Web App" and "Application" is officially disappearing.

What do you think? Are you using .NET Wasm in your current projects, or are you sticking with the traditional JS ecosystem? Let me know in the comments! If you've noticed a speed bump in your Copilot Studio flows, try clearing your cache and seeing if the latest runtime updates have hit your region.

Next Steps:

🚀 Check out the .NET 10 Preview documentation.
🛠️ Try building a small Blazor WebAssembly app to feel the performance difference.
🤖 Dive deeper into Copilot Studio to see these optimizations in action.

Production-Grade Engineering Skills for AI Coding Agents

Vikrant Bagal — Fri, 08 May 2026 02:55:30 +0000

AI coding agents have revolutionized how we write software. They can implement features, fix bugs, and review code at incredible speed. But there's a catch: AI agents default to the shortest path, which often means skipping specs, tests, security reviews, and the practices that make software reliable.

The solution? Production-grade engineering skills for AI coding agents—structured workflows that enforce the same discipline senior engineers bring to production code.

The Problem: AI Agents Need Guardrails

When you give an AI agent a vague prompt like "build a dashboard," it will produce something that looks functional. But will it be:

✅ Well-specified with clear success criteria?
✅ Tested with comprehensive coverage?
✅ Secure against common vulnerabilities?
✅ Performant and maintainable?

Without structured workflows, the answer is often "no." The agent optimizes for "looks right" rather than "is right."

The Solution: Agent Skills

Agent Skills is a production-grade collection of 20 structured workflows for AI coding agents. With 33,000+ stars on GitHub, it's become the de facto standard for reliable AI-assisted development.

Each skill encodes hard-won engineering judgment from Google's engineering culture, including concepts from Software Engineering at Google and Google's engineering practices guide.

The 20 Skills Cover the Entire Lifecycle

Define Phase:

Idea Refinement - Structured divergent/convergent thinking
Spec-Driven Development - Write a PRD before any code

Plan Phase:

Planning and Task Breakdown - Decompose specs into verifiable tasks

Build Phase:

Incremental Implementation - Thin vertical slices with feature flags
Context Engineering - Feed agents the right information at the right time
Source-Driven Development - Ground decisions in official documentation
Frontend UI Engineering - Component architecture, design systems, accessibility
API and Interface Design - Contract-first design, error semantics
Test-Driven Development - RED-GREEN-REFACTOR workflow

Verify Phase:

Browser Testing with DevTools - Chrome DevTools MCP for runtime data
Debugging and Error Recovery - Five-step triage: reproduce, localize, reduce, fix, guard

Review Phase:

Code Review and Quality - Five-axis review, change sizing, severity labels
Code Simplification - Chesterton's Fence, Rule of 500
Security and Hardening - OWASP Top 10 prevention, auth patterns
Performance Optimization - Measure-first approach, Core Web Vitals

Ship Phase:

Git Workflow and Versioning - Trunk-based development, atomic commits
CI/CD and Automation - Shift Left, Faster is Safer, feature flags
Deprecation and Migration - Code-as-liability mindset
Documentation and ADRs - Architecture Decision Records
Shipping and Launch - Pre-launch checklists, staged rollouts

Deep Dive: Spec-Driven Development

The most critical skill is Spec-Driven Development. Before writing any code, the agent creates a specification covering:

The Six-Core Spec Template

# Spec: [Project/Feature Name]

## Objective
What we're building and why. User stories or acceptance criteria.

## Tech Stack
Framework, language, key dependencies with versions

## Commands
Build: npm run build
Test: npm test -- --coverage
Lint: npm run lint --fix
Dev: npm run dev

## Project Structure
src/ → Application source code
src/components → React components
src/lib → Shared utilities
tests/ → Unit and integration tests

## Code Style
Example snippet + key conventions

## Testing Strategy
Framework, test locations, coverage requirements

## Boundaries
- Always: Run tests before commits, follow naming conventions
- Ask first: Database schema changes, adding dependencies
- Never: Commit secrets, edit vendor directories

## Success Criteria
Specific, testable conditions for completion

## Open Questions
Anything unresolved that needs human input

Why This Works

Surfaces Assumptions Early - The spec forces clarity before code
Shared Source of Truth - Human and agent agree on what "done" means
Prevents Rework - A 15-minute spec prevents hours of debugging
Living Document - Updated when decisions change, committed to version control

Deep Dive: Test-Driven Development

The Test-Driven Development skill enforces the RED-GREEN-REFACTOR cycle:

The Cycle

RED: Write a test that fails (proves the test works)
GREEN: Write minimal code to make it pass
REFACTOR: Clean up the implementation
Repeat for each new behavior

Example: Task Service

// RED: This test fails because createTask doesn't exist yet
describe('TaskService', () => {
  it('creates a task with title and default status', async () => {
    const task = await taskService.createTask({ title: 'Buy groceries' });
    expect(task.id).toBeDefined();
    expect(task.title).toBe('Buy groceries');
    expect(task.status).toBe('pending');
    expect(task.createdAt).toBeInstanceOf(Date);
  });
});

// GREEN: Minimal implementation
export async function createTask(input: { title: string }): Promise<Task> {
  const task = {
    id: generateId(),
    title: input.title,
    status: 'pending' as const,
    createdAt: new Date(),
  };
  await db.tasks.insert(task);
  return task;
}

Test Pyramid

80% Unit Tests (small, fast, isolated)
15% Integration Tests (component interactions, API boundaries)
5% E2E Tests (full user flows, real browser)

Real-World Examples

Example 1: Bug Fix with TDD

Bug Report: "Completing a task doesn't update completedAt timestamp"

Agent writes failing test that reproduces the bug
Test confirms bug exists (RED)
Agent implements fix (GREEN)
Agent runs full test suite to ensure no regressions
Result: Bug fixed with guaranteed correctness

Example 2: Parallel Agent Workflow

Scenario: Full-stack feature implementation

Agent 1 (backend): Implements API endpoints in feature branch A
Agent 2 (frontend): Builds React components in feature branch B
Agent 3 (tests): Writes integration tests in feature branch C
Human: Reviews and merges all branches after parallel completion

Result: 3x faster than sequential development

Example 3: Security Review

Agent Skills includes security-and-hardening skill:

OWASP Top 10 prevention patterns
Authentication and authorization patterns
Secrets management and dependency auditing
Three-tier boundary system

Before any code merge, the security skill runs automatically, catching vulnerabilities early.

Common Pitfalls (And How to Avoid Them)

1. Over-Prompting

Problem: Long, repetitive, contradictory prompts confuse agents
Solution: Say what you need once, clearly. Restate rather than append.

2. Under-Reviewing

Problem: Assuming AI-generated code is correct because it looks right
Solution: Review every diff like a pull request from a teammate

3. Skipping Git Isolation

Problem: Running agents on main branch leads to conflicts
Solution: Always use feature branches; use git worktrees for parallel agents

4. Ignoring Session Boundaries

Problem: One long session leads to context bloat and inconsistent decisions
Solution: Start fresh sessions for new tasks; keep sessions focused

5. Testing Implementation Details

Problem: Tests break when refactoring even if behavior unchanged
Solution: Test inputs and outputs, not internal structure

Getting Started

Install Agent Skills

For Claude Code:

/plugin marketplace add addyosmani/agent-skills
/plugin install agent-skills@addy-agent-skills

For Cursor: Copy SKILL.md files into .cursor/rules/

For Gemini CLI:

gemini skills install https://github.com/addyosmani/agent-skills.git --path skills

Create Your First AGENTS.md

Create an AGENTS.md file at your repository root with:

Project layout and important directories
Build, test, lint commands
Engineering conventions
Constraints and do-not rules

Start with Spec-Driven Development

Create a new feature branch
Run the spec-driven development skill
Write the spec with human review
Break into tasks with acceptance criteria
Implement incrementally with tests

The Bottom Line

AI coding agents are powerful but need guardrails. Production-grade engineering skills provide the structure, workflows, and best practices that make AI-assisted development reliable.

The agents who write the best prompts aren't the most productive. The ones with the best processes around prompting are.

Start with spec-driven development. Add test-driven development. Review everything. Manage context like a resource. And watch your AI coding agents transform from fast code generators to reliable engineering partners.

Ready to level up your AI coding workflow? Start with the Agent Skills repository and implement one skill at a time. Your future self (and your production environment) will thank you.

LinkedIn: https://www.linkedin.com/in/vikrant-bagal