A real customer-facing agent needs more than a prompt and a model endpoint. It needs durable memory, tenant isolation, authentication, citations, diagnostics, tests, deployment infrastructure, and a safe way to move from a local prototype to production.

I wanted to see how much of that work could be removed from the critical path, so I tried the create-cosmos-agent starter from beginning to end. I generated a customer-support agent, ran it against the Azure Cosmos DB Linux emulator, stored a customer preference, retrieved it through the chat experience, verified user isolation, inspected diagnostics, and ran the complete validation suite.

The result was a working full-stack application without an Azure subscription, model API key, or cloud resource.

What is create-cosmos-agent?​

create-cosmos-agent is a guided CLI for generating production-oriented TypeScript agent applications. Instead of creating only a chat screen, it scaffolds the surrounding application contracts:

• An Express API and React web application
• Multiple AI provider adapters
• In-memory or Azure Cosmos DB storage
• Durable, scoped agent memory
• Knowledge ingestion and vector retrieval
• Customer-support workflows
• Multi-agent orchestration
• Approval-gated actions
• Microsoft Entra ID authentication support
• OpenTelemetry-style diagnostics
• Unit, security, cost, and integration tests
• Docker and Azure Developer CLI infrastructure

The local and Azure paths use the same application interfaces. That is important: moving to production should be a configuration and infrastructure step, not a rewrite of the application.

Local development                         Azure production
-----------------                         ----------------
Mock or Ollama --------.                  Microsoft Entra ID
Memory or emulator ----+--> Agent API --> Managed Identity
Local identity --------'         |        Azure Cosmos DB
                                +-------> Azure OpenAI
                                +-------> Application Insights
                                '-------> Approval-gated actions

The sample I built​

For this walkthrough, I selected the customer-support scenario with:

• The deterministic mock model provider
• Local development authentication
• Azure Cosmos DB storage
• The Linux Cosmos DB emulator
• The React web interface

This combination is useful because it exercises the real database integration while keeping the model response deterministic and free. It isolates the application and data behavior from model availability, quota, and token cost.

I tested version 0.5.3 from source. The public quick-start command is:

npx create-cosmos-agent@latest bootstrap customer-support-agent `
  --template customer-support-ts `
  --provider mock `
  --auth local `
  --storage cosmos `
  --local emulator `
  --yes

The bootstrap command does more than copy files. It:

1. Resolves the selected scenario and features.
2. Generates the API, web application, packages, tests, and infrastructure.
3. Creates the local emulator configuration.
4. Installs the project dependencies.
5. Initializes a Git repository.
6. Links a local project context.

It does not create Azure resources unless deployment is explicitly requested.

Prerequisites​

To follow the same emulator-backed path, install:

• Node.js 20 or later
• Git
• Docker Desktop using Linux containers

The application uses local ports 3000, 5173, 8080, 8081, and 1234, so make sure they are available.

If you want the fastest possible first run and do not need durable local data, use in-memory storage instead:

npx create-cosmos-agent@latest bootstrap customer-support-agent --yes

That path does not require Docker.

Starting the complete application​

After generation, start the application:

cd customer-support-agent
npm run dev

For the emulator configuration, this single command performs several steps:

1. Starts the Cosmos DB Linux emulator with Docker Compose.
2. Waits for the emulator health check.
3. Creates the database and containers idempotently.
4. Starts the Express API on http://localhost:3000.
5. Starts the React application on http://localhost:5173.

The emulator's Data Explorer is also available at http://localhost:1234.

The first run takes longer because Docker must download the emulator image and npm must install the generated application's dependencies. Once those layers are available locally, subsequent starts are much faster.

Touring the generated experience​

The customer-support application opens with five work areas:

• Chat for context-aware conversations and memory
• Knowledge for document ingestion and retrieval
• Support for ticket workflows
• Agent runs for planner, specialist, and reviewer traces
• Operations for runtime diagnostics

The header clearly showed that I was using the mock provider and cosmos storage. The local identity panel used:

Tenant: tenant-demo
User:   user-demo

These are development identities, not a production authentication mechanism. The generated application blocks local authentication and the mock provider in production.

Proving durable memory​

The most useful part of the walkthrough was testing memory as application data rather than hidden prompt text.

In the Chat tab, I saved this customer preference:

The customer prefers deployment notifications in Microsoft Teams.

The application wrote a memory document to Cosmos DB with the tenant, user, agent, thread, retention class, provenance, schema version, and embedding metadata.

I then asked:

What notification channel does this customer prefer?

Because the sample uses the deterministic local provider, the answer itself is intentionally simple:

Local demo response: What notification channel does this customer prefer?

The important result was the attached citation. Expanding it showed the retrieved preference:

preference
The customer prefers deployment notifications in Microsoft Teams.

The API response also included a retrieval trace containing the tenant, user, selected memory ID, embedding version, timestamp, and correlation ID. That makes memory retrieval inspectable instead of silently injecting data into a prompt.

You can create the same memory directly through the API:

$headers = @{
  "x-tenant-id"      = "tenant-demo"
  "x-user-id"        = "user-demo"
  "x-correlation-id" = "memory-demo-001"
}

