Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
148906 stories
·
33 followers

Microsoft is bringing clearer messaging to OneDrive errors

1 Share
Microsoft is looking to make life a little easier for users of OneDrive by improving error messages. The company has apparently finally realized that error messages should be useful, and is making changes accordingly. An error message which has long been the source of frustration is the one that pops up when the path to a file on OneDrive exceeds 520 characters. Previously devoid of information that is of much help, this is the message that Microsoft is seeking to improve. Just as Windows has a limit on the length of a path to a file, so does OneDrive. While… [Continue Reading]
Read the whole story
alvinashcraft
40 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

W3C Invites Implementations of Decentralized Identifiers (DIDs) v1.1

1 Share

The Decentralized Identifier Working Group has published Decentralized Identifiers (DIDs) v1.1 as a W3C Candidate Recommendation Snapshot. This document specifies the DID syntax, a common data model, core properties, serialized representations, DID operations, and an explanation of the process of resolving DIDs to the resources that they represent.

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. They may refer to any subject and have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities, so as to enable the controller of a DID to prove control over it without requiring permission from any other party.

Comments are welcome via Github issues by 5 April 2026.

Read the whole story
alvinashcraft
40 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

First Public Working Draft: YAML-LD 1.0

1 Share

The JSON-LD Working Group published today a First Public Working Draft of YAML-LD 1.0. [JSON-LD11] is a JSON-based format to serialize Linked Data. In recent years, [YAML] has emerged as a more concise format to represent information that had previously been serialized as [JSON], including API specifications, data schemas, and Linked Data.

This document defines YAML-LD as a set of conventions on top of YAML which specify how to serialize Linked Data [LINKED-DATA] as [YAML] based on JSON-LD syntax, semantics, and APIs.

Since YAML is more expressive than JSON, both in the available data types and in the document structure (see [RFC9512]), this document identifies constraints on YAML such that any YAML-LD document can be represented in JSON-LD.

Read the whole story
alvinashcraft
41 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Get started with GitHub Copilot CLI: A free, hands-on course

1 Share

GitHub Copilot has grown well beyond code completions in your editor. It now lives in your terminal, too. GitHub Copilot CLI lets you review code, generate tests, debug issues, and ask questions about your projects without ever leaving the command line.

To help developers get up to speed, we put together a free, open source course: GitHub Copilot CLI for Beginners. It’s 8 chapters, hands-on from the start, and designed so you can go from installation to building real workflows in a few hours. Already have a GitHub account? GitHub Copilot CLI works with GitHub Copilot Free, which is available to all personal GitHub accounts.

In this post, I’ll walk through what the course covers and how to get started.

What GitHub Copilot CLI can do

If you haven’t tried it yet, GitHub Copilot CLI is a conversational AI assistant that runs in your terminal. You point it at files using @ references, and it reads your code and responds with analysis, suggestions, or generated code.

You can use it to:

  • Review a file and get feedback on code quality
  • Generate tests based on existing code
  • Debug issues by pointing it at a file and asking what’s wrong
  • Explain unfamiliar code or confusing logic
  • Generate commit messages, refactor functions, and more
  • Write new app features (front-end, APIs, database interactions, and more)

It remembers context within a conversation, so follow-up questions build on what came before.

What the course covers

The course is structured as 8 progressive chapters. Each one builds on the last, and you work with the same project throughout: a book collection management app. Instead of jumping between isolated snippets, you keep improving one codebase as you go.

Here’s what using GitHub Copilot CLI looks like in practice. Say you want to review a Python file for potential issues. Start up Copilot CLI and ask what you’d like done:

$ copilot
> Review @samples/book-app-project/books.py for potential improvements. Focus on error handling and code quality.

Copilot reads the file, analyzes the code, and gives you specific feedback right in your terminal.

code review demo gif

Here are the chapters covered in the course:

Quick Start — Installation and authentication
First Steps — Learn the three interaction modes: interactive, plan, and one-shot (programmatic)
Context and Conversations — Using @ references to point Copilot at files and directories, plus session management with --continue and --resume
Development Workflows — Code review, refactoring, debugging, test generation, and Git integration
Custom Agents — Building specialized AI assistants with .agent.md files (for example, a Python reviewer that always checks for type hints)
Skills — Creating task-specific instructions that auto-trigger based on your prompt
MCP Servers — Connecting Copilot to external services like GitHub repos, file systems, and documentation APIs via the Model Context Protocol
Putting It All Together — Combining agents, skills, and MCP servers into complete development workflows
learning path image

