5 Open-Source AI Agent Patterns to Ship on Azure

Agent demos often stop at “prompt → model → response.” Production systems need more: current evidence, controlled permissions, cost-aware routing, reliable scheduling, and a clear audit trail.

These five open-source projects show practical ways to add those capabilities using Azure AI Foundry, Azure Container Apps, and Azure Key Vault.

The popularity figures below come from the November 12, 2026 research snapshot. They are momentum signals, not quality or security guarantees.

1. Pinky: add human-approved phone actions to an Azure agent

What it is: Pinky is an open-source phone-control layer for AI agents. It lets an agent propose actions on a phone while requiring a person to approve sensitive operations such as entering information, tapping controls, or making a purchase.

Why now: The project was created on November 6 and had accumulated 1,866 GitHub stars within days. That interest reflects a real deployment problem: giving an agent access to a personal device is different from giving it access to an API.

Tutorial angle:

1. Run Pinky on a trusted device or network.
2. Put an authenticated MCP bridge in front of it rather than exposing the raw device endpoint.
3. Expose narrow tools such as draft_message, open_screen, and request_purchase instead of unrestricted phone access.
4. Register the bridge with an Azure AI Foundry agent.
5. Require an approval containing a nonce tied to the exact proposed action. This prevents a valid approval from being reused for different input.
6. Test rejection, expiration, replay, and network-failure paths.

Keep the bridge private where possible. If remote access is necessary, use VPN access or an authenticated reverse proxy with TLS, rate limits, and an audit log.

Difficulty: Intermediate

• Start today: Clone the project and inspect its interface without connecting a real phone: git clone https://github.com/DIYgod/pinky.git && cd pinky && ls

2. Kagi Search: ground an Azure agent with fresh web evidence

What it is: The Kagi Search API provides agents with current search results and source links. Wrapping it in an MCP server gives a Foundry agent a controlled way to retrieve evidence instead of relying only on model memory.

Why now: Kagi’s “Search for everyone” update reached 756 points and 413 comments on Hacker News. The discussion highlights growing demand for search infrastructure that agents can use without exposing API credentials or returning an unmanageable stream of content.

Tutorial angle:

Build an MCP server with one deliberately small tool:

search(query, allowed_domains?, result_limit?)

The server should call Kagi, return structured fields such as title, url, snippet, and published_date, and enforce timeouts, result limits, and domain restrictions.

A minimal API check looks like this:

curl -sS -G 'https://api.kagi.com/search' \
  --data-urlencode 'q=Model Context Protocol' \
  -H "Authorization: Bot $KAGI_API_KEY"

Store the API key in Key Vault and inject it into the MCP server at runtime. Do not place it in the agent prompt, source code, or a client-side tool definition.

Then compare a model-only response with a grounded response using the same evaluation prompts. Check:

• Whether every important factual claim maps to a returned URL
• Whether the answer says when evidence is missing
• Whether search results can trigger additional tool calls
• Whether malicious instructions embedded in a page are treated as data, not commands

Return sanitized text rather than arbitrary HTML or executable page content.

Difficulty: Intermediate

• Start today: Open the Kagi Search API documentation and run its smallest authenticated example against one test query.

3. Strands Decider: route agent work to the right model

What it is: Strands Decider is an agent decision layer that selects an execution path or model based on the task. Its goal is to reserve expensive frontier-model calls for work that actually needs them.

Why now: Amazon’s case study about replacing Sonnet with Strands Decider reached 719 points and 257 comments on Hacker News. The discussion is useful because it turns model-routing economics into a measurable engineering problem rather than an abstract optimization.

Tutorial angle: Wrap Decider in a small service, containerize it, and deploy it to Azure Container Apps. Keep provider credentials in Key Vault or use managed identity where the provider supports it.

Benchmark two paths against the same task set:

1. Baseline: Every task goes directly to the expensive model.
2. Routed: Decider chooses the model or execution path.

Measure:

• Task-success rate
• Cost per successful task
• Total input and output tokens
• p50 and p95 latency
• Incorrect or unsafe routing
• Fallback frequency when the selected model fails

Do not compare raw request cost alone. A cheaper model that fails twice as often may make a workflow more expensive overall. Also prevent cost-based routing from bypassing approval requirements for sensitive operations.

