DEV Community: Bruce Wong

🚀 How Foundry IQ helps enterprises build reusable knowledge bases for AI agents

Bruce Wong — Sun, 21 Jun 2026 12:20:31 +0000

Enterprise knowledge is often scattered across document stores, business systems, SharePoint, OneLake, and the public web. The real challenge isn’t simply putting documents into a vector database—it’s helping agents select the right sources, plan retrieval, and return traceable answers.

✅ Connect internal and external knowledge sources
✅ Automate content extraction, chunking, and vectorization
✅ Combine static documents with live web information
✅ Use an LLM to plan queries and select sources
✅ Run parallel retrieval, semantic reranking, and result aggregation
✅ Share one knowledge base across multiple agents
✅ Return grounded results with citations

Enterprise Context Engineering Through Microsoft IQ: A Four-Layer Analysis

Bruce Wong — Sun, 14 Jun 2026 13:34:15 +0000

Recently, while developing Agents with Microsoft Foundry, I noticed a confusing area: Microsoft has a series of "IQ" concepts — Work IQ, Fabric IQ, Foundry IQ, and Web IQ. They all seem to "provide context for Agents," but the context they supplement is actually different.

This points to a core problem in enterprise Agent engineering: context engineering. If prompt engineering is about "how to ask the model," then context engineering is about "what context to give the model." Microsoft IQ can be seen as Microsoft's enterprise-level implementation in this direction: packaging the scattered context inside and outside the organization into four consumable intelligence layers for Agents.

Here's the summary: Microsoft IQ consists of four capabilities:

Work IQ: Understanding how employees work.
Fabric IQ: Understanding business data and business entities.
Foundry IQ: Understanding enterprise knowledge, policies, and authoritative documents.
Web IQ: Understanding fresh information from the external world.

What Problem Does Each Layer Solve?

Enterprise Agent context typically comes from four sources, and each Microsoft IQ layer corresponds to one:

Context Source	Corresponding IQ	Core Question	Typical Representation
Human activities and relationships	Work IQ	Who, when, with whom, did what	Microsoft Graph, collaboration signals
Business facts and metrics	Fabric IQ	What is the current state of the business	Semantic model, ontology, Graph
Enterprise knowledge and rules	Foundry IQ	What do authoritative sources in the organization say	Knowledge base, agentic retrieval
External real-time information	Web IQ	What is happening in the external world	Web search, fresh content

Work IQ: Understanding "How People Work"

Work IQ is the workplace intelligence layer on the Microsoft 365 side. It understands work context, relationships, and patterns, enabling Agents to answer questions faster and more accurately than simple connectors.

From a context engineering perspective, Work IQ's core is activity signals centered on "people / relationships / time." It answers not "what is written in the document," but "who, when, with whom, did what."

For example: What recent email exchanges have there been with a customer? Which documents should I review before tomorrow's meeting? What has the team discussed around a particular project in Teams?

Work IQ leverages Microsoft 365 tenant data, including SharePoint, OneDrive, Outlook, Teams, and collaboration signals in Microsoft Graph, while respecting Microsoft 365 permissions and organizational boundaries. It is particularly suitable for employee productivity Agents: meeting preparation, email summarization, project context梳理, etc.

Fabric IQ: Understanding "What Is the Current State of the Business"

Fabric IQ is the IQ workload within Microsoft Fabric. Official documentation states: "Fabric IQ provides context on the state of your business." It is not simply about letting Agents query tables, but about elevating data to the business language layer, enabling both humans and Agents to understand data around business concepts, goals, and rules.

From a context engineering perspective, Fabric IQ solves the problem of "how business data is correctly understood by Agents." Enterprise data originally resides in tables, fields, and schemas, but business cares about: Who is the Customer, what is the relationship between Shipment and Order, how is a certain KPI calculated, and what actions should be triggered when anomalies occur.

Fabric IQ organizes these business concepts, relationships, rules, and actions through OneLake, Power BI semantic models, ontology, Graph, data agent, and operations agent. It is suitable for analytical and operational Agents: business analysis, supply chain anomaly detection, metric interpretation, and real-time operational response.

Foundry IQ: Understanding "Where Enterprise Knowledge Lives"

Foundry IQ leans more toward the managed knowledge layer for Agents. Agents need context from scattered enterprise content, but models have knowledge cutoffs and cannot access enterprise private data on their own. Foundry IQ can create configurable, multi-source knowledge bases, enabling Agents to provide permission-aware responses based on organizational data.

From a context engineering perspective, this is close to RAG, but not a hand-written simple vector library. Foundry IQ's knowledge base can connect to sources such as Azure Blob Storage, SharePoint, OneLake, and public web data, and use agentic retrieval (query rewriting, multi-round retrieval, source ranking, citation generation, etc.) to return grounded answers with citations.

It solves the problem of "how Agents reliably access enterprise knowledge:" Where are company policies? How is product documentation explained? What related content is in historical solutions? Can the answer provide citations?

It is suitable for knowledge Q&A, policy assistants, product documentation assistants, and pre-sales solution assistants.

Easy to Confuse: Both Foundry IQ and Fabric IQ Mention OneLake — What's the Difference?

Fabric IQ handles data in OneLake that has already been modeled as business semantics (tables, metrics, Graph, semantic models). It enables Agents to understand "business facts."
Foundry IQ handles unstructured content in OneLake such as documents, templates, and solutions that serve as enterprise knowledge sources. It enables Agents to understand "enterprise language / rules."

One is the "business data layer," the other is the "enterprise knowledge layer."

Web IQ: Understanding "What Is Happening in the External World"

Web IQ is the fourth capability. Official Microsoft IQ documentation states that "Web IQ provides AI systems and agents with fresh, real-world intelligence from across the web."

From a context engineering perspective, it solves the problem of "externally changing information:" What is the latest industry news? What have competitors released? What is the impact of new policies, regulations, or vulnerabilities?

If the first three are more about finding context within the organization, Web IQ supplements changes from outside the organization.

Easy to Confuse: Foundry IQ Can Also Connect to Public Web Data — Isn't That Redundant with Web IQ?

No, it's not redundant.

Web data in Foundry IQ is externally curated by the enterprise, such as competitor whitepapers, regulatory pages, and industry reports that have been crawled into the knowledge base. It has already been incorporated into the enterprise knowledge boundary.
Web IQ is real-time, open, general web intelligence that does not require pre-indexing, supplementing "what is happening in the external world right now."

One is "external materials managed by the enterprise," the other is "the real-time external world."

The Differences Among the Four

IQ	Focus	Typical Question	Typical Data	Agent Function
Work IQ	How employees work	Where did I leave off with the client yesterday?	Emails, meetings, Teams, files, personnel relationships	Understand work context
Fabric IQ	Current state of business	What is this customer's renewal risk?	OneLake, semantic models, Ontology, Graph, real-time/analytical data	Understand business concepts and metrics
Foundry IQ	Where enterprise knowledge lives	What does our service agreement say about this type of issue?	Documents, knowledge bases, SharePoint, Blob, OneLake, enterprise-curated web materials	Obtain citable authoritative knowledge
Web IQ	What is happening in the external world	Has the customer been affected by recent industry negative news?	Web information, news, public pages, real-time external materials	Obtain fresh external context

A Context Engineering Example

Suppose we are building a customer meeting preparation Agent:

Help me prepare for tomorrow's meeting with Contoso.

This is not a simple prompt, but an orchestration of multi-layer context:

Use Work IQ to pull recent emails, meetings, and Teams discussions related to Contoso, establishing "people" and "timeline" context.
Use Fabric IQ to query Contoso's business status, such as ARR, orders, risks, renewals, and service ticket trends.
Use Foundry IQ to query product documentation, customer solutions, contract policies, and delivery templates.
If needed, use Web IQ to supplement recent public news, industry trends, or competitive information about Contoso.
Finally, the Agent compiles a briefing, risk points, and suggested questions.

The key is not "which IQ is stronger," but that they supplement different contexts. For example, if you only connect Foundry IQ to query documents without knowing that the customer recently expressed strong dissatisfaction in Teams, the Agent's response is likely to be "correct but contextually detached."

Summary

The real difficulty with Agents is not just whether the model can reason, but whether it has the right context. Microsoft breaks this context into different layers:

Work IQ enables Agents to understand work like a colleague.
Fabric IQ enables Agents to understand data like a business expert.
Foundry IQ enables Agents to find authoritative materials like a knowledge manager.
Web IQ enables Agents to monitor external changes like a researcher.

From a context engineering perspective, the core value of Microsoft IQ lies in: packaging the scattered, heterogeneous, and permission-complex context within the enterprise into standardized capabilities that Agents can directly consume. You don't need to write Graph connectors, build semantic layers, maintain vector libraries, or integrate web searches yourself — you simply choose the appropriate IQ layer for the scenario.

If an enterprise Agent only connects to the model, it easily becomes an assistant that "speaks well but doesn't understand the organization." When it can simultaneously understand work, business, knowledge, and external changes, it comes closer to a truly deployable enterprise Agent.

Microsoft Build 2026: Agent Harness Is About Making Agents Production-Ready

Bruce Wong — Thu, 11 Jun 2026 08:28:19 +0000

Microsoft Build 2026 had many AI announcements, but the one I found most meaningful was not another model or another Copilot UI.

It was Agent Harness in Microsoft Agent Framework.

My reading is simple: Microsoft is trying to move agent development from "the agent can run" to "the agent can survive production."

That difference matters.

Most agent demos look impressive because the happy path is short. A user asks, the model reasons, a tool is called, and the result comes back. But real agent workloads are messier:

the task runs for many steps
context becomes too large
the agent needs memory
some tools require approval
developers need traces
multiple agents may need to collaborate
generated code may need to execute safely

These are not side features. They are the execution layer of an agent system.

Agent Harness is interesting because it makes that execution layer part of the framework default.

What Changed

At a high level, creating a harness agent looks like this:

agent = create_harness_agent(
    client=client,
    name="MyAgent",
    max_context_window_tokens=128_000,
)

The API change is small. The assumption change is not.

The old assumption was: create an agent and let it call tools.

The new assumption is: this agent may run for a long time, use many tools, need human approval, overflow context, delegate work, and require observability.

Agent Harness includes built-in providers for things like:

automatic context compaction
file-based memory
todo tracking
plan vs. execute modes
dynamic skill discovery
background agents
tool approval rules
OpenTelemetry tracing
web search and shell execution

This is why I do not see Agent Harness as just a feature list. I see it as a standardization move.

Every serious agent platform eventually needs these capabilities. The question is whether each team builds them manually, or whether the framework provides strong defaults.

CodeAct: The Real Problem Is Not Tool Speed

The first feature worth paying attention to is CodeAct with Hyperlight.

Traditional tool calling usually works like this:

LLM -> choose tool
Tool -> return result
LLM -> choose next tool
Tool -> return result
LLM -> choose next tool
...

This is fine for simple tasks. But it becomes expensive when the work is procedural.

Imagine an agent needs to calculate total order value across users:

list users
get orders for each user
get discount for each order
get tax rate by region
calculate the final total

In traditional tool calling, the model may need many turns just to walk through a loop.

CodeAct changes this by letting the model generate code once:

users = call_tool("list_users")
total = 0

for user in users:
    orders = call_tool("get_orders", user_id=user.id)
    for order in orders:
        discount = call_tool("get_discount", order_id=order.id)
        tax = call_tool("get_tax_rate", region=order.region)
        total += (order.amount - discount) * (1 + tax)

print(total)

The important improvement is not that the tools execute faster.