learning path image

Every command in the course can be copied and run directly. No AI or machine learning background is required.

Who this is for

The course is built for:

  • Developers using terminal workflows: If you’re already running builds, checking git status, and SSHing into servers from the command line, Copilot CLI fits right into that flow.
  • Teams looking to standardise AI-assisted practices: Custom agents and skills can be shared across a team through a project’s .github/agents and .github/skills directories.
  • Students and early-career developers: The course explains AI terminology as it comes up, and every chapter includes assignments with clear success criteria.

You don’t need prior experience with AI tools. If you can run commands in a terminal, you learn and apply the concepts in this course.

How the course teaches

Each chapter follows a consistent pattern: a real-world analogy to ground the concept, then the core technical material, then hands-on exercises. For instance, the three interaction modes are compared to ordering food at a restaurant. Plan mode is more like mapping your route to the restaurant before you start driving. Interactive mode is a back-and-forth conversation with a waiter. And one-shot mode (programmatic mode) is like going through the drive-through.

ordering food analogy image

Later chapters use different comparisons: agents are like hiring specialists, skills work like attachments for a power drill, and MCP servers are compared to browser extensions. The goal is to provide you with a visual and mental model before the technical details land.

The course also focuses on a question that’s harder than it looks: when should I use which tool? Knowing the difference between reaching for an agent, a skill, or an MCP server takes practice, and the final chapter walks through that decision-making in a realistic workflow.

integration pattern image

Get started

The course is free and open source. You can clone the repo, or open it in GitHub Codespaces for a fully configured environment. Jump right in, get Copilot CLI running, and see if it fits your workflow.

GitHub Copilot CLI for Beginners

For a quick reference, see the CLI command reference.

Subscribe to GitHub Insider for more developer tips and guides.

Read the whole story
alvinashcraft
41 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Building High-Performance Agentic Systems

1 Share

Most enterprise chatbots fail in the same quiet way.

They answer questions.

They impress in demos.

And then they stall in production.

Knowledge goes stale. Answers cannot be audited. The system cannot act beyond generating text. When workflows require coordination, execution, or accountability, the chatbot stops being useful.

Agentic systems exist because that model is insufficient.

Instead of treating the LLM as the product, agentic architecture embeds it inside a bounded control loop:

plan → act (tools) → observe → refine

The model becomes one component in a runtime system with explicit state management, safety policies, identity enforcement, and operational telemetry.

This shift is not speculative. A late-2025 MIT Sloan Management Review / BCG study reports that 35% of organizations have already adopted AI agents, with another 44% planning deployment. Microsoft is advancing open protocols for what it calls the “agentic web,” including Agent-to-Agent (A2A) interoperability and Model Context Protocol (MCP), with integration paths emerging across Copilot Studio and Azure AI Foundry.

The real question is no longer whether agents are coming.

It is whether enterprise architecture is ready for them.

This article translates “agentic” into engineering reality: the runtime layers, latency and cost levers, orchestration patterns, and governance controls required for production deployment.

The Core Capabilities of Agentic AI

What makes an AI “agentic” is not a single feature—it’s the interaction of different capabilities. Together, they form the minimum set needed to move from “answering” to “operating”.

 

 

Autonomy – Goal-Driven Task Completion

Traditional bots are reactive: they wait for a prompt and produce output. Autonomy introduces a goal state and a control loop. The agent is given an objective (or a trigger) and it can decide the next step without being micromanaged. The critical engineering distinction is that autonomy must be bounded: in production, you implement it with explicit budgets and stop conditions—maximum tool calls, maximum retries, timeouts, and confidence thresholds.

The typical execution shape is a loop: plan → act → observe → refine. A project-management agent, for example, doesn’t just answer “what’s the status?” It monitors signals (work items, commits, build health), detects a risk pattern (slippage, dependency blockage), and then either surfaces an alert or prepares a remediation action (re-plan milestones, notify owners). In high-stakes environments, autonomy is usually human-in-the-loop by design: the agent can draft changes, propose next actions, and only execute after approval. Over time, teams expand the autonomy envelope for low-risk actions while keeping approvals for irreversible or financially sensitive operations.

Tool Integration – Taking Action and Staying Current

A standalone LLM cannot fetch live enterprise state and cannot change it. Tool integration is how an agent becomes operational: it can query systems of record, call APIs, trigger workflows, and produce outputs that reflect the current world rather than the model’s pretraining snapshot.