$body = @{
  type           = "preference"
  content        = "The customer prefers deployment notifications in Microsoft Teams."
  threadId       = "web-session"
  interactionId  = "interaction-001"
  retentionClass = "standard"
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri "http://localhost:3000/api/memories" `
  -Headers $headers `
  -ContentType "application/json" `
  -Body $body

Verifying tenant and user isolation​

Memory is only useful when its security boundary is correct.

I changed the local user from user-demo to user-other and asked the same question. The second user received no memory citation. Querying the memory endpoint confirmed the difference:

user-demo  -> 1 memory item
user-other -> 0 memory items

The retrieval traces told the same story:

user-demo  -> selected the stored preference memory
user-other -> selected no memory IDs

This is a small test, but it verifies an important architectural decision: tenant and user scope are carried through authentication, partitioning, storage, and retrieval. They are not only UI filters.

Looking at diagnostics​

The Operations tab exposes redacted runtime diagnostics. After creating and retrieving the preference, my local run reported:

Cosmos operations: 3
Request charge:    3
Errors:            0

The recent-operation list included the create and vector-query operations with duration, request charge, and correlation ID. Prompts and document bodies were not captured by default.

Treat emulator request-unit values as development signals rather than production measurements. The Linux emulator is still a preview, and its request charges, vector indexing, and hierarchical partition behavior can differ from Azure Cosmos DB. Measure representative workloads against the Azure service before making production capacity decisions.

Running the quality gates​

The CLI includes two useful commands:

npx create-cosmos-agent doctor .
npx create-cosmos-agent validate .

doctor checks configuration, secret hygiene, security patterns, and multi-tenant partitioning. My generated project returned:

HEALTHY No static safety issues found
Doctor 0 error(s), 0 warning(s), 1 info

validate runs the generated project's complete quality gate. In my test, it successfully completed:

• TypeScript type checking for the API and web application
• A production Vite build
• 8 unit tests
• 5 security tests
• 2 cost tests
• Bicep template validation

I also validated the generator itself before creating the sample: all 58 generator tests passed, followed by a successful TypeScript build and package creation.

The security tests are especially valuable for an agent starter. They verify behaviors such as production authentication requirements, tenant isolation, and protection of consequential actions instead of leaving those controls as documentation-only recommendations.

What the generated Cosmos DB path gets right​

The generated application applies several patterns that matter when an agent moves beyond a prototype:

Scoped data modeling​

Memory documents include explicit tenant, user, agent, and thread scope. Related data needed for retrieval is stored together, while schema and embedding versions make future evolution possible.

Partition-aware access​

The production path uses hierarchical partition keys aligned with tenant and user access patterns. This reduces accidental cross-tenant queries and gives the application a predictable isolation boundary.

A reusable client​

The Azure Cosmos DB client is reused instead of being created for every request. Reusing a singleton client is essential for efficient connection management and predictable latency.

Bounded and parameterized retrieval​

Vector and document queries are bounded and parameterized. The caller cannot inject query text, and retrieval does not return an unlimited result set.

Optimistic concurrency​

Protected state transitions use ETags. This is important for approval workflows, where two callers must not silently overwrite each other's decisions.

Observable database operations​

Request charge, duration, operation type, errors, and correlation IDs are available without recording prompts or document bodies by default.

Moving from local development to Azure​

The local mock/emulator combination is only one adapter configuration. The production path replaces:

Before deployment, configure the Entra application values and model endpoint, then run:

azd auth login

azd env set ENTRA_TENANT_ID "<tenant-id>"
azd env set ENTRA_AUDIENCE "<api-audience>"
azd env set ENTRA_CLIENT_ID "<spa-client-id>"
azd env set ENTRA_SCOPE "<api-scope>"
azd env set AI_PROVIDER "azure-openai"
azd env set AZURE_OPENAI_ENDPOINT "<endpoint>"
azd env set AZURE_OPENAI_CHAT_DEPLOYMENT "<deployment>"

npx create-cosmos-agent prepare-azure . --environment customer-support-agent-dev
azd up

prepare-azure is a readiness check. It verifies Azure Developer CLI authentication, Entra configuration, the selected production provider, Cosmos DB capacity choices, and required settings without creating resources. azd up is the step that can provision billable resources.

Azure OpenAI capacity is bring-your-own, so confirm that the selected region and deployment have quota before deploying. The generated production infrastructure uses a user-assigned Managed Identity; grant it the required Azure Cosmos DB data-plane role and the Cognitive Services OpenAI User role.

What I learned from the end-to-end run​

Three aspects stood out.

First, the starter treats memory as a product feature. It has scope, provenance, retention, citations, retrieval traces, and diagnostics. That is much stronger than appending previous messages to every prompt.

Second, local development is genuinely local. I exercised Cosmos DB persistence and vector retrieval without creating an Azure account or supplying a model key.

Third, the path to production is visible from the beginning. Entra ID, Managed Identity, infrastructure, diagnostics, capacity, and validation are not postponed until after the prototype succeeds.

There are also practical caveats:

• Docker is required for the emulator-backed path.
• The first emulator image download can take time.
• The mock provider proves application behavior, not model quality.
• Emulator performance and request charges are not production benchmarks.
• Azure deployment still requires identity design, quota, capacity, and cost decisions.

Those are reasonable boundaries. The goal of a starter should be to remove repetitive work while keeping important production decisions explicit.

Frequently asked questions​

Can I build this Azure Cosmos DB AI agent without an Azure subscription?​

Yes. The default local path uses a deterministic mock model and either in-memory storage or the Azure Cosmos DB Linux emulator. You do not need an Azure subscription or model API key for the first run.

Does the local sample require an AI model API key?​

No. The mock provider produces deterministic development responses. You can later configure Azure OpenAI, OpenAI, or Ollama without changing the application contracts.

How does the sample isolate agent memory?​

Authentication context carries tenant and user identifiers through storage and retrieval. A memory saved for one user is not returned to another user, even within the same tenant.

Is the Cosmos DB emulator equivalent to the Azure service?​

No. It is ideal for local development, but request charges, vector indexing, performance, and hierarchical partition behavior can differ from Azure Cosmos DB. Test representative workloads against Azure before making production capacity decisions.

How do I move the generated agent to Azure?​

Configure Microsoft Entra ID, an Azure OpenAI deployment, and the required azd environment values. Run create-cosmos-agent prepare-azure before azd up to validate readiness.

Clean up​

Stop the development process with Ctrl+C, then stop and remove the emulator container:

npm run emulator:stop

The generated data remains local to the emulator container lifecycle. If you used the default in-memory configuration instead, restarting the API resets the data.

Try it yourself​

Start with the repository and end-to-end demo:

• Azure Cosmos DB Agent Starter on GitHub
• Watch the complete end-to-end video
• Download the captioned walkthrough

Then generate an application:

npx create-cosmos-agent@latest bootstrap my-agent --yes
cd my-agent
npm run dev

Open http://localhost:5173, save a preference, ask the agent to recall it, switch users, inspect the citation, and run the validation commands.

That short workflow demonstrates the bigger idea behind the project: start with a zero-cost local agent, preserve the application contracts, and move deliberately toward a secure Azure deployment.

Related reading​

• Building DevGlobe with Azure Cosmos DB and AI Agents
• Turning Coding Agents into Azure Cosmos DB Experts with Scott Hanselman
• What Six Months of Building AI Agent Skills Taught Me About Writing for Machines

A GitHub profile can show repositories. Stack Overflow can show answers. A professional network can show job titles. But none of those views, on their own, answer questions such as:

• Who has recent evidence of working with a specific technology?
• Which developers match the needs of an open-source repository?
• Who is active in a particular region or community?
• Can an AI agent discover a relevant expert without exposing private contact details?

Those questions led me to build DevGlobe, an open-source talent graph for humans and AI agents. What started as an interactive 3D map became a search, data, and consent problem—and Azure Cosmos DB became the foundation that connected those pieces.

Explore DevGlobe and discover developers, contribution opportunities, live coding activity, and agent-ready tools →

The idea: discovery based on evidence, not popularity​

Developer discovery often becomes a popularity contest. Follower counts, total stars, and reputation are useful signals, but they should not become unsupported conclusions about a person's expertise or suitability.

DevGlobe brings together public evidence from sources such as GitHub and Stack Overflow, then presents it through:

• An interactive 3D developer globe
• Search by skills, technologies, roles, names, and locations
• Developer profiles with contribution evidence
• Repository-to-developer matching
• A VS Code extension for opt-in live presence
• A hosted MCP server for AI-agent discovery
• Consent-gated introductions for verified agents

The goal is not to declare that one developer is "better" than another. The goal is to make relevant public evidence easier to discover and explain.

You can explore the live project at devglobe.dev or view the source on GitHub.

Why Azure Cosmos DB fit the problem​

DevGlobe combines several workloads that look related in the interface but behave very differently in storage:

1. Public developer profiles change comparatively slowly and are read frequently.
2. Search needs both exact text signals and semantic similarity.
3. Live coding presence changes every few seconds and should expire automatically.
4. Private coding statistics belong only to the developer who generated them.
5. Introduction requests have a durable, consent-driven lifecycle.
6. Agents need bounded, structured access to public data and protected workflows.

Trying to force all of those workloads through one generic data path would make the system harder to scale and harder to reason about.

Azure Cosmos DB gave me a flexible document model, low-latency reads, vector search, automatic indexing, and workload-specific containers. More importantly, it let the architecture evolve as DevGlobe grew from a visualization into an agent-ready platform.

The high-level architecture​

The production system separates interactive product traffic, high-volume public reads, static snapshots, and scheduled ingestion:

GitHub + Stack Overflow + public signals
                  |
            ingestion jobs
                  |
          Azure Cosmos DB
        /        |         \
 profiles    activities    workflow state
    |            |              |
    +------ search APIs --------+
           /             \
 Azure Functions     Azure Container Apps
 public reads        web, auth, MCP, mutations
           \             /
           humans + AI agents

The major runtime pieces are:

• Next.js, React, and Three.js for the product and interactive globe
• Azure Container Apps for the dynamic web application, authentication, private mutations, share metadata, and hosted MCP endpoint
• Azure Functions for high-volume public APIs, scheduled ingestion, and snapshot generation
• Azure Cosmos DB for profiles, activities, search, live presence, coding statistics, and workflow state
• Azure Blob Storage for a compressed developer snapshot that browsers can download efficiently
• Azure OpenAI embeddings for semantic and hybrid developer search

This split is intentional. Not every request needs to reach the full Next.js application, and not every browser load needs to query the database directly.

Architecture and implementation references​

The architecture is open for inspection. These documents go deeper than a single article can:

• Azure backend and production traffic split
• Hosted MCP server and consent lifecycle
• Agent-readiness and machine-readable discovery
• Public OpenAPI description
• Developer documentation
• Complete source repository

Modeling developer profiles as useful documents​

A developer profile is naturally document-shaped. Identity, location, languages, repository summaries, contribution totals, community credentials, search text, and embeddings are commonly retrieved together.

That makes a denormalized profile document practical for the primary read path. The interface can render a developer card without coordinating several joins, while search APIs can project only the fields required for a result.

The important design choice is to keep facts and conclusions separate.

DevGlobe stores public evidence such as:

• GitHub login and profile metadata
• Languages and repository signals
• Stars, commits, forks, and watchers
• Stack Overflow reputation and engagement
• Verified community credentials
• Geocoded public location
• Search text and vector embeddings

Credentials are explicit data, not guesses. A person is not labeled a Google Developer Expert, Microsoft MVP, GitHub Star, or community leader because an algorithm inferred it from popularity. Those tags require verifiable public evidence.

The same principle applies to search results: a relevance score is an ordinal discovery signal, not a probability that someone is suitable for a job.

Combining text and vector search​

Developer searches do not always use the exact words stored on a profile.

Someone may search for:

"TypeScript developer working on AI agents in Bengaluru"

Text search is strong when the query contains names, locations, languages, or exact technologies. Vector search is useful when the intent is expressed through related concepts rather than matching terms. DevGlobe supports text, vector, and hybrid modes so those strengths can complement each other.

The public Find People experience brings those search modes together over the interactive globe. Visitors can search by skills, projects, locations, names, or GitHub usernames, then inspect the public evidence behind each result.

At a high level, the flow is:

1. Parse and normalize the query.
2. Generate an embedding when semantic search is available.
3. Retrieve a bounded candidate set from Azure Cosmos DB.
4. Combine text and semantic evidence.
5. Return projected public fields with explanations and search signals.

The vector query uses VectorDistance against the stored profile embedding and orders a bounded result set by distance. Text search remains available as a fallback, including for contributors running DevGlobe locally without Azure OpenAI.

That fallback matters. A development environment should not become unusable just because an optional AI dependency is unavailable.

Designing for bounded cost and predictable queries​

Search systems can become expensive when every interaction turns into an unbounded cross-partition scan. DevGlobe keeps public APIs bounded and treats the returned fields as part of the contract.

Several practices help:

• Limit result counts at the API boundary.
• Project only fields needed by list and search views.
• Keep full profile retrieval separate from result summaries.
• Parameterize user-provided values.
• Cache and reuse the Cosmos client and container references.
• Generate browser snapshots for high-volume read paths.
• Keep ephemeral and durable workloads in separate containers.

The browser can load the compressed developer snapshot from Blob Storage, while Azure Functions handle public detail and search requests. This reduces pressure on the application container and avoids routing every public read through a server-rendered page.

Live presence is an expiry problem​

The DevGlobe VS Code extension lets a developer opt in to appear on the live globe. It sends a bounded heartbeat every 30 seconds containing:

• Active language, when enabled
• Editor and platform
• Session start
• Last-seen time

It does not send source code, file paths, repository names, branches, or keystrokes. Coordinates come from the developer's existing public profile rather than the device.

Live presence has a very different lifecycle from a developer profile. A heartbeat is useful now, but it should not remain forever.

DevGlobe uses a TTL-enabled Cosmos DB container for this workload:

• A heartbeat is considered live for 90 seconds.
• A developer can remain visible as recently coding for 15 minutes.
• Cosmos DB TTL removes the item automatically after that window.

This is simpler and safer than building a separate cleanup process for expired presence. The data model expresses the retention policy directly.

Private coding statistics use a separate boundary​

The extension can also build private, owner-only daily coding totals from consecutive heartbeats. These aggregates are stored separately from public live presence and retained for 400 days.

That separation is important:

• Public presence answers, "Who has opted in to appear live?"
• Private statistics answer, "What does my own coding activity look like over time?"

They have different audiences, retention periods, and authorization requirements. Keeping them in separate containers makes those boundaries visible in both the data model and the APIs.

Aggregate writes are best-effort. A statistics failure should never prevent a developer from appearing live.

From a database API to domain-specific MCP tools​

DevGlobe exposes a hosted Streamable HTTP MCP endpoint:

https://www.devglobe.dev/mcp

The easy implementation would have been a generic Cosmos DB query tool. I deliberately did not build that.

The agent setup experience provides connection instructions for GitHub Copilot, VS Code, Claude, Cursor, and direct HTTP clients. Public discovery works without credentials; introductions remain authenticated and consent-gated.

Agents instead receive domain-specific capabilities such as:

• Search public developer profiles
• Inspect a public developer profile
• Match developers to a public GitHub repository
• Discover trending developers
• Find similar developers
• Request a consent-gated introduction
• Check introduction status

This distinction matters. The agent should understand the action it is taking, not merely the database operation underneath it.

Public discovery works anonymously. Introduction requests require a verified agent credential and explicit developer consent. Private contact details are never returned through public discovery.

Cosmos DB persists the workflow state, but the MCP server exposes the domain contract: discover publicly, request transparently, and let the person decide.

Consent is data, not prompt text​

One of the most important lessons from DevGlobe is that prompts cannot enforce consent.

A reliable introduction workflow needs durable state:

agent requests introduction
          |
request stored with bounded context
          |
developer reviews request
       /         \
   accepts       declines
      |             |
status updated and exposed without leaking private data

The system—not the model—decides which transitions are allowed.

DevGlobe separates public discovery from consequential actions, validates scopes, returns structured errors, and records the consent lifecycle. An agent can help someone find a potential collaborator, but it cannot silently initiate contact or retrieve private details.

Building an agent-readable product​

Supporting agents involves more than adding an MCP endpoint.

DevGlobe publishes:

• An OpenAPI description
• An API catalog
• MCP server metadata
• Protected-resource metadata and permission names
• Agent Skill metadata with content digests
• A Markdown representation for clients that request text/markdown
• An llms.txt guide
• Guarded, read-only WebMCP tools in supported preview browsers

This makes the product discoverable through machine-readable contracts rather than requiring an agent to scrape the visual interface.

The API also returns stable error codes and actionable recovery hints. Agents need to know not just that a call failed, but whether they should correct input, authenticate, narrow a query, or stop.

Local development without a cloud dependency​

Open-source projects need a contributor path that does not start with provisioning several Azure resources.

DevGlobe supports three levels:

1. Zero configuration: bundled sample data and offline text search
2. Cosmos DB Emulator: full local database and API development
3. Azure backend: vector and hybrid search with Azure OpenAI

The application automatically falls back to sample data when Cosmos DB credentials are absent. Contributors can clone the repository, run npm install, and start exploring the product before deciding whether they need the emulator or cloud services.

That progression keeps the first-run experience simple without hiding the production architecture.

What I would carry into the next Cosmos DB project​

Building DevGlobe reinforced several principles that apply beyond developer discovery:

Model around access patterns​

Embed information retrieved together, project only what each API needs, and separate workloads with different audiences or retention policies.

Use TTL for genuinely ephemeral data​

Presence, temporary state, and short-lived signals should not require manual cleanup when the database can enforce expiry.

Keep semantic search bounded​

Vector search should retrieve a deliberate candidate set, not become an excuse for returning or ranking the entire dataset.

Reuse the Cosmos client​

Creating a client per request wastes connections and adds latency. DevGlobe caches client and container references for reuse.

Design fallback paths​

Text search and sample data keep the application useful when embeddings, cloud credentials, or the production backend are unavailable.

Put trust boundaries in code and data​

Authorization, consent, retention, and workflow transitions belong in the system—not only in instructions to an AI model.

The larger lesson​

DevGlobe began as a visual way to explore the global developer community. Azure Cosmos DB helped it evolve into something broader: a talent graph that humans can explore and agents can use through explicit, bounded contracts.

The most interesting part was not adding AI to a database. It was deciding how data, search, tools, and consent should work together.

An agent-ready platform needs more than powerful queries. It needs:

• Evidence instead of unsupported conclusions
• Context without unnecessary data exposure
• Search that explains why a result appeared
• Separate boundaries for public and private workloads
• Retention policies that match the value of the data
• Domain tools instead of unrestricted database access
• Human approval for actions that affect people

That is the architecture behind DevGlobe—and the direction I believe developer platforms must take as more software is used by both humans and AI agents.

Help DevGlobe grow​

DevGlobe is independently maintained, open source, and free to use. If the project is useful to you, there are three meaningful ways to support it:

1. Vote for and review DevGlobe on Product Hunt to help more builders discover it.
2. Star DevGlobe on GitHub to follow the project and signal that the work is valuable.
3. Sponsor the open-source work to help fund Azure hosting, observability, public-data refreshes, testing, security updates, and ongoing maintenance.

Sponsorship never influences developer rankings, search placement, moderation, or access to private information. Those boundaries remain part of the product's public trust contract.

Explore DevGlobe​

• Try DevGlobe
• View the source on GitHub
• Vote or leave a Product Hunt review
• Sponsor DevGlobe
• Connect an MCP client
• Read the OpenAPI description
• Install the VS Code extension

What does it take to move AI agents from impressive demos to experiences developers can trust every day?

On September 26, I spoke at MCP Community Connect in Bengaluru about designing MCP tools around trust and consent. The next day, I joined the Global AI Conference in Chennai to share how we can build an agent-first experience for Azure Cosmos DB.

The talks approached the question from different directions, but they arrived at the same conclusion: an agent is only as useful as the context, boundaries, and developer experience we build around it.

Stop one: MCP Community Connect, Bengaluru​

MCP Community Connect was a full-day, community-run conference focused on taking the Model Context Protocol beyond experiments. The agenda went deep into production concerns: security, observability, governance, interoperability, and architecture.

My session, "Beyond CRUD: Designing MCP Tools Around Trust and Consent," focused on a lesson I learned while building DevGlobe: exposing data through MCP is relatively easy. Deciding what an agent should be allowed to discover, infer, and do is the real design challenge.

Why a generic database tool was the wrong abstraction​

When we first think about connecting an agent to a database, the obvious approach is to expose familiar operations: query, create, update, and delete. That interface is flexible, but it also transfers too much responsibility to the agent.

DevGlobe is a developer-discovery platform. It works with public professional evidence such as profiles, repositories, languages, locations, and contribution activity. It also supports introductions between people, which is a very different kind of action. Discovery can use public information; initiating contact requires consent.

Instead of exposing a general database interface, I designed domain-specific tools across two trust levels:

• Anonymous tools support bounded discovery using public evidence.
• Authenticated tools support consent-controlled introduction workflows.

That separation makes the intended behavior clear to both the agent and the developer. More importantly, it turns consent into an application boundary rather than a sentence hidden inside a prompt.

Trust has to exist in the system​

Prompts are useful guidance, but they are not security boundaries. If an action has consequences for another person, the system must enforce the rules.

For DevGlobe, that means:

• Returning bounded, structured results rather than unrestricted database access
• Including evidence and freshness so the agent does not invent unsupported conclusions
• Separating read-only discovery from consequential actions
• Requiring authentication before an introduction can be requested
• Persisting consent and introduction state as durable application data
• Returning explicit errors when a request is unauthorized or invalid

The MCP server can remain stateless while coordinating a stateful workflow in Azure Cosmos DB. The agent gets a small, purposeful set of capabilities, and people remain in control of when and how contact happens.

You can explore the full deck here:

View the Beyond CRUD slides →

Stop two: Global AI Conference, Chennai​

The following day, I traveled to Chennai for the Global AI Conference, a free one-day gathering for developers, engineers, data professionals, students, and AI builders. The program combined expert sessions, live demos, and hands-on workshops, all focused on turning AI ideas into working systems.

My session was "Building an Agent-First Experience for Azure Cosmos DB."

The audience for developer guidance has changed​

Documentation used to be written primarily for people. Today, agents retrieve documentation, samples, schemas, and repository context before they generate code or recommend an implementation.

That changes the responsibility of developer platforms:

• Agents read more of the documentation. Information must be structured, current, and easy to retrieve.
• Agents make more implementation decisions. API choices, data models, query shapes, retries, and indexing strategies may be selected before a person reviews the result.
• Every mistake is amplified. Weak guidance can become repeated code across projects, while strong guidance makes the preferred path repeatable.

Documentation is no longer only content that people read. It is context that agents use to make decisions and write code.

What an agent-first database experience needs​

An agent-first experience is not a chat box placed in front of an existing product. It requires the product to expose the right context and capabilities in forms an agent can use safely.

For Azure Cosmos DB, that experience brings several pieces together:

1. MCP tools give agents bounded access to real database capabilities.
2. Skills encode domain guidance for data modeling, querying, indexing, and SDK usage.
3. Schema and repository context help agents understand the application they are changing.
4. CLI workflows allow agents to invoke existing tools, inspect results, and adapt.
5. Human control keeps consequential operations visible and reviewable.

The goal is not to remove the developer. It is to reduce the context switching that gets between a developer and the problem they are trying to solve.

You can view the Chennai session deck here:

View the Agentic Development with Azure Cosmos DB slides →

What connected both talks​

Bengaluru was about boundaries. Chennai was about context.

An agent needs both.

Context without boundaries creates a capable system that people cannot safely trust. Boundaries without useful context create a safe system that cannot do meaningful work. Good agent experiences combine:

• The right information
• Purpose-built tools
• Clear trust levels
• Durable application state
• Observable actions
• Human approval where consequences matter

This is the product and engineering work behind agent-first development. The protocol is important, but the experience is shaped by the decisions around it.

Community makes the ideas better​

Speaking in Bengaluru and Chennai on consecutive days was a reminder of why local developer communities matter. A slide deck can explain an architecture, but conversations with builders reveal the questions that architecture must answer in the real world.

How much access is too much? Where should consent live? How do teams keep agent guidance current? What should be observable? Which actions should always require a person?

Those questions are not side topics. They are the work.

Thank you to the organizers, volunteers, speakers, and attendees at MCP Community Connect Bengaluru and the Global AI Conference Chennai for creating spaces where developers could examine these challenges together.

The agent-first future will not be built by agents alone. It will be built by communities of people deciding, deliberately, what agents should be able to do—and what must always remain in human hands.

Resources​

• MCP Community Connect Bengaluru
• Global AI Conference Chennai
• Beyond CRUD slides
• Agentic Development with Azure Cosmos DB slides
• DevGlobe

I couldn't prove it. I had gut feelings and a few suspicious eval runs, but nothing concrete enough to point at and say "this is why."

Then I read this paper.

The paper that put numbers on the feeling​

The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents by Darshan Tank and Baran Nama (Sentient Labs) does something deceptively simple. They ran the same agent on the same tasks with and without skills — nearly 6,000 paired runs across two office-automation benchmarks and three different model–harness stacks (OpenCode + MiniMax-M2.7, Codex + GPT-5.4-mini, Claude Code + Sonnet 4.6).

Then instead of just reporting "skills improved pass rate by X%," they counted both sides: how many tasks did skills fix, and how many tasks did skills break.

The answer stung.

Across all conditions, regressions wiped out 59% of the gains. 553 tasks newly solved, 324 tasks newly broken. Net: 229.

That's not a rounding error. That's a tax.

Breaking less matters more than helping more​

Here's the finding that genuinely changed how I think about this work.

The best-performing skill libraries didn't get there by helping on dramatically more tasks. They got there by breaking fewer things. The separation between good and bad libraries was mostly on the regression side, not the gain side.

One example from the paper stuck with me. On Claude Code + Sonnet 4.6, three skill libraries gained 10, 11, and 12 tasks respectively on OfficeQA-Pro. Sounds like the 12-gain library wins, right? But they regressed 2, 4, and 7. The library that gained the fewest tasks actually had the best net effect because it barely broke anything.

I thought back to our own work. When we cut the Cosmos DB skill from 2,000 lines down to ~400, the eval numbers went up. At the time I assumed it was because the trimmed version was more focused and helped more. Now I think the real story is simpler: we stopped breaking cases the model already handled. The trim removed more damage than it removed help.

How skills break things​

The paper names three mechanisms, and honestly, I've hit all three without knowing what to call them.

Skills change behavior just by existing in context​

They call this "skill-description osmosis." A skill sits in the system prompt — its name, its short description — on every single step. The body never loads. The skill is never invoked. And yet outcomes change.

They showed one task where all three independently written skill libraries caused the exact same wrong answer. None were invoked. The descriptions alone shifted how the agent interpreted a financial figure. Same wrong number, three decimal places, across all three libraries. That's not noise.

I've seen a version of this myself. We had a skill with "structured references" in its description, and it was causing the agent to reach for Excel table-reference syntax on completely unrelated spreadsheet tasks. The skill was never triggered — it was just... there, biasing things.

The scary part: any system that decides whether to suppress a skill based on whether it gets called cannot catch this. The description is always present.

Generic procedures override correct intuition​

"Grounding displacement" — a skill tells the agent how to navigate to information, and that procedure sends it to the wrong place. The bare agent would have found the right table on its own. The skill's general-purpose navigation steps redirected it.

This accounted for 59 out of 81 regressions on one benchmark. The most common way skills break things is by overriding a correct reading with a generic one.

Think about it: you write a skill that says "always start by checking the summary table." Great advice most of the time. But for the task where the answer is in a footnote on page 7, you just sent the agent on a detour it never comes back from.

Skills suppress the agent's own sanity checks​

"Verification displacement." The skill's procedure takes over, and somewhere along the way the agent stops doing the final "does this answer actually make sense?" check it would have done on its own.

On SpreadsheetBench, 226 out of 663 formula failures were formulas that were already correct. The agent wrote the right formula. It just never verified the output. When the researchers re-graded those with a proper execution check, they all passed.

The agent did the hard work. The skill displaced the easy part — looking at what it produced and asking "is this right?"

The pipeline problem​

The paper frames it with a simple diagram that I keep coming back to:

INPUT → [grounding] → [method/reasoning] → [verification] → OUTPUT

Skills live almost entirely in the middle box — they're procedural, they tell the agent how to do the work. But when the researchers traced where failures actually happen, procedure was the stage least responsible. Grounding (did the agent read the right input?) and verification (did it check its output?) are where things go wrong.

We're over-engineering the part models are already decent at, and ignoring the parts where they actually need help.

Looking back at our own skill iterations, this tracks. The changes that moved our eval numbers the most weren't better procedures. They were things like "read the partition key path from container settings before writing any query" (grounding) and "after generating output, verify the partition key appears in the WHERE clause" (verification). Boring, specific, and effective.

What I'm changing​

I'm not going to pretend I have this all figured out. But a few things are different now:

We track regressions separately. Not just "did pass rate go up?" but "which previously-passing tasks now fail?" Two skills with identical net improvement can have completely different regression profiles, and we want the one that breaks less.

Descriptions get the same scrutiny as bodies. Every word in a skill description is always-on context. It's not just a trigger condition — it's shaping agent behavior on every task, including the ones it has nothing to do with. We're rewriting descriptions to be narrower and more precise, with explicit "DO NOT USE FOR" boundaries.

Less procedure, more anchoring. Instead of 15-step how-to guides, we're writing short grounding statements ("the data you need is here, not there") and verification checks ("confirm your output satisfies X before returning"). The model knows how to write a Cosmos DB query. It sometimes looks at the wrong container or forgets to check its results.

We test the description-only condition. Descriptions present, bodies disabled. If outcomes shift, the description is doing unsupervised work. Sometimes that's fine. Sometimes it's osmosis you need to fix.

The uncomfortable takeaway​

I've written before about how less is more with skills. This paper makes me think I didn't go far enough.

The instinct when a skill helps on 10 tasks is to celebrate. But if it also silently breaks 7 tasks the bare model had already nailed, your net is 3. And you won't know that unless you're measuring both sides.

Most of the value in skill engineering isn't in the knowledge you add. It's in the damage you don't do. That's the regression tax, and it's higher than any of us assumed.

Paper: The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents (Tank & Nama, 2026). If you're building agent skills, read this one.

Not bigger prompts.

Not more skills.

Just a better separation of responsibilities.

The Framework​

My current approach boils down to three pillars:

✅ Lean Prompts​

Tell the agent what to do, not how to do everything.

• Be clear about the goal
• Include only what's essential
• Avoid fluff and unnecessary details

Instead of writing a 500-line prompt that tries to cover every edge case, I keep it short:

"List the top 5 features of our product."

That's it. No preamble. No over-explanation. The agent doesn't need a backstory.

📚 Rich Artifacts & Context​

Put the heavy lifting into documentation, examples, schemas, and project knowledge — not the prompt itself.

• Add docs, schemas, references
• Share examples and constraints
• Include relevant project knowledge

This is where files like architecture.md, schema.json, coding-standards.md, and examples/ come in. The agent reads these as context, so your prompt stays lean while the agent still has everything it needs.

🧩 Small, Focused Skills​

Keep skills modular with a single responsibility instead of building giant "do everything" tools.

• Single purpose
• Modular and composable
• Easy to maintain and extend

Think query-data, run-tests, generate-report, create-pr — each skill does one thing well. Not a monolithic "handle-everything" skill that tries to be clever.

Why This Works​

The result of applying this pattern consistently:

• More consistent outputs — The agent isn't distracted by irrelevant instructions
• Better reasoning — Smaller context means the agent focuses on what matters
• Easier maintenance — Change one skill without breaking everything else
• Lower token usage — Less prompt bloat means faster, cheaper responses

What I Learned Building This in Practice​

This isn't theoretical. I arrived at this framework through months of hands-on work building AI agent skills and tools. Here are some concrete examples from my own experience:

Building the Cosmos DB Best Practices Skill​

When I started building skills for the Azure Cosmos DB Agent Kit, I fell into the "more is better" trap. We wrote down everything — partition key strategies, indexing decisions, query optimization, change feed patterns, vector search setup. The skill file kept growing past 2,000 lines.

Then we started measuring. Some of that guidance made zero measurable difference — the model already knew it from training data. A few cases actually made things worse because the model spent attention budget processing our instructions instead of solving the problem.

The fix? We trimmed to a ~400-line core backed by reference files that load on-demand. Performance improved. Token usage dropped by ~60%. The lesson: skills matter most where the model's training data is thin.

I wrote about this journey in depth in my post What Six Months of Building AI Agent Skills Taught Me About Writing for Machines.

Using Skills for Real Customer Scenarios​

The framework proved itself in real support scenarios. When a customer needed help understanding why they couldn't scale down their Cosmos DB autoscale throughput after a test, I used the best practices skill to quickly generate accurate, context-aware guidance. The skill provided the precise domain knowledge the agent needed — not a generic explanation, but the exact autoscale behavior rules. Lean prompt + rich context = accurate answer in seconds.

Extending Skills for Customer-Specific Scenarios​

Enterprise customers like Walmart and Nike started asking for customized skills tailored to their specific use cases. This validated the modular approach — because each skill had a single responsibility, we could extend or compose them for customer scenarios without rewriting the core. A monolithic skill would have made this nearly impossible.

Skill Descriptions Are Underrated​

One of the subtler lessons: how you describe a skill matters as much as what's in it. Our first skill description was vague — "Best practices for Cosmos DB." It got triggered for everything remotely related, including completely wrong contexts.

The fix was adding explicit scope boundaries and negative triggers. A good description says what the skill is for and what it's not for. "Do NOT use for MongoDB, PostgreSQL, or DynamoDB" is surprisingly effective at preventing false matches. We also found that skill registries degrade in selection accuracy past ~20-30 entries without a retrieval filter.

The Anti-Pattern: Why Long Prompts Fail​

I've seen (and written) the opposite approach — massive prompts that try to anticipate every scenario. They fail for predictable reasons:

1. Context rot — Even models with 200K token windows lose attention in the middle. Research confirms this. A big context window is not the same as a big useful context window.

2. Diminishing returns — Past ~800 lines, performance degrades regardless of model. More tokens ≠ better output.

3. Maintenance nightmare — One giant prompt means every change risks breaking something else. Small skills are independently testable and updatable.

4. Duplicating training data — Frontier models already know common patterns. Writing skills for things models already handle is wasted effort.

How to Get Started​

If you want to try this framework:

1. Audit your prompts — Find the ones that are doing too much. Split the "what to do" from the "how to do it."

2. Extract context into files — Move schemas, examples, coding standards, and domain knowledge into separate artifacts the agent can reference.

3. Build small skills — One skill per capability. If a skill description needs the word "and," it's probably two skills.

4. Measure — Even a crude evaluation (5 test cases, 3 trials each) is infinitely better than vibes. You'll be surprised what the model already knows.

5. Iterate — Treat skills like code. Test them. Version them. Cut what doesn't help.

What's Your Prompting Philosophy?​

I'm curious if others have arrived at the same conclusion.

• Do you rely on long prompts?
• Do you invest more in context?
• Or have you found another approach that works even better?

Share your tips, prompts, or real-world examples — let's learn from each other.

Six months later, what I learned about how to write for AI agents turned out to be far more interesting than the domain knowledge itself.

The starting point​

The idea seemed simple enough: take deep expertise in a technology, write it down as structured guidance, and feed it to coding agents as a "skill." The agent reads the skill, follows the rules, and produces better output. Easy.

So that's what we did. We wrote down everything — design patterns, common pitfalls, configuration recipes, SDK best practices, operational guidance. For Cosmos DB specifically, this meant partition key strategies, indexing decisions, query optimization, change feed patterns, vector search setup. Hundreds of rules, all carefully documented.

It felt productive. We were capturing knowledge. Surely more knowledge = better outcomes?

The "more is better" trap​

We kept adding. Every edge case, every teammate's favorite gotcha, every "oh you should also mention..." went in. The skill file kept growing — 500 lines, 1000, eventually past 2000.

Then newer models came out — and they were already pretty good at a lot of what we'd written. Without any skill at all, they'd handle basic scenarios correctly. They already knew common patterns from training data.

Which raised the uncomfortable question: were our skills actually helping, or were we just duplicating what models already knew?

We had no idea. We were operating on vibes.

We started measuring (and got humbled)​

This is where things got real. We set up controlled experiments — give the same coding tasks to agents with and without our skills, then grade the output systematically.

We tested:

• Bare model, zero guidance
• Full monolithic skill (everything we'd written)
• Trimmed versions (cut the obvious stuff)
• Split by topic (separate skills per domain area)
• Across different foundation models
• Across different agent runtimes

Some results stung. There were scenarios where our carefully written guidance made zero measurable difference. A few cases where it actually made things worse — the model spent attention budget processing our instructions instead of just solving the problem.

But there were also clear wins. Complex, nuanced scenarios — things where even frontier models would make mistakes — showed real improvement with skills. The pattern was clear: skills matter most where the model's training data is thin or the task requires precise, multi-step domain reasoning.

For Cosmos DB, that meant skills were invaluable for things like multi-container data modeling and vector search configuration, but unnecessary for basic CRUD operations or simple queries.

The split skills experiment (and why it mostly didn't help)​

We had a theory: break the monolith into smaller, topic-focused skills. One for data modeling. One for querying. One for SDK patterns. Clean separation.

Sounded great. In practice? The agent loaded three of them for a single task, ending up with roughly the same token count as the monolith. Different filing cabinet, same pile of paper on the desk.

The lesson: splitting only helps if it changes what actually gets loaded per interaction. Reorganizing files doesn't reduce context consumption. You need a mechanism that selectively loads only what's relevant for the current task.

Context rot is real​

Here's something that caught me off guard. A skill that worked beautifully on one model (long context window) completely fell apart on another (tighter window). Same content, wildly different results.

There's research on this phenomenon — even if a model technically supports 200K tokens, its actual attention degrades well before that limit. Information in the middle gets lost. Instructions at the end carry less weight. A big context window is not the same as a big useful context window.

The takeaway: how you package guidance matters as much as what's in it. Skill design isn't just a content problem — it's a delivery problem.

Five principles that actually work​

After months of experimentation, five things consistently improved skill effectiveness regardless of the domain:

1. Steps beat prose, every time​

Our early skills read like documentation — conversational, nuanced, full of "it depends." Models hated it. They'd cherry-pick fragments or hallucinate steps that weren't there.

Rewriting as numbered, deterministic procedures changed everything. For example, instead of "Consider your access patterns and choose appropriately...", we'd write:

1. Identify the most frequent query predicate
2. Check candidate cardinality (must exceed threshold)
3. Validate with a concrete query
4. If below threshold, combine fields into a composite

No ambiguity. No interpretation needed. Pass rates improved immediately across every domain we tested.

2. How you describe the skill matters more than you think​

Our first skill description was vague — something like "Best practices for [Technology X]." It got triggered for everything remotely related, including completely wrong contexts.

The fix: explicit scope boundaries and negative triggers. A good description says what the skill is for and what it's not for. "Do NOT use for [related but different technology]" is surprisingly effective at preventing false matches.

We also found that skill registries degrade in selection accuracy past ~20-30 entries without a retrieval filter. Precise descriptions become doubly important as your skill library grows.

3. Don't front-load everything​

We went from 2000+ lines to a ~400-line core backed by reference files that load on-demand. The core says "For [specific topic], read references/topic-details.md" — and the agent only pulls that in when the task requires it.

Our empirical finding: performance degrades above ~800 lines regardless of model. Keep the entry point lean. Defer supplementary detail to separate files that get loaded only when explicitly needed.

4. Scripts over step-by-step instructions​

Any multi-step operation with dependencies between steps (setup flows, migrations, environment configuration) should be wrapped in a single executable script. Models routinely skip steps, reorder operations, or miss conditional branches when given sequential instructions.

One script call = deterministic execution = no ambiguity. We apply this everywhere a task involves more than two sequential commands with dependencies.

5. Route, don't concatenate​

The real breakthrough: a lightweight "router" skill that examines the task and selectively loads only the relevant sub-skill. A modeling question loads the modeling skill. A performance question loads the optimization skill. Not both.

This cut average context consumption by ~60% with no loss in coverage. The key insight: composition only works if it changes what gets loaded, not just how files are organized on disk.

The bigger lessons​

Three things I'll carry with me:

Measure before you write. We would have sworn certain skills were helping. Data said otherwise. Start with evaluation, not authoring. You'll be surprised what models already know — and even more surprised what they consistently get wrong.

Less is more. Every token competes for attention. A focused 300-line skill covering what the model doesn't already know beats a comprehensive 2000-line one that mostly repeats training data.

This is a new discipline. Writing for AI agents isn't like writing docs, tutorials, or prompts. It's closer to writing a curriculum for a very fast, very literal student who reads everything once and has limited short-term memory. That mental model changes how you structure everything.

Hill-climbing: continuous improvement​

We now treat skills like code — they get tested. The loop:

1. Define what success looks like for a set of tasks
2. Write 10-20 scenarios (including negative cases where the skill should not trigger)
3. Run 5-30 trials per scenario
4. Grade with script graders (did the output actually work?) and LLM graders (was the reasoning sound?)
5. Identify failure patterns, tweak the skill
6. Re-run and compare

Each cycle pushes pass rates up incrementally. It catches regressions when underlying models update. It's tedious, but it's the only way to know if your skills are actually getting better versus just feeling better.

If you're starting out​

My honest advice for anyone building skills in their own domain:

1. Pick the hard stuff. Don't write skills for things models already handle. Focus on areas where you see consistent failures or where domain expertise genuinely matters.
2. Measure from day one. Even a crude eval (5 test cases, 3 trials each) is infinitely better than vibes.
3. Write procedures, not explanations. The agent doesn't need to understand why — it needs to know what to do.
4. Keep it short. If you can't fit the core guidance in 400-500 lines, you're probably trying to cover too much in one skill.
5. Test negative cases. Make sure your skill doesn't trigger where it shouldn't. False positives are as bad as missing coverage.

Minko Gechev gave a great talk on skill design at the AI Coding Summit that covers many of these same principles from a framework perspective. Highly recommend it if you're working in this space.

Six months in, I'm more convinced than ever that the hard problem isn't capturing knowledge — it's delivering it effectively to a system with very different attention patterns than a human reader. We're still learning. But the gap between "skills that feel right" and "skills that measurably work" is where all the interesting problems live.

This session was special to me, not just because of the topic, but because of the person I got to share the stage with.

Scott Hanselman: An Inspiration Since 2014​

Scott Hanselman has been one of my biggest inspirations in the developer community since 2014. His ability to break down complex technical topics, his genuine enthusiasm for empowering developers, and his commitment to making technology accessible have always resonated with me. I've followed his blog, podcasts, and talks for over a decade, and his content has shaped how I think about developer experience and community building.

I had the privilege of meeting Scott in person for the first time in 2018 at the Microsoft MVP Summit in Seattle. As a Microsoft MVP, attending the summit was already a dream come true, but getting to meet and interact with Scott made it truly unforgettable. He was exactly as warm, approachable, and passionate in person as he comes across in his content. That encounter reinforced my belief that the best technologists are those who lift others up.

Fast forward to 2026, and here I am, joining him on the Azure Developers Show to demo the work our team has been building. It's one of those full-circle moments that remind you why you keep pushing forward in your career.

What We Covered in the Session​

In the session, we explored how the Azure Cosmos DB Agent Kit transforms AI-powered coding agents into database experts. Here's a breakdown of what we discussed:

The Problem​

Coding agents like GitHub Copilot, Claude, and others are incredibly powerful for general programming tasks, but they often lack deep expertise when it comes to specific database operations, query optimization, and data modeling best practices for Azure Cosmos DB.

The Solution: Azure Cosmos DB Agent Kit​

The Agent Kit bridges this gap by providing coding agents with:

• Schema discovery — Agents can explore your database structure, understand containers, partition keys, and indexing policies
• Intelligent CRUD operations — Context-aware create, read, update, and delete operations that follow Cosmos DB best practices
• Query optimization — AI-assisted query building that respects partition key strategies and minimizes RU consumption
• Vector search capabilities — Enabling agents to perform semantic queries against your data
• MCP integration — Seamless integration through the Model Context Protocol for tool-augmented AI workflows

Key Takeaways​

1. Agent-first development is becoming the norm — developers increasingly rely on AI agents for database interactions
2. Domain-specific toolkits like the Agent Kit are essential for agents to provide expert-level guidance
3. The MCP protocol enables standardized communication between AI agents and tools, making integrations portable across different AI assistants
4. Developer experience matters — The Agent Kit is designed to feel natural within existing development workflows

Watch the Full Session​

If you missed the live session, you can watch the full recording here:

Watch on YouTube →

A Note of Gratitude​

Thank you, Scott, for the opportunity and for being such a generous host. And thank you to the Azure Developers team for having me on the show. Moments like these fuel my passion for building tools that make developers' lives better.

If you're working with Azure Cosmos DB and want to supercharge your coding agents, check out the Azure Cosmos DB Agent Kit and let me know what you think!

I'm excited to announce the release of Angular Agent Kit - a collection of AI coding agent skills designed specifically for Angular developers. This toolkit extends the capabilities of AI coding assistants like GitHub Copilot, Claude Code, Cursor, and Gemini CLI with deep Angular expertise.

What is Angular Agent Kit?​

Angular Agent Kit is a collection of skills that follow the Agent Skills specification. These skills are packaged instructions and scripts that extend AI agent capabilities, enabling them to provide expert-level guidance on Angular development.

The Problem It Solves​

As Angular applications grow in complexity, maintaining performance becomes increasingly challenging. Developers often struggle with:

• Change detection optimization - Understanding when to use OnPush strategy
• Bundle size management - Identifying and eliminating bloat
• Template performance - Writing efficient templates that don't cause unnecessary re-renders
• RxJS patterns - Avoiding memory leaks and implementing efficient async operations

While AI coding assistants are powerful, they sometimes lack the specialized Angular knowledge needed to provide optimal recommendations. Angular Agent Kit bridges this gap.

Available Skills​

angular-best-practices​

The flagship skill contains 45+ rules across 8 categories, prioritized by their impact on application performance:

Installation​

Getting started is simple with a single command:

npx skills add sajeetharan/angular-agent-kit

Usage Examples​

Once installed, skills are automatically available. Simply ask your AI assistant:

Review my Angular component for performance issues

Help me optimize change detection in this component

Optimize this Angular template for better performance

The AI agent will automatically leverage the Angular best practices rules to provide expert-level recommendations.

Compatibility​

Angular Agent Kit works with all major AI coding tools:

• GitHub Copilot - Works seamlessly in VS Code
• Claude Code - Full support for Claude's coding assistant
• Cursor - Enhanced Angular development experience
• Gemini CLI - Google's AI coding assistant
• Any other Agent Skills-compatible tools

Skill Structure​

Each skill in the kit follows a consistent structure:

• SKILL.md - Instructions that trigger skill activation
• AGENTS.md - Compiled rules that agents read
• rules/ - Individual rule files for easy maintenance
• metadata.json - Version and metadata information

Why I Built This​

As someone who works extensively with Angular and AI development tools, I noticed a gap between generic AI coding assistance and Angular-specific expertise. The rules in this kit are distilled from years of Angular development experience, official Angular documentation, and community best practices.

Acknowledgments​

This project was inspired by:

• Vercel's React Best Practices
• The Agent Skills specification
• Angular team's official documentation

Contributing​

Contributions are welcome! If you have Angular best practices that should be included, or improvements to existing rules, please check out the CONTRIBUTING.md file for guidelines.

Get Started Today​

Ready to supercharge your Angular development with AI-powered best practices?

1. Install the skill: npx skills add sajeetharan/angular-agent-kit
2. Open your Angular project
3. Ask your AI assistant for Angular optimization help

Check out the GitHub repository for more details and to star the project if you find it useful!

Have questions or feedback? Feel free to open an issue on GitHub or reach out to me on Twitter!

I'm thrilled to introduce Angular Visual Storybook - an interactive learning resource that transforms complex Angular concepts into easy-to-understand visual infographics. Whether you're a beginner starting your Angular journey or an experienced developer looking for quick reference guides, this comprehensive collection has something for everyone.

What is Angular Visual Storybook?​

Angular Visual Storybook is a static website that provides a comprehensive visual guide to Angular development through 26 beautifully designed infographics. It's built with pure HTML5, CSS3, and JavaScript - no frameworks required! The project is perfect for visual learners and developers who prefer a structured, comprehensive approach to learning Angular.

🔗 Live Demo: sajeetharan.github.io/angular-graphic

🌟 Features​

• 📚 26 Comprehensive Topics - From Angular Overview to AI Integration
• 🎨 Beautiful Design - Modern, responsive UI with smooth animations
• 🔒 Image Protection - Multiple layers of protection to prevent unauthorized downloading
• 📱 Mobile Friendly - Fully responsive design that works on all devices
• ♿ Accessible - WCAG-compliant with keyboard navigation support
• 🚀 Performance Optimized - Fast loading with intersection observers and lazy loading
• 🔍 Search Functionality - Quick search through topics in the sidebar
• 📊 Progress Tracking - Visual progress bar as you scroll through content

Topics Covered​

The storybook covers all major Angular topics from the official Angular documentation:

🛠️ Technologies Used​

What makes this project special is its simplicity:

• Pure HTML5, CSS3, and JavaScript - No frameworks required!
• CSS Grid & Flexbox for responsive layouts
• Intersection Observer API for scroll detection
• Modern ES6+ JavaScript features

Quick Start​

Want to run it locally? It's incredibly simple:

# Clone the repository
git clone https://github.com/sajeetharan/angular-graphic.git
cd angular-graphic

# Using Python
python -m http.server 8000

# Or using Node.js
npx http-server

# Then visit http://localhost:8000

🔒 Image Protection Features​

The website implements multiple layers of image protection:

1. Right-Click Prevention - Context menu disabled on images
2. Drag-and-Drop Blocking - Images cannot be dragged
3. Keyboard Shortcut Blocking - Common save shortcuts are intercepted
4. CSS Protection - User-select and drag properties disabled
5. Visual Feedback - Warning overlay when protection is triggered
6. Mobile Long-Press Protection - Touch events handled to prevent saving

Why I Built This​

Learning Angular can be overwhelming with its extensive documentation and numerous concepts. I wanted to create a resource that:

• Simplifies complex concepts through visual representation
• Provides quick reference for experienced developers
• Offers an engaging learning experience for beginners
• Works offline once loaded - perfect for on-the-go learning

🎨 Customization​

The project is highly customizable. You can easily modify colors by editing CSS variables:

:root {
  --primary-color: #dd0031; /* Angular red */
  --secondary-color: #c3002f; /* Darker red */
  --accent-color: #0066ff; /* Blue accent */
}

Contributing​

Contributions are welcome! If you have ideas for new infographics or improvements:

1. Fork the repository
2. Create your feature branch (git checkout -b feature/AmazingFeature)
3. Commit your changes
4. Push to the branch
5. Open a Pull Request

🙏 Acknowledgments​

• Content structure inspired by angular.dev
• Infographics created for educational purposes
• Built with ❤️ for the Angular community

Get Started Today​

Ready to learn Angular visually?

• 🌐 Visit the live site: sajeetharan.github.io/angular-graphic
• 📦 Clone the repo: github.com/sajeetharan/angular-graphic

Have feedback or suggestions? Feel free to open an issue on GitHub or reach out to me on Twitter!

In last November 2021, Cosmos DB team has announced support for patching documents with SQL API which was the top requested features in the user voice. This is a useful and long-awaited feature among users. Prior to this announcement the only way to change the stored document was to completely replace it. Users will be able to perform Partial updates with all the Cosmos DB SDKs ( JAVA, . Net , JS ) and also Cosmos DB REST API.

Use Case:

Let's look at a scenario of a dashboard application where user need to display the System and it's features. User has decided to use Cosmos DB as a database to store the data of a System and it's features. A sample document would look as follows.

{
    "ApplicationId": "App-01",
    "ApplicationName": "New Cosmos Client",
    "Description": "This shows the users and interactions",
    "IsDraft": 0,
    "IsSaved": 1,
    "Features": [
        {
            "SystemID": 1,
            "Features": [
                {
                    "FeatureID": 4,
                    "FeatureName": "Patch",
                    "IsActive": false
                },
                {
                    "FeatureID": 35,
                    "FeatureName": "Feature-a-2",
                    "IsActive": false
                },
                {
                    "FeatureID": 36,
                    "FeatureName": "test-feature-a-3",
                    "IsActive": true
                }
            ]
        }
    ],
    "id": "af3dfd7a-b7e9-4467-a2ca-9c6be7ad5b9f",
    "_rid": "S1xQAKKOTBABAAAAAAAAAA==",
    "_self": "dbs/S1xQAA==/colls/S1xQAKKOTBA=/docs/S1xQAKKOTBABAAAAAAAAAA==/",
    "_etag": "\"31003582-0000-0700-0000-6213cb6b0000\"",
    "_attachments": "attachments/",
    "_ts": 1645464427
}

Let's look at some of the scenarios where user needs to perform patch operations.

Patch Scenario 1:  Add a new record (JSON object) under Features parent array

JSON object to Add:

{
       "SystemID": 2,
       "Features": [
       {
          "FeatureID": 1,
          "FeatureName": "Reports",
          "IsActive": false
       }
     ]
 }

You can refer my previous blog on How to setup Rest Operations with Postman. Once you've configured the setup with the underlying database and container. Here we need to insert a new Object within the Features array, certainly we can leverage the Single Add Operation. And the sample request Body will be like,

Patch Url : [https://account/dbs/dbName/colls/Patch/docs/id of the document](https://account/dbs/dbName/colls/Patch/docs/id of the document) and the header "x-ms-documentdb-partitionkey" is set to the partition key value which is the "ApplicationId" "App-01". And we need to specify the path as "/Features/-"

On a successful response, in the backend you will see that a new Object that is shown above will be added to the Features array.

Patch Scenario 2:  Update the Application Description in the root Object to "Testing Patch with REST API"

Patch Scenario 3:  Update only a specific Feature object in array for a given Features parent object like FeatureName . Let's assume if we need to update the Object at the 0th index and then update the First Features Object,

Patch Scenario 4 : Perform all the above operations as a single request

Since Partial document update supports up to 10 operations in a single request, all the above operations can be merged. User needs to combine all the operations as one as below,

{
   "operations":[
     {
         "op":"replace",
         "path":"/Features/0/Features/0/FeatureName",
         "value":"Patch Testing"
    },
    {
         "op":"set",
         "path":"/Description",
         "value":"Testing Patch with REST API"
    },
    {
    "op":"add",
    "path":"/Features/-",
    "value":{
       "SystemID": 2,
       "Features": [
           {
               "FeatureID": 1,
               "FeatureName": "Reports",
               "IsActive": false
           }
       ]
    }
   }
 ]
}

Hope these samples help you to perform different operations at different path using Cosmos Rest API. Cheers!

As a Developer, If you have a requirement to have list of work items which are approved to be displayed in a Grid View. You would tend to query for all approved work items and display them in the grid, one point to note is that since the amount of approved work items might grow over time, hence loading the data would get slower and slower due to having to download more items. In general, this is where pagination comes into play in front end development, which means you don't need to necessarily download all records, just download a page of records at a time. If you are using Cosmos DB as a backend, this feature is supported out of the box via the use of Continuation Token. Cosmos DB SDKs utilize a continuation strategy when managing the results returned from the queries.

Pagination with @Azure/cosmos SDK:​

One of the frequent questions I have come across on forums is on How to Implement Pagination with @azure/cosmos SDK with JavaScript. With this post , I wanted to keep it simple and add a very minimal quick start on how to implementation pagination with .js SDK. You can follow the steps given in the repository.

Prerequisites:​

• Create a CosmosDB Account of type SQL API and database named 'javascript' and collection named 'products'
• Insert the data 'ProductsData.json' to CosmosDB using the Data Migration Tool

execute.ts is the start point of the application which invokes the CallPagination method defined in the pagination.service.ts.

import dotenv from "dotenv"
import { Helper } from './helper';
import PaginationService from './pagination.service';

dotenv.config()

const cosmosDB = new Helper();
const pageMod = new PaginationService(cosmosDB);


const callPagination = async () => {
    const result = await pageMod.executeSample(2, "")
    console.log({
        data: result.result,
        dataLength: result.result.length,
        hasMoreResult: result.hasMoreResults,
        contToken: result.continuationToken
    });
};

callPagination();

Implementation is really simple as we are passing a simple query that has more than 40 records and we set the pageLimit as 5 which is the max number of items to be returned in single call.

 public async executeSample(
    pageLimit: number = 5,
    contToken: string = ""
  ): Promise<{
    result: Array<any>;
    hasMoreResults: boolean;
    continuationToken: string;
  }> {
    const sqlQuery =
      `SELECT * from products where products.CategoryName = "Bikes, Road Bikes"`
    console.log({ sqlQuery })

    const { result, hasMoreResults, continuationToken } =
      await this.cosmosHelper.queryContainerNext(
        {
          query: sqlQuery
        },
        {
          maxItemCount: pageLimit,
          continuationToken: contToken
        },
        process.env.CONTAINER_NAME
      );

    return {
      result: result || [],
      hasMoreResults: hasMoreResults || false,
      continuationToken: continuationToken || "",
    };
  }

You can access the whole sample from this link.

Steps to Run the application​

• Clone the Repository
• Run npm install
• Replace the environment COSMOS_ENDPOINT,COSMOS_KEY,COSMOS_DATABASE_NAME,CONTAINER_NAME in the .env file
• Run npm start run the application

Hope this helps someone who wants to implement Pagination with JavaScript. Cheers!

Azure Data Lake is a big data solution which allows organizations to ingest multiple data sets covering structured, unstructured, and semi-structured data into an infinitely scalable data lake enabling storage, processing, and analytics. It enables users to build their own customized analytical platform to fit any analytical requirements in terms of volume, speed, and quality.

In the context of above, the book "Cloud Scale Analytics with Azure Data Services" book is your guide to learning all the features and capabilities of Azure data services for storing, processing, and analyzing data (structured, unstructured, and semi-structured) of any size. You will explore key techniques for ingesting and storing data and perform batch, streaming, and interactive analytics

The book also shows you how to overcome various challenges and complexities relating to productivity and scaling. Next, you will be able to develop and run massive data workloads to perform different actions. Using a cloud based big data-modern data warehouse–analytics setup, you will also be able to build secure, scalable data estates for enterprises. Finally, you will not only learn how to develop a data warehouse but also understand how to create enterprise-grade security and auditing big data programs.

By the end of this Azure book, you will have learned how to develop a powerful and efficient analytical platform to meet enterprise needs.

WIN YOUR FREE COPY​

Enter your details and Click Submit to enter our monthly prize draw. Take your chance to receive one of the 10 free copies as give away.

In this blog post you will learn about the Azure Cosmos DB SQL API queries and How to get started with Cosmos DB SQL API. I recently published a video on youtube and decided to have it available in blog as well. Azure Cosmos DB is a fully managed NoSQL multi model database service provided by Azure which is highly available, globally distributed, and responds back within the minimum latency in single digit millisecond. It's becoming the preferred database for developers on Azure to build modern day applications.

You can access the slides here and repository for the queries here.

Azure supports multiple data models including documents, key-value, graph, and column-family with multi models APIs such as SQL,Mongo,Cassandra,Gremlin and Table. SQL APi is one of them and its oldest offerings on cosmos db. SQL API is also known as Core API which means that any new feature which is rolled out to cosmos db usually first available in SQL API accounts. It supports for querying the items using the Structured query language Syntax which provides a way to query JSON objects.

Also cosmos db SQL API queries can be done using any SDK we provide with Net, Java, Node and python.

Azure Cosmos DB is truly schema-free. Whenever you store data, it provides automatic indexing of JSON documents without requiring explicit schema or creation of secondary indexes.

The Azure Cosmos DB database account is a unique name space that gives you access to Azure Cosmos DB.

A database account consists of a set of databases, each containing multiple collections, each of which can contain stored procedures, triggers, UDFs, documents, and related attachments.

Ways to Manage Cosmosdb Documents :​

With the Cosmos DB SQL API , you can create documents using a variety of different tools :

Portal: The Data Explorer is a tool embedded within the Azure Cosmos DB blade in the Azure Portal that allows you to view, modify and add documents to your Cosmos DB API collections. Within the explorer, you can upload one or more JSON documents directly into a specific database or collection which i will be showing in a bit

SDK: Cosmos DB database service that was released prior to Azure Cosmos DB featured a variety of SDKs available across many languages

REST API : As we mentioned previously, JSON documents stored in SQL API are managed through a well-defined hierarchy of database resources. These resources are each addressable using a unique URI. Since each resource has a unique URI, many of the concepts in Restful API design applies to SQL API resources

Data Migration Tool: The open-source Cosmos DB data migration tool which allows you to import data into a SQL API collection from various sources including MongoDB, SQL Server, Table Storage, Amazon DynamoDB, HBase and other Cosmosdb collections.

Prerequisites:​

For this overview demo , I will be using a dataset Tweets which contains Tweets by users across the world on certain tags says #Azure and #Cosmosdb

To replicate the demo you can use the Emulator which you can download from here Cosmosdb Emulator . Or you can create a Cosmosdb free tier account which is handy for developers.Azure Cosmos DB free tier makes it easy to get started, develop, test your applications, or even run small production workloads for free. When free tier is enabled on an account, you'll get the first 1000 RU/s and 25 GB of storage in the account for free.

In this demo let me migrate this sample dataset tweets which has 1000 recent tweets from users who actually tweeted about different technologies. I have uploaded the dataset in my github account and we will be using the same to understand different queries.

• Create a CosmosDB Account of type SQL API and database/collection named Tweets
• Insert the data inside the folder Tweets to CosmosDB using the Data Migration Tool

SQL API Queries :​

Once you created the Cosmos DB account on Azure , Navigate to Settings -> Key and copy the Endpoint and the Url for the Cosmos DB account and replace the values in the Program.cs ( This is not recommended for production use , use Keyvault instead).

  // The Azure Cosmos DB endpoint for running this sample.
  private static readonly string EndpointUri = "https://sajee-cosmos-notebooks.documents.azure.com:443/";
  // The primary key for the Azure Cosmos account.
  private static readonly string PrimaryKey = "==";

Before dive into the queries , let me explain one of the most important thing to deal with queries in Cosmos DB. In Cosmos DB SQL API accounts, there are two ways to read data.

Point reads – Which denotes you can do a key value lookup on a single item id and a partition key. Point reads usually cost 1 RU With a latency under 10 Milli seconds.

SQL queries - SQL queries consume more Rus in general than the point reads . So if you need a single item, point reads are cheaper and faster.

As a developer we tend to execute select * from table which might cause you more RUs since you are reading the whole data across multiple partitions.

Let's dive into some of the queries with SQL API

Query 1 : Select All​

To retrieve all items from the container, in this case let's get all the tweets. Type this query into the query editor:

SELECT *
FROM tweets

...and click on Execute Query!

Few things to note here are, It retrieves the first 100 items from the container and if you need to retrieve the next 100, you could click on load more , under the hood it uses the pagination mechanism. Another handy thing here is that you can navigate to query stats and see more details on the query such as RUs, Document size, Execution time etc.

Query 2 : Filter Path​

When referring to fields you must use the alias you define in the FROM clause. We have to provide the full "path" to the properties of the objects within the container. For example, if you need to get the RetweetCount from the container for all the items.

SELECT tweets.RetweetCount
FROM tweets

Query 3 : Join​

Lets see how we can find out the hashtags that have been used in all the tweets. We can use the JOIN keyword to join to our hashtags array in each tweet. We can also give it an alias and inspect its properties.

Let's see the JOIN in action. Try this query:

SELECT hashtags
FROM tweets
JOIN hashtags IN tweets.Hashtags

Now that we know how to join to our child array we can use it for filtering. Lets find all other hashtags that have been used along with the known hashtags (#Azure, #CosmosDB):

SELECT hashtags
FROM tweets
JOIN hashutcDate IN tweets.Hashtags
WHERE hashtags.text NOT IN ("CosmosDB", "Azure")

Similarly we can use OR,IN,DISTINCT,GROUPBY etc.

Query 4 : KEYWORDS (IN,OR etc)​

To return the entire tweet where the indices of the hashtag is between 11 and 18 simply by selecting the tweets rather than the indices

SELECT tweets
FROM tweets
JOIN hashtags IN tweets.Hashtags
JOIN indices IN hashtags.indices
WHERE indices BETWEEN 11 AND 18

Query 5 : ORDERBY and TOP​

We can also order our query so we can find the most recent tweet(s) and retrieve the top 5 tweets. (use ASC for ascending and DESC for Descending) :

SELECT TOP 5 tweets
FROM tweets
JOIN hashtags IN tweets.Hashtags
JOIN indices IN hashtags.indices
WHERE indices BETWEEN 21 AND 28
ORDER BY tweets

Query 6 : PROJECTION​

We can use a feature called Projection to create an entirely new result set. We could use this to create a common structure or to make it match a structure we already have.

Try this query:

SELECT tweets.CreatedBy.Name AS Name,
		tweets.FullText AS Text,
		tweets.CreatedAt AS CreatedTime,
        tweets.TweetDTO.metadata.iso_language_code AS LanguageCode
FROM tweets

Query 7 : USER DEFINED FUNCTION​

The SQL API supports javascript User defined functions, there that you can use on this server called displayDate which removes the time parts of a UTC date string.

This is the function :

function displayDate(inputDate) {
    return inputDate.split('T')[0];
}

Let's have a go at using it

SELECT tweets.CreatedAt,
    udf.displayDate(tweets.CreatedAt) AS FormattedDate
FROM tweets

The SQL API also supports stored procedures written in JavaScript which enables you to perform ACID transactions over multiple records. This allows scalable and almost unlimited expandability on the functionality Azure Cosmos DB can offer.

These are some of the basic queries to get started with CosmosDB SQL API. If you want to get to know more about SQL API the following references would be useful.

• SQL API quickstart
• Data Migration Tools Cosmos DB

Hope this post help you get started with CosmosDB SQL API! Cheers!

I have already published an article which demonstrates how to deploy to Azure Static Web Apps using GithubActions. Azure static web apps team announced the public preview of Azure Devops with Azure static web apps yesterday.

In this post you I will walk you through on how to deploy an angular application to Azure static web apps using Azure Devops.

PreRequisites:​

• An Azure account (you can use free trial, If you don't have one, you can create an account for free)
• Azure DevOps  (If you need help getting started, see Create one)

Step 1 : Create a Devops repository​

Navigate to Dev.Azure.com and create a new Devops Repository as below

Step 2 : Import your static web application to Azure Devops repository​

https://github.com/microsoft/static-web-apps-gallery-code-samplesNext step is to import the web application from any source control to your newly created Azure Devops repository. In this case i am importing the same "Meme generator" app which was made of Angular. Meme4Fun is an app to create custom programming memes from a picture and it also identifies features of people in the image which is available as part of code samples for Azure static web apps.

Step 3 : Create a static web app on Azure​

Next step is to create the static web application on azure, navigate to azure portal and create a new resource by searching for Static Web apps, and create it.

Note : Since I am going to leverage Azure Devops as the deployment method, select Other as the option.

Once the deployment is successful, navigate to the new Static Web Apps resource and select Manage deployment token.

Step 4: Create the Pipeline task in Azure Devops​

If you are using Azure Devops to deploy applications in the past, you will need to have the pipeline in plact to deploy to particular resource. In this case, lets create a build pipeline to deploy the angular application.

Next step is to select the template, since we are deploying an angular application, you can select the template as angular with nodejs

Also for static web apps it is important to include the following step in the yaml which has the app_location, api_location, and output_location , you need to pass those values if you have those details if not keep it empty.

and the final configure YAML will look similar to the below,

# Node.js with Angular
# Build a Node.js project that uses Angular.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
- master
pool:
  vmImage: ubuntu-latest
steps:
- task: NodeTool@0
  inputs:
    versionSpec: '10.x'
  displayName: 'Install Node.js'
- script: |
    npm install -g @angular/cli
    npm install
    ng build --prod
  displayName: 'npm install and build'
- task: AzureStaticWebApp@0
  inputs:
      app_location: "/" 
      api_location: "api"
      output_location: "dist/meme4fun"
  env:
      azure_static_web_apps_api_token: $(deployment_token)

Next step is to provide the The **azure_static_web_apps_api_token** value is self managed and is manually configured. Select Variables in the pipeline and create a new variable named as "deployment_token"(matching the name in the workflow) below.

Make sure to check "Keep the value secret" and save the workflow and run.

With that step Azure Devops will execute the pipeline and deploy the application to azure static web apps.

Now you can access the application from the static static web app from the URL.

If you had any trouble in executing the above steps, you can watch the same tutorial published as a video here.

It's great to see that with few steps of configuration, i was able to deploy the application with Azure Devops. If you have enabled backend support with the azure functions, it can be deployed as well. Support with Azure Devops has been one of the most requested features by developers and great to see it in live now. It's your chance to explore various application deployments with different frameworks, hope this is useful. Cheers!

As per a survey, 57% of young individuals agreed they do not have the right connections to find a mentor and more than 50% of them couldn't find a job that they are passionate about. As a result I was exploring if there is any platform that would solve this major problem. Yes, there are some existing online apps but those don't serve the complete purpose to the extent that i expected. I decided to start a pet project to build this platform during my spare time , in this post i will be sharing the architecture of the application and how i was able to quickly spin up this application.

 Prerequisites to build and deploy​

As an Azure fan, i have used Azure as the cloud platform to deploy this solution. Here are some prerequisites first:

• An Azure account (don’t worry, deploying this app costed me almost nothing, you can use free trial)
• node and npm (preferably the latest versions)
• VSCode and Android Studio

As i explained in the previous posts, Cosmosdb and Azure Functions are great combo to build applications and deploy in quick time without worrying about underlying infrastructure. You can read about some of the reference architectures i have posted in the past from the below links,

• Game with Cosmosdb
• How Azure CosmosDB + Functions + IOT hub + PowerBI could solve the burning Traffic problem
• Facial Recognition solution for the fraud prevention using Azure AI and Cosmosdb
• Github Issue Reporter with Azure Function and CosmosDB

Let me dive into each component in the architecture of 'MentorLab'.

How it works?​

MentorLab has been made to scale up the existing students and mentors using Azure Services and Serverless Architecture to provide a cost-economic one stop solution which is dependable and truly secure. The objective is to give the students a platform which is built on a serverless architecture and can be remotely accessed irrespective of geographic location.

There are two facets of this solution​

• Mentor Side - Dashboard (Flutter)
• Students Side - Mobile App (Flutter)

Azure Services Used ​

• Github Actions
• Active Directory (A2D)
• Blob Storage
• Azure Cosmos DB
• API Management
• Azure Functions
• Monitor

Flutter App is the front end application which is accessed by Mentor and Developer with different types of logins, All the requests from the mobile app will be router via the AppGateway. The backend APIs are built as servelress APIs with Azure functions with the support of Cosmosdb Trigger. Cosmosd's serverless feature is a great offering when building these kind of applications, as it is a cost-effective option for databases with sporadic traffic patterns and modest bursts. It eliminates the concept of provisioned throughput and instead charges you for the RUs your database operations consume. In this scenario, i have chosen Mongo API for the CRUD operations. The APIs are registered as endpoints with the Azure API management with right policies in place.

Some of the additional components you could see in the diagram are the CI/CD pipelines with Github Actions and Azure AD B2C for the authorization, Key vault for storing the connection strings,keys in a secured way. And finally application insights to generate the related metrics and for troubleshooting.

It nearly took just 3 days to build this application and going forward i am planning to add more features such as video conferencing with the help of Azure Communication and Media services . All these components just costs 36$/Month to host this application on Azure.

Hope this reference architecture helps you to kickstart your work for similar application. Feel free to add your thoughts/Questions as comments in the section below. Happy Hacking!

• A proactive approach.
• Get visibility of your infrastructure and application issues
• React fast to an issue and mitigate quickly.
• Increase your application availability
• Reduce application downtime

I have been involved in lot of discussions with customers and partners on how to setup alerts in order to proactively get to know the issues and help the customers. One of the frequent questions i noticed is that about how to setup SMS alerts. In this post i wanted to cover about how to setup SMS alert on Azure at a minimal cost.

PreRequisities:​

You will need to have an Azure Subscription. If you do not have an Azure subscription you can simply create one with free trial.

Services used:​

• Azure Logic Apps
• Azure Monitor
• Twilio API
• Azure Virtual Machine

There is no SMS notification service readily available on Azure as of now. Even though Azure Communication Service which Integrate SMS into existing applications and workflows with Azure services Logic Apps and Event Grid is still in preview and not supported in many countries. In this case you could integrate with any of the SMS providers. In this case i will use one of the famous SMS provider which i have used in many of the projects in the past.

Step 1 : Create the Resource Group

As the first step, we need to create the resource group that contains all the resources needed. In your case, you might already have an Azure environment with all the resources. Navigate to Azure Portal and create the resource group named “smsalert”

Step 2 : Create the application and deploy on Azure VM

In this case, i will be focusing on setting up alerts on a Virtual Machine, If you already have an application deployed on any compute services such as AppService or AKS you could replicate the same steps. You might not need to do this step as its about application deployment. I will use the Devops starter resource to deploy a Dotnet core application and choose VM as the compute option to deploy my application.

Search for Devops starter in the search bar and create a new ASPNet core application and choose VM as the destination to be deployed.

Once the application is deployed you could access the application from the url and you can login to the VM as well.

Now we have the application deployed on VM, assume if you want to monitor the performance and setup alert whenever it breaches certain condition, lets setup azure monitor integrated with Logic apps.

Step 2 : Create Logic app Integrated with Twilio

You need to setup a Twilio account inorder to send the SMS alerts, the free tier gives a worth of 15$ credits which would be enough for 4000 messages. You will also get a number to send SMSes from the account portal. If you need a custom number you can set it up with extra cost.

Let's create the logic app, you can search for Logic app resource on the search bar and create a Logic app with the name smsalert under the same resource group.

Next step is to configure the steps in logic app , whenever a request is received from the azure monitor, we need to send the SMS to relevant members in the team which can be configured with 2 steps as below,

Add the first step as when an http request is received and we need to map the schema of alert inorder to get the information from the alert and to send the sms. Paste the schema object in the request body.

Next step is to add the twilio connector inorder to send the SMS when an alert is recieved. you can configure the twilio send text message step as below, you need to pass the account SID and the access token in the configuration.

You can also pass a custom text which consists of any of the parameters that recieved from the alert, say for ex. CPU percentage, time etc.

Now we are ready with the logic app integrated with Twilio, next step is to create the alert rule on the vm to send the SMS

Step 3 : Setup Alert Rule to send SMS notification.

Open the VM resource , on the blade navigate to Alerts and click on new alert rule, by default you can see that the resource is selected as the VM, next step is to setup the condition when you need to fire the alert, this can be a combination of multiple configurations, you can choose it from the predefined configurations. In this case i will choose the condition as "When the percentage CPU goes above 10%".

We are good with the condition just for this demo purpose, but you can play around multiple conditions in combinationas you need for your environment.

Step 4: Add Action Group

In the "Add action group" section, we have to create an Action Group Name and we need to choose the Logic app as action and select the logic app which you have created in the above step,

Once you are done with the action group, just pass the alert rule details and set the severity level.

We are done with all the steps needed to send the SMS alert, now whenever the CPU usage goes above 10% the configured number will get an SMS message. If you want to send the SMS to multiple members in the team, you could just use the for condition in logic app and send it to multiple members.

Step 5 : Manage Alert Rules

You can also manage the alert rules based on the severity and if the action has been taken on those alerts and recrtified from the manage alerts section.

That's all i wanted to cover in this post, one thing to note is that i have seen many customers who already have setup email notifications via the Azure monitor, but SMS is not still readily available in all countries if you've noticed.

Hope this helps to setup SMS alerts on any resource that you use as compute option to run your application. Cheers!

It allows developers to use a fully-featured, cloud-hosted development environment that spins up in seconds Directly within Github. This will help you to start contributing to a project immediately from any machine, all without needing to install anything locally. If you are a developer, you should be a fan of this one. As we’ve all been adopting practices like social distancing and remote working, development teams have become more distributed. In this post, i wanted to share one of the productivity tips on how to open your code directly from the browser via codespaces.

You just need to open your repository and add "1s" after github when viewing the codebase on browser and github codespaces loads up instantly.

Here is the action below!

One thing to note here is that, this feature is not directly from the Github codespaces itself, it is enabled via the 1s which is sort of a middleware repository enabling this! However it's a great feature and worth exploring it!

Hope this enable more developers to contribute to Opensource world instantly. Cheers!

Are you are .Net developer interested in building Microservice based applications to the Cloud?. Recently i gave a talk about announcements on DotNet ecosystem and building Cloud Native applcitions with Tye and i decided to write on the same topic . Tye is an amazing project from Microsoft to ease the development, deployment with two fundamental cloud native technologies such as Docker and Kubernetes. If you have been deploying Applications in production using containers, you must be already aware of how complex steps you need to make in order to get your application running. I have worked on multiple projects where I have to run many modules as dependencies at the same time, even though I was only  working on one of them. There has always been a requirement for a tool to start, deploy applications with a  simple command to your desired environment without spending much time on creating docker files, configurations etc.

What is Project Tye?​

Tye is an experimental developer tool from the .NET team at Microsoft that makes developing, testing, and deploying microservices and distributed applications easier. It comprises a local orhestrator to assist the developers to develop microservices, deploy them to kubernetes with minimal configuration and steps.

• Service discovery via configuration conventions makes Developers to expose their API with proper documentation
• Add dependencies (Redis, SQL Server, etc.) without writing docker files
• Run and debug locally using containers and Kubernetes
• Local dashboard for metrics, logging, debugging
• Automatically dockerize and deploy to Azure Kubernetes Service

What I like really like about Project Tye is that it has a very small footprint and it is so simple to get started with after spending so many years with docker and K8s. It offers the following capabilities,

Getting Started​

Let's see how to get started with project Tye. You need to have the following Prerequisites in order to run the following application successfully.

• Azure Subscription (Free Trial)
• Dotnet SDK latest
• Visual Studio / Visual Studio Code
• Docker/Kubernetes Extension VSCode ( Optional)

You can install Project Tye as a global .NET tool. In order to install the utility, you need to run the following command in your terminal

dotnet tool install -g Microsoft.Tye --version "0.2.0-alpha.20258.3"

To verify that Tye was installed properly you can run the following command that should output the current version installed:

> tye --version

Create a Simple Application​

This section will demonstrate how to use Tye to run multi-project application.

Step 1 : Make a new folder named dotnetconfApp

mkdir dotnetconfApp
cd dotnetconfApp

Step 2 : Create a frontend project with Razor

dotnet new razor -n frontend

Step 3 : To run the frond end project, execute the following command

tye run frontend

As you could see above tye will do two things: start the frontend application and run a dashboard. Navigate to http://localhost:8000 to see the dashboard running.

The dashboard should show the frontend application running.

• The Logs column has a link to view the streaming logs for the service.
• the Bindings column has links to the listening URLs of the service.

Add Multiple Projects​

Step 1 : Let's go ahead and add a Web API to fetch the data for the front end application. If you haven't already, stop the existing tye run command using Ctrl + C. Create a backend API that the frontend will call inside of the microservices/ folder.

dotnet new webapi -n backend

Step 2 : Create a solution file and add both projects

dotnet new sln
dotnet sln add frontend backend

You should have a solution called dotnetconfapp.sln that references the frontend and backend projects.

Step 3: Run the multiple projects with tye . Execute the following command within the solution folder,

tye run

The dashboard should show both the frontend and backend services. You can navigate to both of them through either the dashboard of the url outputted by tye run.

Make the Communication between the frontend and backend​

As you see above, we have both the backend and frontend applications running, let's make them communicate. By default, tye enables service discovery by injecting environment variables with a specific naming convention.

Step 1: Open the solution folder with VSCode or Visual Studio

Step 2 : As we need to fetch and bind the data from the sample WebApi , lets add a Contract named WeatherForecast.cs to the frontend project and it should match the contract that exist in the backend project WeatherForecast.cs

using System;

namespace frontend
{
    public class WeatherForecast
    {
        public DateTime Date { get; set; }

        public int TemperatureC { get; set; }

        public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

        public string Summary { get; set; }
    }
}

Step 3: Add a file WeatherClient.cs to the frontend project with the following contents:

using System.Net.Http;
using System.Text.Json;
using System.Threading.Tasks;

 namespace frontend
 {
     public class WeatherClient
     {
         private readonly JsonSerializerOptions options = new JsonSerializerOptions()
         {
             PropertyNameCaseInsensitive = true,
             PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
         };
 
         private readonly HttpClient client;
 
         public WeatherClient(HttpClient client)
         {
             this.client = client;
         }
 
         public async Task<WeatherForecast[]> GetWeatherAsync()
         {
             var responseMessage = await this.client.GetAsync("/weatherforecast");
             var stream = await responseMessage.Content.ReadAsStreamAsync();
             return await JsonSerializer.DeserializeAsync<WeatherForecast[]>(stream, options);
         }
     }
 }

Step 4 : Add a reference to the Microsoft.Tye.Extensions.Configuration package to the frontend project

dotnet add frontend/frontend.csproj package Microsoft.Tye.Extensions.Configuration  --version "0.4.0-*"

Step 5 : Register  this client in frontend by adding the following to the existing ConfigureServices method to the existing Startup.cs file:

...
public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
     /** Add the following to wire the client to the backend **/
    services.AddHttpClient<WeatherClient>(client =>
    {
         client.BaseAddress = Configuration.GetServiceUri("backend");
    });
    /** End added code **/
}
...

This will connect the WeatherClient to use the correct URL for the backend service.

Step 6 : Add a Forecasts property to the Index page model under Pages\Index.cshtml.cs in the frontend project.

...
public WeatherForecast[] Forecasts { get; set; }
...

Change the OnGet method to take the WeatherClient to call the backend service and store the result in the Forecasts property:

...
public async Task OnGet([FromServices]WeatherClient client)
{
     Forecasts = await client.GetWeatherAsync();
}
...

Step 7 : Change the Index.cshtml razor view to render the Forecasts property in the razor page:

@page
@model IndexModel
@{
     ViewData["Title"] = "Home page";
 }

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

Weather Forecast:

 <table class="table">
     <thead>
         <tr>
             <th>Date</th>
             <th>Temp. (C)</th>
             <th>Temp. (F)</th>
             <th>Summary</th>
         </tr>
     </thead>
     <tbody>
         @foreach (var forecast in @Model.Forecasts)
         {
             <tr>
                 <td>@forecast.Date.ToShortDateString()</td>
                 <td>@forecast.TemperatureC</td>
                 <td>@forecast.TemperatureF</td>
                 <td>@forecast.Summary</td>
             </tr>
         }
     </tbody>
 </table>

Step 8 : Run the project with tye run and the frontend service should be able to successfully call the backend service!

When you visit the frontend service you should see a table of weather data. This data was produced randomly in the backend service. Since you are seeing the data in a web UI in the frontend means that the services are able to communicate.

If you are getting any issues with the self signed scertifications, you need to run the below commands,

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Let's deploy to Kubernetes​

Step 1 : Provision the Kubernetes Cluster, since we will be using Azure Kubernetes Service , you can provision it by either CLI or using Azure Portal

Step 2 : Let's authenticate and get the required credentials

az aks get-credentials --resource-group dotnetconfsl-rg  --name dotnetconf

Step 3: You need to have either Docker registry or Azure container registry created where docker images of the frontend and backend will be pushed.

Step 4 : Now everything is ready do easy deploy the solution. Navigate to the solution folder and execute following:

tye deploy --interactive

You will be prompted to enter the Container Registry (ex: 'example.azurecr.io' for Azure or 'example' for dockerhub) where the Kubernetes service is installed.

The deployment process has built the docker container and pushed repositories to my registry:

Test the application​

If you are using VScode with the Kubernetes extension installed, once you authenticate to Azure using Azure extension, you will be able to navigate to the cluster and click on Workloads -> Pods -> Right Click Get

You can also explore the running pods from the Azure portal or using Cloudshell as well. You'll have two services in addition to the built-in kubernetes service.

You can visit the frontend application by port forwarding to the frontend service.

kubectl port-forward svc/frontend 5000:80

Now navigate to http://localhost:5000 to view the frontend application working on Kubernetes. You should see the list of weather forecasts just like when you were running locally.

Some important Notes:

⚠️ Currently tye does not provide a way to expose pods/services created to the public internet.

⚠️ Currently tye does not automatically enable TLS within the cluster, and so communication takes place over HTTP instead of HTTPS.

Conclusion:​

In this post I explained how easy it is to get started with Project Tye and How to run a simple web application. You can certainly do the same adding an external dependency like SQL server or Redis cache without creating docker files manually. In short, Tye simplifies the multiple gestures for all the services within an application to a single command. Even though Project Tye is an experimental tool , you can watch out for more features around service discovery, diagnostics , observability, configuration and logging when it comes to building cloud native applications with Microservices. Certainly it's a great addition to the tooling what .Net ecosystem provides and hope you will consider exploring it more. Cheers!

There’s always a lot of new services and products being offered through Azure, and some of them go into preview before being GA (General Availability).

There are two types of previews in Azure:

• Private Preview. An Azure feature marked “private preview” is available to specific Azure customers for evaluation purposes.
• Public Preview. An Azure feature marked “public preview” is available to all Azure customers for evaluation purposes.

One of the ways to check for preview features is that , if you browse to the Azure Updates portal, you can see all new features order per date and not only you can filter for the ones that are in preview, but you can also do a Keyword search.

However, today i noticed a new feature in the azure portal where you can opt into previews right there. You just need to navigate to the subscriptions blade , choose your subscription and click on preview features for your subscription as shown in the image below,

It's a great way to explore the new features, always keep yourself updated with what’s coming for Azure, but more importantly, provide as much feedback as you can. Cheers!

Hope this helps!

Hope this helps!