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.

Organization onboarding defaults

Before creating the first agents, review the four separate organization and workspace defaults. Default LLM connection supplies a model connection to eligible creation flows; Default agent and Default agent for quick actions select agents for different entry points. A workspace provisions its own default agent. Changing the connection default does not switch existing agents.

When a new organization is created and the required system template exists, it also receives a Quick Actions Agent configured as the quick-actions default. Desktop App is enabled; the organization receives Use access and the Admins team Write access. If the system template is missing, provisioning skips that agent. This does not automatically add it to older organizations. For an existing organization, select an agent belonging to that organization with Desktop App enabled. See Quick Actions onboarding.

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.

Let an agent start an approved workflow

Save and activate a tested workflow, then enable Configuration → System Tools → Workflows on the pilot agent and select that workflow. Save the agent with Submit. Keep the pilot workflow on Schedule → On Demand when it should have no recurring schedule.

Ask for one explicit run, check the tool acknowledgement, then inspect Build → Workflows → Runs and the node outputs. The acknowledgement only confirms submission: it neither proves completion nor returns the result to chat. Review the trigger's outputs and node mappings before relying on launch input. See agent-triggered workflows for access, input, and recursion restrictions. Task created remains a separate event-driven path.

Migrate task intake to a workflow

The former task-workspace default-agent and auto-execution options no longer control task processing. The workspace chat default agent serves a separate purpose. Recreate the required behavior with Task created → Agent → Update task and bind the trigger to the intended workspace. Choose the agent on the Agent node and explicitly map the task prompt and ID. The former workspace options do not create this workflow automatically.

Test by creating one new task, because manual Run is not available for Task created workflows. Check the workflow execution, the selected agent, and the final task status. Use Review for output requiring human checking. Grant the workflow owner task view access for the trigger and task edit/write access for creating or updating tasks. See Task workflows.

Use the builder's access selector to share the tested workflow. Own-team sharing and organization-wide sharing have different permission boundaries; the same audience should be reviewed separately on the task workspace.

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.

For an existing agent, save configuration changes with Submit before Save as new template. Treat linked System Messages as shared behavior: edits through Library or Override existing template affect linked agents, while other agent settings stay separate. Review template editing and access before updating a team template.

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.