[MS] AI agents, meet the Azure Cosmos DB vNext emulator - devamazonaws.blogspot.com

If you use the Azure Cosmos DB vNext emulator, you probably know the local development loop: start the emulator, connect to it, create some resources, load test data, run queries, and inspect the results. Each step is straightforward, but together they add setup work before you can test the application you are actually building.

How agents work with the emulator

How a developer’s intent flows through the coding agent, Agent Skill, Cosmos DB Shell, and local emulator.   The emulator includes the Azure Cosmos DB Shell, an open-source CLI for working with databases, containers, and items. It runs inside the emulator container and handles the local endpoint and well-known key, giving developers a direct, scriptable way to work with the emulator. CLIs are well suited to agent workflows because they expose operations as explicit commands and return results the agent can inspect. An agent can discover commands through built-in help, run them non-interactively, respond to errors, and use the output to choose its next action. These characteristics make the CLI a practical interface for agents. Azure Cosmos DB Shell brings that model to the local emulator. For example, an agent can run Cosmos DB Shell non-interactively inside the emulator container: 
docker exec <emulator-container> cosmoshell.sh -c '<command>'
It gives AI coding agents, such as GitHub Copilot CLI, Codex, and Claude Code, a straightforward way to work with the emulator. The developer describes the required outcome instead of translating the task into a sequence of shell commands. Command access is only the starting point. The agent still needs an operating procedure for finding the emulator, choosing appropriate commands, respecting safety boundaries, and verifying its work. An Agent Skill fills that gap by packaging task-specific guidance for reuse across requests and sessions. For the local emulator, the cosmosdb-emulator-vnext skill helps the agent inspect resources, create databases and containers, load test data, and run queries through Azure Cosmos DB Shell. [cta-button text="Check out the emulator agent skill on GitHub" url="https://ift.tt/Js63iWI" color="btn-primary" align="center"]

From prompt to test data

Consider a developer building a multi-tenant order-processing application. The integration tests need data across multiple tenants and different stages of the order lifecycle. Creating and maintaining that data by hand can quickly become tedious. Instead, the developer could give a coding agent this prompt: 
I’m building a multi-tenant order-processing app and need realistic data
for integration testing. Set up my local Cosmos DB emulator with synthetic
orders covering two tenants and a mix of new, shipped, and cancelled orders.
Show me the data when it’s ready.
I tested this prompt with GitHub Copilot CLI while the local emulator was already running. The agent located the emulator, used the bundled Azure Cosmos DB Shell, and created OrdersDB with an Orders container partitioned by /tenantId. It then generated a balanced set of synthetic orders for both tenants. Each order included customer details, nested line items, timestamps, shipping information, and totals. It also added status-specific fields, such as tracking information for shipped orders and cancellation reasons for cancelled ones. The setup summary showed what the agent created: 
Database: OrdersDB
Container: Orders
Partition key: /tenantId
Orders created: 12
To verify the data, the agent queried the container. Six of the 12 orders are shown below:
Order Tenant Customer Status Total
ord-a001 tenant-alpha Alice Navarro new $145.96
ord-a003 tenant-alpha Clara Mendes shipped $361.99
ord-a005 tenant-alpha Elena Vasquez cancelled $129.00
ord-b001 tenant-beta Grace Osei new $74.97
ord-b003 tenant-beta Ingrid Sorensen shipped $249.00
ord-b006 tenant-beta Luca Ferrari cancelled $101.97
Because the request is open-ended, names, values, and document counts may vary. The workflow remains the same: create the resources, load the data, and query it back. Showing the saved orders confirms that the data is in the emulator and ready for the application to use. At this point, the developer has persisted, partitioned data for integration testing without writing a seed script or manually assembling documents. Notice that the prompt describes the application need, not the operating procedure. It says nothing about finding the emulator, using the bundled shell, choosing non-interactive commands, or verifying changes.

Why use an Agent Skill

You could include all those operating instructions in every prompt. That works for a one-off task, but repeating the same guidance soon becomes tedious. Results can also vary when an important constraint is omitted or phrased differently. Moving the guidance into global instructions avoids that repetition, but makes emulator-specific context available during unrelated tasks. An Agent Skill avoids both tradeoffs. The cosmosdb-emulator-vnext skill keeps the emulator guidance in one place and makes it available when a relevant request is detected. As a markdown file, the skill can be shared, reviewed, tested, versioned, and adapted to a team’s conventions or testing workflow. The same approach extends to other parts of Azure Cosmos DB development. The Azure Cosmos DB team maintains the Azure Cosmos DB Agent Kit, a collection of skills for AI coding agents working with Azure Cosmos DB. It includes guidance on data modeling, partition-key design, query optimization, SDK usage, indexing, throughput, security, and monitoring. [alert type="note" heading=""]The emulator skill may also be combined into the Agent Kit and maintained there alongside other Azure Cosmos DB agent skills.[/alert]