There are two classes of tools that matter in enterprise agents:

  • Retrieval tools (grounding / RAG)When the agent needs facts, it retrieves them. This is the backbone of reducing hallucination: instead of guessing, the agent pulls authoritative content (SharePoint, Confluence, policy repositories, CRM records, Fabric datasets) and uses it as evidence. In practice, retrieval works best when it is engineered as a pipeline: query rewrite (optional) → hybrid search (keyword + vector) → filtering (metadata/ACL) → reranking → compact context injection. The point is not “stuff the prompt with documents,” but “inject only the minimum evidence required to answer accurately.”
  • Action tools (function calling / connectors) These are the hands of the agent: update a CRM record, create a ticket, send an email, schedule a meeting, generate a report, run a pipeline. Tool integration shifts value from “advice” to “execution,” but also introduces risk—so action tools need guardrails: least-privilege permissions, input validation, idempotency keys, and post-condition checks (confirm the update actually happened).
  • In Microsoft ecosystems, this tool plane often maps to Graph actions + business connectors (via Logic Apps/Power Automate) + custom APIs, with Copilot Studio (low code) or Foundry-style runtimes (pro code) orchestrating the calls.

 

 

Memory (Context & Learning) – Context Awareness and Adaptation

“Memory” is not just a long prompt. In agentic systems, memory is an explicit state strategy:

  • Working memory: what the agent has learned during the current run (intermediate tool results, constraints, partial plans).
  • Session memory: what should persist across turns (user preferences, ongoing tasks, summarized history).
  • Long-term memory: enterprise knowledge the agent can retrieve (indexed documents, structured facts, embeddings + metadata).

Short-term memory enables multi-step workflows without repeating questions. An HR onboarding agent can carry a new hire’s details from intake through provisioning without re-asking, because the workflow state is persisted and referenced. Long-term “learning” is typically implemented through feedback loops rather than real-time model weight updates: capturing corrections, storing validated outcomes, and periodically improving prompts, routing logic, retrieval configuration, or (where appropriate) fine-tuning.

The key design rule is that memory must be policy-aware: retention rules, PII handling, and permission trimming apply to stored state as much as they apply to retrieved documents.

 

 

Orchestration – Coordinating Multi-Agent Teams

Complex enterprise work is rarely single-skill. Orchestration is how agentic systems scale capability without turning one agent into an unmaintainable monolith. The pattern is “manager + specialists”: an orchestrator decomposes the goal into subtasks, routes each to the best tool or sub-agent, and then composes a final response.

This can be done sequentially or in parallel. Employee onboarding is a classic: HR intake, IT account creation, equipment provisioning, and training scheduling can run in parallel where dependencies allow. The engineering challenge is making orchestration reliable: defining strict input/output contracts between agents (often structured JSON), handling failures (timeouts, partial completion), and ensuring only one component has authority to send the final user-facing message to avoid conflicting outputs.

In Microsoft terms, orchestration can be implemented as agentic flows in Copilot Studio, connected-agent patterns in Foundry, or explicit orchestrators in code using structured tool schemas and shared state.

 

 

Strategic Impact – How Agentic AI Changes Knowledge Work

Agentic AI is no longer an experimental overlay to enterprise systems. It is becoming an embedded operational layer inside core workflows. Unlike earlier chatbot deployments that answered isolated questions, modern enterprise agents execute end-to-end processes, interact with structured systems, maintain context, and operate within governed boundaries. The shift is not about conversational intelligence alone; it is about workflow execution at scale.

The transformation becomes clearer when examining real implementations across industries.

In legal services, agentic systems have moved beyond document summarization into operational case automation. Assembly Software’s NeosAI, built on Azure AI infrastructure, integrates directly into legal case management systems and automates document analysis, structured data extraction, and first-draft generation of legal correspondence. What makes this deployment impactful is not merely the generative drafting capability, but the integration architecture. NeosAI is not an isolated chatbot; it operates within the same document management systems, billing systems, and communication platforms lawyers already use. Firms report time savings of up to 25 hours per case, with document drafting cycles reduced from days to minutes for first-pass outputs. Importantly, the system runs within secure Azure environments with zero data retention policies, addressing one of the most sensitive concerns in legal AI adoption: client confidentiality.