Difficulty: Intermediate

• Start today: Open the Strands Decider case study and identify the evaluation dataset and success criteria used in its benchmark.

4. Home Assistant MCP: give an agent controlled access to a smart home

What it is: Home Assistant MCP is an MCP server that exposes Home Assistant state and controls to compatible agents. It can support useful natural-language automation, but it also creates a direct path toward physical devices.

Why now: The project had 645 stars on GitHub Trending in the November 12 snapshot. Smart-home integrations are popular because they are easy to understand, but they make permission design unusually visible: a mistaken agent action can affect a real home.

Tutorial angle:

Start with a small entity allowlist, such as a few sensors, one light, and one thermostat. Give read and write operations separate credentials or scopes.

A safe permission model looks like this:

• Reading allowed sensors: permitted
• Changing a light or thermostat: permitted with an explicit tool
• Unlocking a door: disabled by default
• Opening a garage, changing security state, or running a script: requires fresh confirmation

For every write operation, return the intended change before executing it. Require confirmation for doors, locks, alarms, and other sensitive entities.

Keep the MCP server on the local network or behind a private relay. Do not publish the Home Assistant endpoint directly to the internet. Test ambiguous instructions such as “turn off everything” and verify that entity filtering prevents unintended devices from being included.

Difficulty: Intermediate

• Start today: Download the server and inspect its configuration without enabling write access: git clone https://github.com/homeassistant-ai/ha-mcp.git && cd ha-mcp && ls

5. daily_stock_analysis: run scheduled analysis with Azure Container Apps Jobs

What it is: daily_stock_analysis is an open-source system that combines market data, news, analysis, dashboards, and scheduled notifications. It is a good candidate for turning a local script into a repeatable background workload.

Why now: In the November 12 snapshot, the repository showed 278 stars for the day and 70,237 total stars. Its combination of data collection, LLM analysis, and notifications exercises most of the operational requirements of a real scheduled application.

Tutorial angle:

1. Containerize the existing application.
2. Publish the image to Azure Container Registry.
3. Store provider and data-service credentials in Key Vault.
4. Run the workload as a scheduled Azure Container Apps Job.
5. Send logs and metrics to Log Analytics or Application Insights.
6. Configure retries only for transient failures.

Scheduling needs more than a cron expression. Define the market calendar, exchange timezone, and whether the job runs before or after the market closes.

Make each run idempotent with a key such as:

analysis:{trade_date}:{analysis_version}

That prevents retries from sending duplicate notifications. Notifications should be sent only after the analysis artifact has been stored successfully. This project should remain an analysis and reporting system; it should not place trades automatically.

Difficulty: Intermediate

• Start today: Clone the repository and locate its existing scheduler and configuration files: git clone https://github.com/ZhuLinsen/daily_stock_analysis.git && cd daily_stock_analysis && ls

Building in public: my lead-gen engine

Alongside these projects, I’m improving an automated pipeline that discovers, enriches, and contacts Hong Kong SME leads. The latest run discovered 1,776 leads, enriched 201, and contacted 231. Because contacted leads can include earlier cohorts, the next iteration will add stage IDs before calculating conversion rates.

• Discovered leads: 1,776
• Enriched leads: 201
• Leads contacted: 231
• Next focus: Improve enrichment throughput and track conversion by cohort

Start with this today

Start with Home Assistant MCP because its permission boundaries are concrete and visible:

git clone https://github.com/homeassistant-ai/ha-mcp.git

Open the README, list three read-only entities you would expose, and keep every write-capable tool disabled for the first run. You will have a safe architecture sketch without changing a real device.

Picks of the week

• Best focused experiment: Kagi Search MCP
• Best approval-flow demo: Pinky
• Best cost experiment: Strands Decider
• Best local-device integration: Home Assistant MCP
• Best scheduled workload: daily_stock_analysis

Which of these five would you ship first—and what would you refuse to let an agent do without explicit approval?

---

Connect

If this kind of post is useful, the easiest way to support the work is to:

• Star / follow on dev.to (you're already here 🙂)
• Follow on X: @devkingov
• Reach out for HK-based dev work — .NET / Azure / system integration / IT security: studio.resurrects.co or email [e-mail]
• Subscribe to weekly HK tech posts → studio.resurrects.co/blog (one email a week, no spam)