Try it yourself

Agent Skills are a lightweight, open standard that lets you reuse the same skill across coding agents. Install the skill and put it to work with your local emulator: 
npx skills add abhirockzz/cosmosdb-vnext-emulator-skill
Then run the order-processing prompt above to create your first test dataset. From there, adapt the request to the data and workflows your application needs. Together, the local emulator, Azure Cosmos DB Shell, and the skill make this kind of setup repeatable without hiding how the work gets done. Developers can describe the data they need while the agent runs explicit commands, verifies the result, and leaves an execution trail they can inspect.

About Azure Cosmos DB

Azure Cosmos DB is a fully managed and serverless NoSQL and vector database for modern app development, including AI applications. With its SLA-backed speed and availability as well as instant dynamic scalability, it is ideal for real-time NoSQL and MongoDB applications that require high performance and distributed computing over massive volumes of NoSQL and vector data. To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn.  Join the discussion with other developers on the #nosql channel on the Microsoft Open Source Discord.
Post Updated on July 20, 2026 at 03:05PM
Thanks for reading
from devamazonaws.blogspot.com

Comments

Post a Comment

Popular posts from this blog

[MS] Pulling a single item from a C++ parameter pack by its index, remarks - devamazonaws.blogspot.com

In my earlier discussion of pulling a single item from a C++ parameter pack by its index , I noted that with the Pack Indexing proposal, you would be able to write this to pull an item from a parameter pack while preserving its reference category. template<int index, typename...Args> void example(Args&&... args) { auto&& arg = (Args...[index]&&)args...[index]; using Arg = Args...[index]&&; } Why did I need to apply the (Args...[index]&&) cast ? Why can't I just write this: auto&& arg = args...[index]; or possibly decltype(auto) arg = args...[index]; Well, when you write the name of a variable, the result is an lvalue reference, even if the variable is an rvalue reference . Watch: struct S { S(S&); // construct from lvalue S(S&&); // construct from rvalue }; void whathappens(S&& s) { S t = s; // which will it use? } Try it out in your favorite compiler. This code construc...
Read more

[MS] Boosting Azure DevOps Security with GHAS Code Scanning - devamazonaws.blogspot.com

Image
Debjyoti Ganguly shares insights on the security benefits and configuration of GHAS Code Scanning with Azure DevOps. Boosting Azure DevOps Security with GHAS Code Scanning Code scanning, a pipeline-based tool available in GitHub Advanced Security, is designed to detect code vulnerabilities and bugs within the source code of ADO (Azure DevOps) repositories. Utilizing CodeQL as a static analysis tool, it performs query analysis and variant analysis. When vulnerabilities are found, it generates security alerts. CodeQL CodeQL is a powerful static analysis tool used for showing vulnerabilities and bugs in source code. It enables developers to write custom queries that analyze codebases, searching for specific patterns and potential security issues. By converting code into a database format, CodeQL allows for sophisticated, database-like queries to detect flaws. CodeQL in Action 1. Preparing the Code Create a CodeQL Database : Extract and structure the code into a database for analy...
Read more

[MS] How can I check that all the changes in a git branch have been cherry-picked or rebased into its upstream branch? - devamazonaws.blogspot.com

If you try to delete a branch that contains changes that haven't been merged to its upstream, git warns you, the branch is not fully merged. If you are sure you want to delete it, run 'git branch -D xxx' . Suppose you want to check that all of the changes in the branch have been cherry-picked or rebased into the upstream branch. How can you confirm this? How can you do the "If you are sure" step? One way to do this is to merge the branch into its upstream and see if the result produces any changes. # Detach the HEAD from the upstream so we can do some tinkering. $ git checkout --detach featurebranch{@u} # Propose a merge of the feature branch. $ git merge featurebranch $ ⟦ resolve any merge conflicts and commit ⟧ # See if anything would have changed. $ git diff HEAD HEAD~1 # Return to original branch, abandon detached HEAD. $ git checkout - If the git diff produces no output, then everything in your featurebranch is already present in the upstream, so you ...
Read more