JPMorgan’s COiN platform represents another dimension of legal and financial automation. Instead of conversational assistance, COiN performs structured contract intelligence at production scale. It analyzes more than 12,000 commercial loan agreements annually, extracting over 150 clause attributes per document. Work that previously required approximately 360,000 human hours now executes in seconds. The architecture emphasizes structured NLP pipelines, taxonomy-based clause classification, and private cloud deployment for regulatory compliance. Rather than replacing legal professionals, the system flags unusual clauses for human review, maintaining oversight while dramatically accelerating analysis. Over time, COiN has also served as a knowledge retention mechanism, preserving institutional contract intelligence that would otherwise be lost with employee turnover.

In financial services, the impact is similarly structural. Morgan Stanley’s internal AI Assistant allows wealth advisors to query over 100,000 proprietary research documents using natural language. Adoption has reached nearly universal usage across advisor teams, not because it replaces expertise, but because it compresses research time and surfaces insights instantly. Building on this foundation, the firm introduced an AI meeting debrief agent that transcribes client conversations using speech-to-text models and generates CRM notes and follow-up drafts through GPT-based reasoning. Advisors review outputs before finalization, preserving human judgment. The result is faster client engagement and measurable productivity improvements.

What differentiates Morgan Stanley’s approach is not only deployment scale, but disciplined evaluation before release. The firm established rigorous benchmarking frameworks to test model outputs against expert standards for accuracy, compliance, and clarity. Only after meeting defined thresholds were systems expanded firmwide. This pattern—evaluation before scale—is becoming a defining trait of successful enterprise agent deployment.

Human Resources provides a different perspective on agentic AI. Johnson Controls deployed an AI HR assistant inside Slack to manage policy questions, payroll inquiries, and onboarding support across a global workforce exceeding 100,000 employees. By embedding the agent in a channel employees already use, adoption barriers were reduced significantly. The result was a 30–40% reduction in live HR call volume, allowing HR teams to redirect focus toward strategic workforce initiatives. Similarly, Ciena integrated an AI assistant directly into Microsoft Teams, unifying HR and IT support through a single conversational interface. Employees no longer navigate separate portals; the agent orchestrates requests across backend systems such as Workday and ServiceNow. The technical lesson here is clear: integration breadth drives usability, and usability drives adoption.

Engineering and IT operations reveal perhaps the most technically sophisticated application of agentic AI: multi-agent orchestration. In a proof-of-concept developed through collaboration between Microsoft and ServiceNow, an AI-driven incident response system coordinates multiple agents during high-priority outages. Microsoft 365 Copilot transcribes live war-room discussions and extracts action items, while ServiceNow’s Now Assist executes operational updates within IT service management systems. A Semantic Kernel–based manager agent maintains shared context and synchronizes activity across platforms. This eliminates the longstanding gap between real-time discussion and structured documentation, automatically generating incident reports while freeing engineers to focus on remediation rather than clerical tasks. The system demonstrates that orchestration is not conceptual—it is operational.

Across these examples, the pattern is consistent. Agentic AI changes knowledge work by absorbing structured cognitive labor: document parsing, compliance classification, research synthesis, workflow routing, transcription, and task coordination. Humans remain essential for judgment, ethics, and accountability, but the operational layer increasingly runs through AI-mediated execution. The result is not incremental productivity improvement; it is structural acceleration of knowledge processes.

Design and Governance Challenges – Managing the Risks

As agentic AI shifts from answering questions to executing workflows, governance must mature accordingly. These systems retrieve enterprise data, invoke APIs, update records, and coordinate across platforms. That makes them operational actors inside your architecture—not just assistants.

The primary shift is this: autonomy increases responsibility.

Agents must be observable. Every retrieval, reasoning step, and tool invocation should be traceable. Without structured telemetry and audit trails, enterprises lose visibility into why an agent acted the way it did.

Agents must also operate within scoped authority. Least-privilege access, role-based identity, and bounded credentials are essential. An HR agent should not access finance systems. A finance agent should not modify compliance data without policy constraints. Autonomy only works when it is deliberately constrained.

Execution boundaries are equally critical. High-risk actions—financial approvals, legal submissions, production changes—should include embedded thresholds or human approval gates. Autonomy should be progressive, not absolute.

Cost and performance must be governed just like cloud infrastructure. Agentic systems can trigger recursive calls and model loops. Without usage monitoring, rate limits, and model-tier routing, compute consumption can escalate unpredictably.

Finally, agentic systems require continuous evaluation. Real-world testing, live monitoring, and drift detection ensure the system remains aligned with business rules and compliance requirements. These are not “set and forget” deployments.

In short, agentic AI becomes sustainable only when autonomy is paired with observability, scoped authority, embedded guardrails, cost control, and structured oversight.

 

Conclusion – Towards the Agentic Enterprise

