Establishing patterns for trust and safeguards for agentic workflows

[enantz-lilly]

Within life sciences, many groups in statistics and data science are beginning to build multi-agent / agentic workflows and pipelines with AI. Recently, Will Landau published a novel Trusted Mini-Agents guide to outline a core set of pinciples and case studies for how we can build addtional guardrails and granular control when building capabilities harnassing AI. It would be excellent to hear how others are approaching their workflows involving multiple agents (leveraving skills versus tool calling, how MCP servers play a role, and other considerations)

[armorer-labs]

For life-sciences agentic workflows, I would separate the safeguards into a few records that survive beyond the chat transcript. The important boundary is where an agent's proposed work becomes a change to code, data, analysis artifacts, or study documentation.

A pattern that has worked well in adjacent agent-ops systems is:

• keep a run manifest: workflow id, dataset or repo snapshot, model/provider, prompt/config version, and intended operating mode;
• keep a capability inventory: skills available, MCP servers mounted, tool schemas, credential scope, and whether each tool is read-only, write-capable, networked, or export-capable;
• bind approvals to exact side effects: the normalized tool call, files or records touched, external destinations, and the human or policy decision that allowed it;
• emit a provenance receipt for outputs: inputs used, tool calls made, validation checks run, redactions applied, and the final artifact digest or pointer;
• make replay/validation a first-class step, especially for generated analysis code, package changes, report text, and data transformations.

For the skills-versus-tool-calling split, I would use skills for workflow conventions and domain procedures, but put side effects behind typed tool calls or MCP servers. Skills are good for teaching the agent how the group thinks about an analysis. Tools are where I would enforce authority, capture parameters, and produce audit evidence.

The MCP part is most useful if the server is not just a convenience wrapper. I would want each server to expose stable tool identity, schema version, and risk metadata, then let the local runtime or gateway decide whether a call needs dry-run, human approval, quarantine, or a validation gate. That keeps a clear line between the agent suggested this and the workflow allowed this side effect.

For an early, practical version in a statistics/data-science team, I would start with one non-production pipeline and require: dry-run before write, explicit approval before export or publish, immutable run receipt after each agent turn, and negative tests for the cases you most do not want, such as changing an input dataset, silently altering analysis code, or using a broader credential than the workflow expected.

Disclosure: I work on Armorer Labs, where we build local agent control-plane pieces around approvals, jobs, tool boundaries, and run receipts.