The improvement is that the system reduces model-to-tool round trips.

Microsoft's example showed more than 50% latency reduction and more than 60% token reduction for a multi-step workflow. The exact number will vary, but the pattern is very useful: when the task is procedural, let the model express the procedure as code and let the runtime execute it.

This is closer to how developers work. If I need to repeat an operation across many records, I do not want to manually reason through every iteration. I write a small script.

CodeAct gives agents that same execution pattern.

Hyperlight Does Not Remove Tool Governance

CodeAct uses Hyperlight to run generated code in an isolated micro-VM. That is important because model-generated code should not run directly in the host environment.

But I think the security boundary needs to be stated clearly:

CodeAct sandboxing protects the host from unsafe generated code. It does not automatically make your tools safe.

If your tool can send an email, delete a file, update a database, approve a refund, or trigger a deployment, the sandbox is not enough. You still need tool-level permissions, approval policies, and auditability.

In other words:

Sandbox protects code execution.
Approval protects business actions.

Confusing these two would be dangerous in production.

Handoff: Multi-Agent Workflow Should Not Always Be a Pipeline

The second feature I found important is Handoff.

Many multi-agent examples are built as a fixed pipeline:

Planner -> Implementer -> Reviewer

That works for some development workflows. But many real service workflows are not linear.

Think about customer support:

Coordinator
  -> Refund Agent
  -> Shipping Agent
  -> Technical Support Agent
  -> back to Coordinator if needed

The right next step depends on the conversation.

This is where Handoff is useful. Developers define the participants and topology, while agents can decide when to transfer control.

A simplified structure looks like this:

workflow = (
    HandoffBuilder(name="customer_support")
    .participants([coordinator, refund, shipping, tech])
    .set_coordinator(coordinator)
    .with_interaction_mode("autonomous")
    .with_termination_condition(should_terminate)
    .build()
)

The point is not simply "multiple agents."

The point is runtime routing.

A coordinator can route to a specialist. A specialist can finish the task, ask for more information, or hand control back. The workflow can end early when the condition is met.

That is very different from forcing every request through the same fixed sequence.

My Takeaway

For me, the most important message from Agent Harness is this:

Production agents need an execution layer, not just a reasoning model.

That execution layer includes context management, memory, approvals, tracing, code execution, and multi-agent routing.

CodeAct improves single-agent efficiency by reducing unnecessary model turns.

Handoff improves multi-agent collaboration by allowing dynamic runtime routing.

Agent Harness brings these ideas into the Microsoft Agent Framework as default infrastructure.

This is why I think Agent Harness matters. It is not the most visually exciting Build 2026 announcement, but it may be one of the most practical ones for developers building real agent systems.

The next phase of agent development will not be defined only by smarter models. It will also be defined by better execution infrastructure.

GitHub Copilot CLI: Your AI Coding Partner in the Terminal

Bruce Wong — Thu, 11 Jun 2026 08:22:45 +0000

1. What is Copilot CLI?

In February 2026, GitHub officially released Copilot CLI to General Availability (GA). It is not a command-line port of the VS Code plugin, but a standalone, terminal-native AI coding agent.

GitHub's positioning is clear:

"Copilot CLI has grown from a terminal assistant into a full agentic development environment—one that plans, builds, reviews, and remembers across sessions, all without leaving the terminal."

All Copilot subscribers can use it (Free/Pro/Business/Enterprise) at no extra cost.

2. How is it different from VS Code Copilot?

This is the most confusing part. Many people think CLI is just "Copilot from VS Code moved to the terminal." It is not.

2.1 Positioning differences

Dimension	VS Code Copilot	Copilot CLI
Runtime	Inside the IDE	Terminal / command line
Interaction	Inline editor completions, side Chat	Full-screen terminal chat
Core strength	Real-time coding assistance	Complex task planning & execution
Context switching	Within the IDE	No need to leave the terminal

2.2 Feature comparison

