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.

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.