The organizations achieving meaningful returns from agentic AI share a common pattern. They do not treat AI agents as experimental tools. They design them as production systems with defined roles, scoped authority, measurable KPIs, embedded observability, and formal governance layers.

When autonomy is paired with integration, memory, orchestration, and governance discipline, agentic AI becomes more than automation—it becomes an operational architecture.

Enterprises that master this architecture are not merely reducing costs; they are redefining how knowledge work is executed. In this emerging model, human professionals focus on strategic judgment and innovation, while AI agents manage structured cognitive execution at scale. The competitive advantage will not belong to those who deploy the most AI, but to those who deploy it with architectural rigor and governance maturity.

Before we rush to deploy more agents, a few questions are worth asking:

  • If an AI agent executes a workflow in your enterprise today, can you trace every reasoning step and tool invocation behind that decision?
  • Does your architecture treat AI as a conversational layer - or as an operational actor with scoped identity, cost controls, and policy enforcement?
  • Where should autonomy stop in your organization - and who defines that boundary?

Agentic AI is not just a capability shift. It is an architectural decision.

Curious to hear how others are designing their control planes and orchestration layers.

References

Read the whole story
alvinashcraft
41 minutes ago
reply
Pennsylvania, USA
Share this story
Delete

Building a lean team before raising big with David Park, Narada

1 Share

This week on Build Mode, we’re joined by David Park, co-founder and CEO of Narada, an enterprise AI agent platform spun out of UC Berkeley AI Lab research. Narada uses large action models to automate complex, multi-step workflows across enterprise systems. After previously co-founding and exiting Coverity, Park is now building his second company with a different playbook: Stay lean, talk to customers, and don’t raise before you’re ready. 

In this episode, he shares why Narada spent a year making nearly 1,000 customer calls before raising institutional capital, how the company reached 99.99% reliability in production environments, and why he believes too much funding too early can derail even the strongest teams. Park also reflects on his experience as a Startup Battlefield Top 20 company and the lessons he’s carried from his first exit into building Narada. 

He breaks down: 

  • Why customers won’t tell you your “baby is ugly” — but their wallets will 

  • How Narada achieves enterprise-grade AI reliability 

  • Why raising money before product-market fit can be dangerous 

  •  The discipline of building a lean, “mean building machine” 

  • When to scale your go-to-market team (and when not to) 

  • Why founders must stick to their values, even under pressure 

  • Lessons from Startup Battlefield and building in public 

Apply to Startup Battlefield: We are looking for early-stage companies that have an MVP. So nominate a founder (or yourself): techcrunch.com/apply. Be sure to say you heard about Startup Battlefield from the Build Mode podcast.  

Founders Summit: If you want to take these conversations beyond the podcast, then come join us in person at a TechCrunch event on June 9 in Boston, we're hosting our founders Summit, which is essentially build mode in real life. It's a full day focused entirely on founders, builders and the conversations that actually move startups forward. It's also a great way to sharpen your story. Get your tickets. 

TechCrunch Disrupt: If you're thinking about applying to Startup Battlefield, then October 13 to 15 in San Francisco, we're back for TechCrunch Disrupt, where the Startup Battlefield 200 takes the stage. So if you want to cheer them on, or just network with 1000s of founders, VCs, and tech enthusiasts, then grab your tickets. 
 

Use code buildmode15 for 15% off any ticket type

00:00 – Why customers won’t tell you the truth (but their wallets will) 
02:43 – What Narada does: enterprise AI agents powered by large action models 
04:28 – Enterprise reliability: reaching 99.99% accuracy 
07:32 – Trust, security, and on-prem deployment 
12:26 – Bootstrapping, 1,000 customer calls & finding real pain 
15:05 – Raising after traction & meeting their lead VC at Disrupt 
18:47 – Scaling responsibly after product-market fit 
22:46 – Go-to-market strategy & leveraging channels 
23:48 – From Coverity exit to Narada: a founder’s second act 
27:05 – Founder advice: passion, grit & integrity 
30:20 – Fake it till you make it? Not quite. 
30:44 – Startup Battlefield experience 
36:05 – Final reflections on disruption & building for impact 

New episodes of Build Mode drop every Thursday. Hosted by Isabelle Johannessen. Produced and edited by Maggie Nye. Audience development led by Morgan Little. Special thanks to the Foundry and Cheddar video teams. 





Download audio: https://traffic.megaphone.fm/TCML3999225064.mp3?updated=1772562410
Read the whole story
alvinashcraft
42 minutes ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories