Prepare Agents and Workflows for Teams

Production agents should use reviewed configuration and workflows to solve specific jobs with deliberate Data, tools, prompts, access, and monitoring. Avoid publishing generic assistants that can see too much and do not have an owner.

Build the First Pilot Agent From Scratch

Use a concrete, read-oriented job for the first agent. The example below is Tender Review — Pilot: it reviews one approved tender pack, extracts requirements and deadlines, flags gaps, and drafts clarification questions. It does not submit a bid, contact a supplier, or change an external system.

Create this first agent from scratch instead of starting from a template so the owner reviews every setting:

1. Open Agents, select Create Agent, and enter a name, description, and named business owner that identify the exact job.
2. In Configuration, select the approved AI Connection and Model Name. Set Reasoning effort to Medium when the selected model supports it. Leave temperature, maximum length, presence penalty, frequency penalty, and Agent harness settings at their defaults for the first evaluation.
3. Add a system message with the role, source boundary, expected output, escalation behavior, and actions the agent must not take. Start with the example below and adapt the bracketed values.
4. Attach the verified private collection from Build the First Pilot Data Pack.
5. Leave Platform Tools off unless the use case has a tested need. For this example, enable Grounding with Google Search only when current public verification is required, and Web scraper only for approved public URLs. Leave unrelated Platform Tools and live write-capable connections unattached.
6. Assign only skills that describe repeatable tender-review tasks, such as Extract mandatory requirements, Compare the response with requirements, or Draft clarification questions. Keep the stable role and boundaries in the system message; put reusable procedures and their tools in skills.
7. Keep the agent Private and run representative conversations: a known-answer question, a missing-answer question, a conflicting-document case, an out-of-scope request, and an instruction that tries to make the agent perform a prohibited action.
8. Check that answers are traceable to the pilot pack, uncertainty is explicit, and any enabled tool appears with the expected arguments and result in Tool Executions.
9. Fix the prompt, data, or skill before tuning model parameters. When the private tests pass, apply the safe pilot sharing sequence and grant one team Can Use while owners retain edit access.

You are the Tender Review Pilot for [company or team].

Review only the approved tender pack attached to this agent. Extract mandatory requirements, deadlines, evaluation criteria, risks, and open questions. For every material finding, identify the source document and location when available.

If evidence is missing, stale, or contradictory, say so and ask for human review. Do not invent requirements, submit a bid, contact suppliers, change external systems, or expose material outside the pilot audience. Use approved public web tools only when the user explicitly asks for current external verification, and label that evidence separately from the tender pack.

Production Agent Checklist

Before sharing an agent with a team, review:

• Name and description: users can identify the job it performs.
• Owner: one person or team owns changes and incidents.
• Model connection: the model/provider is approved for the workload.
• Prompt: role, boundaries, output style, escalation, and refusal behavior are explicit.
• Data: data collections, Memory, files, and connected sources are intentional.
• Shared tools: service-account tools are approved for the agent audience.
• Private tools: user-owned tools are required only when user context matters.
• Platform Tools: built-in advanced capabilities are enabled only when the job needs them.
• Access: private for build, team-shared for pilot, organization-wide only after approval.
• Monitoring: conversations, feedback, Tool Executions, analytics, and history have an owner.

Agent Configuration Problems

Symptom	Likely cause	Admin action
Agent says it has no data	Data collection, Memory, or connection is not attached or not shared	Attach the source and test retrieval
Agent cannot call a tool	Connection is missing, private connection belongs to another user, or function is disabled	Review assigned tools and connection governance
Agent asks for approval too often	Write functions are correctly in confirmation mode, or too many operations are modeled as writes	Keep confirmations for risky actions; refine tool design for safe reads
Agent gives inconsistent answers	Prompt is too broad, data source is stale, or model setting is unsuitable	Tighten the prompt, refresh data, and test with known cases
Users can edit production behavior	Team has edit/write access instead of use access	Restrict edit access to owners

Workflow Preparation

Use workflows for repeated processes with predictable steps. A workflow should have known inputs, clear node dependencies, safe error behavior, and a rollback path for write actions.

Before publishing:

1. Name the workflow by business process.
2. Define required inputs and expected output.
3. Use read nodes before write nodes whenever possible.
4. Keep write nodes behind confirmation when impact is high.
5. Test on non-production records.
6. Review Tool Executions for each connection action.
7. Review workflow History after every major edit.
8. Share with one pilot team before expanding access.

Workflow Examples

Workflow	Recommended controls
Support request -> Jira issue -> Slack notification	Jira create and Slack post require confirmation during pilot
HubSpot deal lookup -> meeting prep -> calendar draft	CRM reads can be direct; calendar updates need user context or confirmation
Webhook incident intake -> classify -> task creation	Webhook has a named API key, sample payload, and failure replay plan
Data refresh -> summary -> report file	Use safe test folders and inspect generated files before team rollout

If A Workflow Changed The Wrong Record

1. Pause or narrow workflow sharing.
2. Open Tool Executions and find the write action.
3. Capture function name, arguments, result, approval status, user, and timestamp.
4. Check the preceding node output that supplied the record ID.
5. Confirm whether the connection had too-broad permissions.
6. Add confirmation, stricter parameters, or a validation step.
7. Retest on safe records.
8. Re-enable access only after the owner signs off.

Templates

Use templates only after the agent has a proven configuration. A template can copy useful prompts, tools, Data assumptions, and Platform Tools into new agents, so a bad template spreads problems quickly.

Before publishing a template:

• remove test credentials and draft prompts,
• confirm access defaults,
• check Platform Tools,
• document intended audience,
• create one agent from the template and test it end to end.

When the pilot is live, monitor usage, audit evidence, and risk before expanding access.