// Agentic AI

With the plan approved, ToolSmith starts building, and the first thing it needs is a connection to PurpleSuite. The sixth video in the Build EmployeeWorks plugins with ToolSmith series enters the API key and instance ID in a secure configuration form (never in chat), follows a failed test through to an updated plan, then checks what ToolSmith created against that plan.

ToolSmith proposes a plan before it builds anything, so the plan is where you catch mistakes. The fifth video in the Build EmployeeWorks plugins with ToolSmith series describes the booking cancellation task to ToolSmith, then reviews the plan it proposes, including how the plugin authenticates to PurpleSuite and whose bookings it finds.

You don't want to test a booking cancellation plugin against someone's real trip. The fourth video in the Build EmployeeWorks plugins with ToolSmith series introduces PurpleSuite, an enterprise app simulator, and shows how to create an instance, find the bookings and API operations in Purple Expense, and collect the credentials ToolSmith will need.

Before ToolSmith builds a plugin for you, it helps to know how plugins are put together so you can review its plan. The third video in the Build EmployeeWorks plugins with ToolSmith series walks through a plugin's assets in Tool Studio (connector, HTTP actions, conversational process and the plugin itself), then follows an employee's request through all of them.

EmployeeWorks assistants can use Enterprise Search, MCP servers and plugins as tools. The second video in the Build EmployeeWorks plugins with ToolSmith series explains how tools and the agentic loop let a language model act, then when to reach for each option: Enterprise Search for company knowledge, MCP servers for an open standard set of tools, and plugins for tasks that have to run the same way every time.

An AI assistant is only as useful as the tools you give it. The first video in the Build EmployeeWorks plugins with ToolSmith series covers the groundwork: the problem employees face moving between systems to get something done, and how EmployeeWorks gives them one place to search company knowledge and take action across the systems they already use.

One model reviewing its own plan tends to agree with itself. So I built a cleanup workflow shaped like a jury: separate critics from a deliberate mix of model families weigh the evidence, with a simple forcing function that keeps neighbouring reviewers off the same family. The orchestrator presides as judge, refuting rather than merging, votes promote shared findings, and a post-approval diff check can overrule a verdict that was unanimous and still wrong.

Building with one agent is familiar. Orchestrating a fleet of them in parallel across local, background, and cloud surfaces is where it gets real. This session covers the decisions that matter, how to decompose work across agents, when to fork vs. delegate, and how to verify quality when agents outnumber you — with patterns for multi-agent workflows you can apply to your own codebase.

Conversation state and retrieved context lead naturally into memory, but only if we're clear about what memory is for. Rules, skills, and instruction files package what you already know. Memory should capture what the work itself teaches the system, and that means reflection, verification, and forgetting matter just as much as recall.

Start with minimal AGENTS.md and SKILL.md examples, then adapt the portable core alongside Copilot-specific concepts like custom instructions, agents and prompt files. This post explains what belongs where and how to check that the files improve a real agent task.