Plugins, MCP servers or Enterprise Search? | Build EmployeeWorks plugins with ToolSmith (Part 2)
This is the second video in the Build EmployeeWorks plugins with ToolSmith series on the ServiceNow Dev Program channel. The video covers the following topics:
- What a language model can do on its own: summarise a travel policy or compare options, but not look up or cancel a live booking
- How tools work: the model asks for a tool by name, the agent harness runs it and hands back the result, and that agentic loop is what makes an agent
- Enterprise Search for company knowledge, such as the travel cancellation policy
- MCP servers as an open standard for offering tools to agents, including asking for a team’s open Linear issues and inspecting the Linear server’s tools in Tool Studio
- Why you should review the tools an MCP server exposes before giving an agent access, since the model can call any of them, including ones that update or delete data
- Plugins for tasks that have to run the same way every time, like the travel plugin that finds bookings, lets the employee pick one and confirms before anything changes
- Checking business rules in plugin code (such as only allowing cancellations more than 48 hours before a trip) rather than relying on the model’s instructions
The full written series is on the ServiceNow Community.
Related Content
Build EmployeeWorks plugins with ToolSmith
Employees shouldn't need to know which system handles their request, jump between portals, or learn how every application works to get something done. This series introduces EmployeeWorks and shows how to plan, build, review, and test well-governed plugins with ToolSmith.
What is EmployeeWorks? | Build EmployeeWorks plugins with ToolSmith (Part 1)
ServiceNowAn 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.
The Jury Pattern: a mixture of critics for AI code review
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.