Feature	VS Code Copilot	Copilot CLI
Code completion	✅ Real-time inline	❌ Not the main focus
Agent mode	✅ Yes	✅ Yes, and more powerful
Multi-step complex tasks	✅ Supported	✅ Better suited
Git operations	⚠️ Limited	✅ Native integration
GitHub.com operations (PR/Issue)	⚠️ Requires browser switch	✅ Direct operations
Plan Mode (plan first, then execute)	✅ Yes	✅ Shift+Tab, more complete
Cross-session memory	✅ Yes	✅ Stronger Repository Memory
CI/CD integration	❌ Difficult	✅ -p programmatic calls
Shell command execution	⚠️ Indirect	✅ Native support

2.3 One-sentence summary

VS Code Copilot is "your co-pilot while coding" — real-time completions, quick explanations, single-file refactoring.

Copilot CLI is "a full-stack engineer that works independently" — you can say "refactor this entire module," go do something else, and it reports back when done.

3. When to use CLI vs VS Code?

Scenarios for VS Code Copilot

Daily coding with real-time completions
Quick refactoring within a single file
Explaining selected code functionality
Reviewing and confirming changes directly in the editor

Scenarios for Copilot CLI

Complex multi-step tasks: creating complete features, cross-file changes
DevOps / automation: generating CI/CD configs, Terraform scripts
GitHub operations: bulk PR management, code reviews, issue creation
Background tasks: long-running code analysis, security scans
Pure terminal environments: SSH remote servers, Docker containers, WSL
Scripted integration: embedding AI capabilities into automation workflows

4. Copilot CLI's three killer features

4.1 Cloud Delegation (&)

The most unique feature. Prefix your prompt with & to push the task to the GitHub Cloud Agent:

Runs remotely on GitHub Actions runners
Automatically creates a copilot/ branch and Draft PR
Continues even if you shut down your local machine
Perfect for long-running tasks (code analysis, large-scale refactoring)

In contrast, Autopilot Mode (--autopilot) runs locally, is visible in real time, but stops if your local machine shuts down.

4.2 Programmatic Mode (-p)

Ideal for integration into scripts and automation workflows.

# Single-shot call, great for script integration
copilot -p "Show me this week's commits and summarize them" --allow-tool='shell(git)'

# Pipe input
./script-outputting-options.sh | copilot

Value: Can be integrated into CI/CD, cron jobs, and shell scripts.

4.3 Plan Mode — plan first, then execute

Press Shift+Tab to enter Plan Mode. Copilot will:

Analyze your request
Ask clarifying questions
Build a structured implementation plan
Wait for your confirmation before coding

Value: Avoids the "AI blindly changes code" problem by communicating requirements first.

5. Installation and quick start

5.1 Installation

这是提取出来的 Markdown 表格内容：

Platform	Command
macOS	brew install copilot-cli
Linux	brew install copilot-cli or curl -fsSL https://gh.io/copilot-install \| bash
Windows	winget install GitHub.Copilot
npm	npm install -g @github/copilot

需要我帮你保存成 .md 文件吗？如果要的话，文件名和路径有偏好吗？
Article content

5.2 Authentication

copilot
/login 
## 5.3 Quick start

# 1. Enter your project directory
cd my-project

# 2. Start interactive mode
copilot

# 3. Initialize custom instructions (helps Copilot understand your stack)
/init
# Generates .github/copilot-instructions.md with project context

# 4. Start building
"Create a React component for user authentication"

# 5. Run in the background (non-blocking terminal)
& "Analyze all security vulnerabilities in this codebase"

Reference resources

Official docs:https://docs.github.com/copilot/how-tos/copilot-cli/cli-getting-started

Best practices:https://docs.github.com/copilot/how-tos/copilot-cli/cli-best-practices

Command reference:https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference

Slash command cheat sheet:https://github.blog/ai-and-ml/github-copilot/a-cheat-sheet-to-slash-commands-in-github-copilot-cli/

Product page:https://github.com/features/copilot/cli