These KoolArchitect AI Agent Terms govern agent identity, delegated authority, tools, permissions, approval gates, transactions, oversight, logging, testing, incidents, suspension, and accountability.
These KoolArchitect AI Agent Terms govern the configuration, authorization, deployment, supervision, and use of AI agents and agentic workflows that can plan tasks, retrieve data, invoke tools, communicate, update systems, or perform actions through KoolArchitect.
Agent functionality is available only where enabled by an Order Form, Subscription Plan, API Schedule, integration authorization, or other written agreement. These terms supplement the KoolArchitect Subscription Agreement, API Terms, and Acceptable Use Policy.
Agent means an AI-enabled software capability that may select or sequence actions. Agent Action means a tool call or external effect. Agent Owner means the Customer-designated accountable person. Approval Gate means a required authorized review before execution.
Customer remains responsible for every agent it configures, enables, instructs, or permits to act under Customer accounts, including agent objectives, data access, tool permissions, recipients, transactions, outputs, approvals, and downstream consequences.
Each production agent should have a named business owner with authority and knowledge appropriate to the workflow. The Agent Owner is responsible for purpose, scope, permissions, review, escalation, suspension, and periodic reassessment.
An agent must have a documented, bounded purpose. Customer must not deploy an open-ended agent whose objectives, tools, data, recipients, transaction authority, or completion conditions cannot be reasonably described and controlled.
Where supported, an agent should use a distinct, lifecycle-managed identity rather than a shared human or administrator account. Agent activity must remain attributable to the relevant Customer, workspace, principal, session, and delegated authority.
Customer may delegate only authority Customer lawfully possesses. Delegation must identify who authorized the agent, permitted actions, affected systems, data boundaries, limits, duration, and required approvals.
Agent permissions must be limited to the minimum tools, scopes, records, fields, tenants, workspaces, environments, actions, and time necessary. An agent must not receive broader effective authority than the sponsoring user or approved service role.
Where practical, read, draft, preview, write, send, delete, export, execute, and administer capabilities should be separated so that higher-impact actions can receive stricter authorization, approval, logging, and limits.
Agents may invoke only enabled, documented, and authorized tools. Customer must review each tool owner, capability, data reach, arguments, reversibility, approval behavior, logging, and failure mode before production use.
Tool access must be bound to the intended agent, workflow, environment, purpose, and permission scope. Customer must not expose generic administrator tools or unrestricted command execution when narrower functions can accomplish the task.
Customer should constrain recipient domains, record types, allowed values, quantities, amounts, date ranges, file types, export sizes, environments, and other parameters. Prompts alone must not be treated as the sole enforcement mechanism.
Customer is responsible for lawful and accurate instructions, source data, context, attachments, and connected content. Agents may be influenced by incorrect, malicious, outdated, or ambiguous inputs, including prompt injection embedded in retrieved content.
Customers must assess whether untrusted documents, messages, websites, records, or tool outputs can influence an agent. Sensitive actions should require independent authorization, constrained tooling, validation, and appropriate human approval.
Agent-generated plans, reasoning summaries, classifications, and proposed actions may be incomplete or incorrect. Customer must not assume that an apparently coherent plan proves that each step is authorized, safe, accurate, or necessary.
Customer must define where an agent may act independently, where review is required, who can approve, how reviewers receive sufficient context, and when the agent must stop, escalate, revert to manual handling, or await instruction.
Approval should be required for irreversible, high-impact, external, financial, legal, security-sensitive, privacy-sensitive, employment-related, or permission-changing actions unless a signed schedule and documented control design expressly allow bounded automation.
An approval must present enough information for an authorized reviewer to understand the proposed action, target, material inputs, consequences, limits, and relevant exceptions. Rubber-stamping or approval without adequate context is not meaningful oversight.
Agents initiating purchases, payments, credits, refunds, invoices, inventory movements, provisioning, commitments, or contract-related actions require Customer-defined authorization, value limits, recipient validation, reconciliation, and segregation of duties.
Agents that draft or send external communications must use approved identities, recipients, templates, disclosure rules, consent, suppression, review, and escalation controls. Customer remains responsible for the communication and applicable law.
Agents that create, update, approve, reserve, cancel, delete, or reconcile records must preserve authorized business rules, record ownership, validation, traceability, and Customer controls applicable to the connected system.
Agents must not make final employment, credit, insurance, legal-rights, safety, health, or similarly consequential decisions without lawful authority, qualified human review, appropriate evidence, and Customer governance.
An agent must not access, correlate, export, or disclose data outside authorized Customer, tenant, workspace, project, record, field, regional, or purpose boundaries. Combined access across multiple tools must be evaluated as a whole.
Restricted data may be used only when the applicable service, contract, safeguards, and Customer authorization permit it. Agents must not expose secrets, credentials, Personal Data, confidential records, or regulated information through prompts, logs, tools, or messages.
Agent memory, history, summaries, embeddings, caches, files, and persisted context are subject to applicable configuration, retention terms, and data controls. Customer must not assume that deleting a conversation removes all connected copies or downstream records.
If an agent delegates to another agent, the downstream agent must remain within the original authorized purpose and effective permissions. Delegation must not expand authority, bypass review, obscure responsibility, or break traceability.
Customer must implement reasonable limits on steps, retries, duration, concurrency, cost, transactions, messages, tool calls, and recursive delegation. Agents must stop when limits, uncertainty thresholds, policy conflicts, or repeated failures occur.
Production workflows should provide practical means to pause, disable, revoke credentials, block tools, terminate execution, or return to manual operation. Customer must identify who may activate these controls.
Where actions are reversible, Customer should define rollback, correction, compensation, and reconciliation procedures. Where an action cannot be reversed, stronger approval and validation controls are required before execution.
Uncertainty, conflicting instructions, authorization failure, unexpected targets, missing evidence, policy conflicts, unusual values, new recipients, or tool errors should route to an authorized human rather than be silently bypassed.
Where supported, Customer should preserve agent identity, sponsoring principal, instructions, relevant context, tool calls, arguments, approvals, outputs, timestamps, errors, and final results sufficient to investigate material actions.
Customer is responsible for monitoring agent behavior appropriate to impact, including failure rates, denied actions, approval overrides, unusual access, transaction patterns, costs, data movement, and recurring exceptions.
Before production use, Customer should test expected workflows, authorization boundaries, invalid inputs, prompt injection, tool failures, duplicate events, retries, approval paths, stop conditions, rollback, and excessive-agency scenarios.
New or materially changed agents should begin with limited scope, representative data, restricted permissions, controlled users, and increased review where practical. Authority may expand only after Customer evaluates evidence and risk.
Changes to models, prompts, tools, scopes, recipients, workflows, data sources, thresholds, approvals, or connected systems may alter risk and should trigger appropriate review and retesting before release.
Agents may depend on independent AI, cloud, API, communications, identity, payment, ERP, or productivity providers. Provider terms, model behavior, limits, outages, and changes may affect agent performance and availability.
Customer must manage agent credentials, integrations, tokens, service accounts, secrets, dependencies, vulnerabilities, access reviews, and incidents. Compromised or misbehaving agents must be contained promptly.
Customer must promptly report material unauthorized actions, data exposure, credential compromise, runaway execution, significant financial or operational errors, or security events involving an agent and cooperate with containment and investigation.
Kool&Tech may restrict agents, tools, credentials, integrations, workflows, or accounts when reasonably necessary to address misuse, compromise, excessive consumption, legal requirements, platform risk, or material breach.
Agents and Outputs may be inaccurate, incomplete, inconsistent, delayed, or affected by context, models, tools, permissions, providers, and data. Kool&Tech does not guarantee that an agent will achieve a business result or prevent every error.
Agent use must comply with the Responsible AI Statement, AI Use & Disclosure Policy, Acceptable Use Policy, privacy terms, and applicable law. Customer must apply fairness, safety, transparency, accountability, and human oversight appropriate to use.
Kool&Tech retains KoolArchitect, agent frameworks, tools, prompts, orchestration, interfaces, Documentation, and related intellectual property. Customer rights in Customer Content and Outputs remain subject to the governing agreements and law.
Warranties, disclaimers, liability limits, indemnification, confidentiality, force majeure, law, and disputes are governed by the Master Services Agreement or other controlling contract.
For agent matters: signed amendment or Agent Schedule; Order Form; SLA Schedule; DPA; Master Services Agreement; Subscription Agreement; these Agent Terms; API Terms; Acceptable Use Policy; Documentation; incorporated AI and security policies.
Kool&Tech may update these terms as agents, tools, models, risks, laws, and platform controls evolve. Application to active subscriptions follows the governing agreement and applicable law.
Questions about agent eligibility, permission design, approval gates, tools, incidents, or an Agent Schedule may be sent to info@koolandtech.com. Do not include credentials, secrets, or unnecessary sensitive data.
Contact Kool&Tech to define agent purpose, owner, identity, tools, permissions, data boundaries, approval gates, transaction limits, logging, testing, incident handling, and suspension controls.
Back to headingThese KoolArchitect AI Agent Terms govern agent identity, delegated authority, tools, permissions, approval gates, transactions, oversight, logging, testing, incidents, suspension, and accountability.
These KoolArchitect AI Agent Terms govern the configuration, authorization, deployment, supervision, and use of AI agents and agentic workflows that can plan tasks, retrieve data, invoke tools, communicate, update systems, or perform actions through KoolArchitect.
Agent functionality is available only where enabled by an Order Form, Subscription Plan, API Schedule, integration authorization, or other written agreement. These terms supplement the KoolArchitect Subscription Agreement, API Terms, and Acceptable Use Policy.
Agent means an AI-enabled software capability that may select or sequence actions. Agent Action means a tool call or external effect. Agent Owner means the Customer-designated accountable person. Approval Gate means a required authorized review before execution.
Customer remains responsible for every agent it configures, enables, instructs, or permits to act under Customer accounts, including agent objectives, data access, tool permissions, recipients, transactions, outputs, approvals, and downstream consequences.
Each production agent should have a named business owner with authority and knowledge appropriate to the workflow. The Agent Owner is responsible for purpose, scope, permissions, review, escalation, suspension, and periodic reassessment.
An agent must have a documented, bounded purpose. Customer must not deploy an open-ended agent whose objectives, tools, data, recipients, transaction authority, or completion conditions cannot be reasonably described and controlled.
Where supported, an agent should use a distinct, lifecycle-managed identity rather than a shared human or administrator account. Agent activity must remain attributable to the relevant Customer, workspace, principal, session, and delegated authority.
Customer may delegate only authority Customer lawfully possesses. Delegation must identify who authorized the agent, permitted actions, affected systems, data boundaries, limits, duration, and required approvals.
Agent permissions must be limited to the minimum tools, scopes, records, fields, tenants, workspaces, environments, actions, and time necessary. An agent must not receive broader effective authority than the sponsoring user or approved service role.
Where practical, read, draft, preview, write, send, delete, export, execute, and administer capabilities should be separated so that higher-impact actions can receive stricter authorization, approval, logging, and limits.
Agents may invoke only enabled, documented, and authorized tools. Customer must review each tool owner, capability, data reach, arguments, reversibility, approval behavior, logging, and failure mode before production use.
Tool access must be bound to the intended agent, workflow, environment, purpose, and permission scope. Customer must not expose generic administrator tools or unrestricted command execution when narrower functions can accomplish the task.
Customer should constrain recipient domains, record types, allowed values, quantities, amounts, date ranges, file types, export sizes, environments, and other parameters. Prompts alone must not be treated as the sole enforcement mechanism.
Customer is responsible for lawful and accurate instructions, source data, context, attachments, and connected content. Agents may be influenced by incorrect, malicious, outdated, or ambiguous inputs, including prompt injection embedded in retrieved content.
Customers must assess whether untrusted documents, messages, websites, records, or tool outputs can influence an agent. Sensitive actions should require independent authorization, constrained tooling, validation, and appropriate human approval.
Agent-generated plans, reasoning summaries, classifications, and proposed actions may be incomplete or incorrect. Customer must not assume that an apparently coherent plan proves that each step is authorized, safe, accurate, or necessary.
Customer must define where an agent may act independently, where review is required, who can approve, how reviewers receive sufficient context, and when the agent must stop, escalate, revert to manual handling, or await instruction.
Approval should be required for irreversible, high-impact, external, financial, legal, security-sensitive, privacy-sensitive, employment-related, or permission-changing actions unless a signed schedule and documented control design expressly allow bounded automation.
An approval must present enough information for an authorized reviewer to understand the proposed action, target, material inputs, consequences, limits, and relevant exceptions. Rubber-stamping or approval without adequate context is not meaningful oversight.
Agents initiating purchases, payments, credits, refunds, invoices, inventory movements, provisioning, commitments, or contract-related actions require Customer-defined authorization, value limits, recipient validation, reconciliation, and segregation of duties.
Agents that draft or send external communications must use approved identities, recipients, templates, disclosure rules, consent, suppression, review, and escalation controls. Customer remains responsible for the communication and applicable law.
Agents that create, update, approve, reserve, cancel, delete, or reconcile records must preserve authorized business rules, record ownership, validation, traceability, and Customer controls applicable to the connected system.
Agents must not make final employment, credit, insurance, legal-rights, safety, health, or similarly consequential decisions without lawful authority, qualified human review, appropriate evidence, and Customer governance.
An agent must not access, correlate, export, or disclose data outside authorized Customer, tenant, workspace, project, record, field, regional, or purpose boundaries. Combined access across multiple tools must be evaluated as a whole.
Restricted data may be used only when the applicable service, contract, safeguards, and Customer authorization permit it. Agents must not expose secrets, credentials, Personal Data, confidential records, or regulated information through prompts, logs, tools, or messages.
Agent memory, history, summaries, embeddings, caches, files, and persisted context are subject to applicable configuration, retention terms, and data controls. Customer must not assume that deleting a conversation removes all connected copies or downstream records.
If an agent delegates to another agent, the downstream agent must remain within the original authorized purpose and effective permissions. Delegation must not expand authority, bypass review, obscure responsibility, or break traceability.
Customer must implement reasonable limits on steps, retries, duration, concurrency, cost, transactions, messages, tool calls, and recursive delegation. Agents must stop when limits, uncertainty thresholds, policy conflicts, or repeated failures occur.
Production workflows should provide practical means to pause, disable, revoke credentials, block tools, terminate execution, or return to manual operation. Customer must identify who may activate these controls.
Where actions are reversible, Customer should define rollback, correction, compensation, and reconciliation procedures. Where an action cannot be reversed, stronger approval and validation controls are required before execution.
Uncertainty, conflicting instructions, authorization failure, unexpected targets, missing evidence, policy conflicts, unusual values, new recipients, or tool errors should route to an authorized human rather than be silently bypassed.
Where supported, Customer should preserve agent identity, sponsoring principal, instructions, relevant context, tool calls, arguments, approvals, outputs, timestamps, errors, and final results sufficient to investigate material actions.
Customer is responsible for monitoring agent behavior appropriate to impact, including failure rates, denied actions, approval overrides, unusual access, transaction patterns, costs, data movement, and recurring exceptions.
Before production use, Customer should test expected workflows, authorization boundaries, invalid inputs, prompt injection, tool failures, duplicate events, retries, approval paths, stop conditions, rollback, and excessive-agency scenarios.
New or materially changed agents should begin with limited scope, representative data, restricted permissions, controlled users, and increased review where practical. Authority may expand only after Customer evaluates evidence and risk.
Changes to models, prompts, tools, scopes, recipients, workflows, data sources, thresholds, approvals, or connected systems may alter risk and should trigger appropriate review and retesting before release.
Agents may depend on independent AI, cloud, API, communications, identity, payment, ERP, or productivity providers. Provider terms, model behavior, limits, outages, and changes may affect agent performance and availability.
Customer must manage agent credentials, integrations, tokens, service accounts, secrets, dependencies, vulnerabilities, access reviews, and incidents. Compromised or misbehaving agents must be contained promptly.
Customer must promptly report material unauthorized actions, data exposure, credential compromise, runaway execution, significant financial or operational errors, or security events involving an agent and cooperate with containment and investigation.
Kool&Tech may restrict agents, tools, credentials, integrations, workflows, or accounts when reasonably necessary to address misuse, compromise, excessive consumption, legal requirements, platform risk, or material breach.
Agents and Outputs may be inaccurate, incomplete, inconsistent, delayed, or affected by context, models, tools, permissions, providers, and data. Kool&Tech does not guarantee that an agent will achieve a business result or prevent every error.
Agent use must comply with the Responsible AI Statement, AI Use & Disclosure Policy, Acceptable Use Policy, privacy terms, and applicable law. Customer must apply fairness, safety, transparency, accountability, and human oversight appropriate to use.
Kool&Tech retains KoolArchitect, agent frameworks, tools, prompts, orchestration, interfaces, Documentation, and related intellectual property. Customer rights in Customer Content and Outputs remain subject to the governing agreements and law.
Warranties, disclaimers, liability limits, indemnification, confidentiality, force majeure, law, and disputes are governed by the Master Services Agreement or other controlling contract.
For agent matters: signed amendment or Agent Schedule; Order Form; SLA Schedule; DPA; Master Services Agreement; Subscription Agreement; these Agent Terms; API Terms; Acceptable Use Policy; Documentation; incorporated AI and security policies.
Kool&Tech may update these terms as agents, tools, models, risks, laws, and platform controls evolve. Application to active subscriptions follows the governing agreement and applicable law.
Questions about agent eligibility, permission design, approval gates, tools, incidents, or an Agent Schedule may be sent to info@koolandtech.com. Do not include credentials, secrets, or unnecessary sensitive data.
Contact Kool&Tech to define agent purpose, owner, identity, tools, permissions, data boundaries, approval gates, transaction limits, logging, testing, incident handling, and suspension controls.
Back to heading