# AgentShelf - Complete Site Content > Generated: 2026-11-06T02:21:01.737Z > Source: https://agentshelf.ai > Catalog Snapshot Source: api > Catalog Snapshot Generated At: 2026-11-06T02:21:00.913Z > Catalog Hash: 09f4f1916c224f280b6d3228fa331519fb8fb8f6b61b173fe5ce70a892707978 > This file is auto-generated at build time from the current public site source content. This file contains the current public-facing site content for LLM consumption. ## Localization Policy - The full-site export includes published Knowledge Center bodies in their authored English and Spanish locales. - Other AI-readable sections remain English unless explicitly labeled otherwise. - Spanish route listings alone do not imply translated body content. - Legal pages and marketplace agent detail content remain English-only. --- ## Public Routes - Spanish routes are listed for public marketing, blog, Knowledge Center, request-agent, and landing pages. - Legal pages and marketplace agent detail content remain English-only. - https://agentshelf.ai - https://agentshelf.ai/solutions/ai-front-desk - https://agentshelf.ai/platform - https://agentshelf.ai/platform/agent-harness - https://agentshelf.ai/platform/knowledge-tools-automation - https://agentshelf.ai/platform/trust-boundaries - https://agentshelf.ai/platform/governance-cost-controls - https://agentshelf.ai/technology/developer-runtime - https://agentshelf.ai/technology/why-multi-agent - https://agentshelf.ai/technology/architecture - https://agentshelf.ai/technology/infrastructure - https://agentshelf.ai/solutions/ai-builder-platform - https://agentshelf.ai/enterprise - https://agentshelf.ai/discover - https://agentshelf.ai/about - https://agentshelf.ai/work-with-us - https://agentshelf.ai/blog - https://agentshelf.ai/legal - https://agentshelf.ai/es - https://agentshelf.ai/es/solutions/ai-front-desk - https://agentshelf.ai/es/platform - https://agentshelf.ai/es/platform/agent-harness - https://agentshelf.ai/es/platform/knowledge-tools-automation - https://agentshelf.ai/es/platform/trust-boundaries - https://agentshelf.ai/es/platform/governance-cost-controls - https://agentshelf.ai/es/technology/developer-runtime - https://agentshelf.ai/es/technology/why-multi-agent - https://agentshelf.ai/es/technology/architecture - https://agentshelf.ai/es/technology/infrastructure - https://agentshelf.ai/es/solutions/ai-builder-platform - https://agentshelf.ai/es/enterprise - https://agentshelf.ai/es/discover - https://agentshelf.ai/es/about - https://agentshelf.ai/es/work-with-us - https://agentshelf.ai/es/blog - https://agentshelf.ai/request-agents - https://agentshelf.ai/es/request-agents - https://agentshelf.ai/finance/financial-services-ai-agents - https://agentshelf.ai/investors/san-francisco-ai-agent-platform - https://agentshelf.ai/marketing/enterprise-ai-agent-platform - https://agentshelf.ai/marketing/website-ai-agents - https://agentshelf.ai/operations/shadow-ai-compliance - https://agentshelf.ai/sales/salesforce-ai-agents - https://agentshelf.ai/es/finance/financial-services-ai-agents - https://agentshelf.ai/es/investors/san-francisco-ai-agent-platform - https://agentshelf.ai/es/marketing/enterprise-ai-agent-platform - https://agentshelf.ai/es/marketing/website-ai-agents - https://agentshelf.ai/es/operations/shadow-ai-compliance - https://agentshelf.ai/es/sales/salesforce-ai-agents - https://agentshelf.ai/llm.txt - https://agentshelf.ai/llms.txt - https://agentshelf.ai/.well-known/llms.txt - https://agentshelf.ai/llms-marketplace.txt - https://agentshelf.ai/llms-full.txt - https://agentshelf.ai/blog/ai-agents-for-cyber-defense - https://agentshelf.ai/blog/same-model-different-harness - https://agentshelf.ai/blog/the-brain-the-job-the-app - https://agentshelf.ai/blog/same-brain-different-tool - https://agentshelf.ai/blog/rough-edges - https://agentshelf.ai/blog/best-practices-for-product-discovery-with-llm-agents - https://agentshelf.ai/blog/understanding-ai-agents-beyond-the-llm - https://agentshelf.ai/es/blog/ai-agents-for-cyber-defense - https://agentshelf.ai/es/blog/same-model-different-harness - https://agentshelf.ai/es/blog/the-brain-the-job-the-app - https://agentshelf.ai/es/blog/same-brain-different-tool - https://agentshelf.ai/es/blog/rough-edges - https://agentshelf.ai/es/blog/best-practices-for-product-discovery-with-llm-agents - https://agentshelf.ai/es/blog/understanding-ai-agents-beyond-the-llm - https://agentshelf.ai/knowledge - https://agentshelf.ai/knowledge/agent-design - https://agentshelf.ai/knowledge/agent-design/agent-handoffs - https://agentshelf.ai/knowledge/agent-design/choose-an-ai-agent-use-case - https://agentshelf.ai/knowledge/agent-design/define-a-focused-agent-job - https://agentshelf.ai/knowledge/agent-design/human-in-the-loop-ai-agents - https://agentshelf.ai/knowledge/agent-design/structured-agent-workflows - https://agentshelf.ai/knowledge/ai-agent-integration - https://agentshelf.ai/knowledge/ai-agent-integration/agent-sessions-and-artifacts - https://agentshelf.ai/knowledge/ai-agent-integration/embed-an-agentshelf-agent - https://agentshelf.ai/knowledge/ai-agent-integration/external-agent-integration-troubleshooting - https://agentshelf.ai/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform - https://agentshelf.ai/knowledge/ai-agent-integration/llm-provider-failover - https://agentshelf.ai/knowledge/ai-agent-integration/policy-and-capabilities - https://agentshelf.ai/knowledge/ai-agent-integration/public-references-and-secure-bootstrap - https://agentshelf.ai/knowledge/ai-agent-integration/workspaces-and-external-agents - https://agentshelf.ai/knowledge/ai-cyber-defense - https://agentshelf.ai/knowledge/ai-cyber-defense/ai-legacy-system-security - https://agentshelf.ai/knowledge/ai-cyber-defense/ai-supply-chain-security - https://agentshelf.ai/knowledge/ai-cyber-defense/defensive-ai-agents - https://agentshelf.ai/knowledge/ai-cyber-defense/exposed-ai-api-keys - https://agentshelf.ai/knowledge/ai-cyber-defense/operate-defensive-ai-agents - https://agentshelf.ai/knowledge/ai-foundations - https://agentshelf.ai/knowledge/ai-foundations/ai-agent-architecture - https://agentshelf.ai/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation - https://agentshelf.ai/knowledge/ai-foundations/llm-deployment-options - https://agentshelf.ai/knowledge/ai-foundations/llm-infrastructure - https://agentshelf.ai/knowledge/ai-foundations/what-is-an-agent-harness - https://agentshelf.ai/knowledge/ai-foundations/what-is-an-ai-agent - https://agentshelf.ai/knowledge/ai-governance - https://agentshelf.ai/knowledge/ai-governance/agent-operating-boundaries - https://agentshelf.ai/knowledge/ai-governance/ai-agent-change-management - https://agentshelf.ai/knowledge/ai-governance/ai-agent-failure-modes - https://agentshelf.ai/knowledge/ai-governance/ai-agent-governance-and-cost-controls - https://agentshelf.ai/knowledge/ai-governance/ai-agent-governance-checklist - https://agentshelf.ai/knowledge/ai-governance/ai-agent-observability - https://agentshelf.ai/knowledge/ai-governance/ai-agent-permissions-and-boundaries - https://agentshelf.ai/knowledge/ai-governance/ai-agent-security-review - https://agentshelf.ai/knowledge/ai-governance/evaluate-an-ai-agent - https://agentshelf.ai/knowledge/ai-governance/llm-budget-management - https://agentshelf.ai/knowledge/ai-governance/review-agent-tools-and-data-access - https://agentshelf.ai/knowledge/ai-governance/shadow-ai-governance - https://agentshelf.ai/knowledge/ai-governance/share-ai-agents-across-teams - https://agentshelf.ai/knowledge/ai-use-cases - https://agentshelf.ai/knowledge/ai-use-cases/agent-library-vs-custom-build - https://agentshelf.ai/knowledge/ai-use-cases/ai-agent-library - https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-internal-knowledge - https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-lead-qualification - https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-meeting-preparation - https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-research-briefs - https://agentshelf.ai/knowledge/glossary - https://agentshelf.ai/knowledge/knowledge-tools - https://agentshelf.ai/knowledge/knowledge-tools/connecting-agents-to-business-systems - https://agentshelf.ai/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context - https://agentshelf.ai/knowledge/knowledge-tools/knowledge-skills-tools-and-connections - https://agentshelf.ai/knowledge/website-agents - https://agentshelf.ai/knowledge/website-agents/ai-front-desk-agent - https://agentshelf.ai/knowledge/website-agents/design-a-website-agent-knowledge-base - https://agentshelf.ai/knowledge/website-agents/human-handoff-for-website-agents - https://agentshelf.ai/knowledge/website-agents/measure-website-agent-quality - https://agentshelf.ai/knowledge/website-agents/website-agent-vs-chatbot-vs-live-chat - https://agentshelf.ai/knowledge/website-agents/what-is-a-website-ai-agent - https://agentshelf.ai/es/conocimiento - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/agente-de-ia-vs-chatbot-vs-chat-en-vivo - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/disenar-la-base-de-conocimiento - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/medir-la-calidad-del-agente - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-recepcion-con-ia - https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/transferencia-a-una-persona - https://agentshelf.ai/es/conocimiento/casos-de-uso - https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-calificar-oportunidades-comerciales - https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-el-conocimiento-interno - https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-informes-de-investigacion - https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-preparar-reuniones - https://agentshelf.ai/es/conocimiento/casos-de-uso/biblioteca-de-agentes-vs-desarrollo-a-medida - https://agentshelf.ai/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/claves-api-de-ia-expuestas - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/operar-agentes-defensivos-de-ia - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software - https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/seguridad-de-sistemas-heredados-con-ia - https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas - https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/conectar-agentes-con-sistemas-de-negocio - https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones - https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial - https://agentshelf.ai/es/conocimiento/diseno-de-agentes - https://agentshelf.ai/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada - https://agentshelf.ai/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso - https://agentshelf.ai/es/conocimiento/diseno-de-agentes/resultados-estructurados - https://agentshelf.ai/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes - https://agentshelf.ai/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/opciones-de-despliegue-de-llm - https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia - https://agentshelf.ai/es/conocimiento/glosario - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/compartir-agentes-entre-equipos - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/control-de-uso-y-visibilidad - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/fallos-de-agentes-y-recuperacion - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-del-uso-de-ia-no-aprobado - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos - https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes - https://agentshelf.ai/es/conocimiento/integracion-de-agentes - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/integrar-un-agente-con-el-sdk - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/politica-y-capacidades - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/resolver-problemas-de-integracion - https://agentshelf.ai/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos - https://agentshelf.ai/legal/privacy-policy - https://agentshelf.ai/legal/terms-and-conditions - https://agentshelf.ai/legal/cookie-policy - https://agentshelf.ai/legal/acceptable-use-policy - https://agentshelf.ai/legal/ai-and-product-schedule - https://agentshelf.ai/legal/supplemental-credit-terms - https://agentshelf.ai/legal/marketplace-and-publisher-terms - https://agentshelf.ai/legal/voice-and-messaging-schedule - https://agentshelf.ai/legal/professional-services-terms - https://agentshelf.ai/discover/account-prospect-researcher - https://agentshelf.ai/discover/alphafold-protein - https://agentshelf.ai/discover/alphafold-protein-structure-agent - https://agentshelf.ai/discover/apollo-enrichment - https://agentshelf.ai/discover/apolloio-enrichment-agent - https://agentshelf.ai/discover/artifact-builder - https://agentshelf.ai/discover/batch-enrichment-agent - https://agentshelf.ai/discover/biorxiv-preprint-agent - https://agentshelf.ai/discover/browser-automation - https://agentshelf.ai/discover/browser-automation-engineer - https://agentshelf.ai/discover/campaign-analyzer - https://agentshelf.ai/discover/canvas-designer - https://agentshelf.ai/discover/chembl-drug-discovery-agent - https://agentshelf.ai/discover/classification-agent - https://agentshelf.ai/discover/clinicaltrialsgov-agent - https://agentshelf.ai/discover/clinpgx-pharmacogenomics-agent - https://agentshelf.ai/discover/co-investor-discovery-agent - https://agentshelf.ai/discover/company-brand-context-builder - https://agentshelf.ai/discover/competitive-marketing-analyst - https://agentshelf.ai/discover/content-extractor-agent - https://agentshelf.ai/discover/context-analyzer-agent - https://agentshelf.ai/discover/conversation-manager-agent - https://agentshelf.ai/discover/conversion-rate-optimizer - https://agentshelf.ai/discover/crunchbase-api-agent - https://agentshelf.ai/discover/crunchbase-web-scraper - https://agentshelf.ai/discover/customer-growth-renewal-advisor - https://agentshelf.ai/discover/customer-support-tier1 - https://agentshelf.ai/discover/data-extraction-agent - https://agentshelf.ai/discover/data-validator-agent - https://agentshelf.ai/discover/data-visualization - https://agentshelf.ai/discover/data-visualization-specialist - https://agentshelf.ai/discover/deal-strategy-proposal-advisor - https://agentshelf.ai/discover/deduplication-agent - https://agentshelf.ai/discover/digital-advertising-manager - https://agentshelf.ai/discover/discovery-meeting-copilot - https://agentshelf.ai/discover/document-specialist - https://agentshelf.ai/discover/enrichment-pipeline-agent - https://agentshelf.ai/discover/field-mapper-agent - https://agentshelf.ai/discover/generative-artist - https://agentshelf.ai/discover/geo-gene-expression-agent - https://agentshelf.ai/discover/gif-animator - https://agentshelf.ai/discover/gwas-catalog-agent - https://agentshelf.ai/discover/hmdb-metabolome-agent - https://agentshelf.ai/discover/ios-test-automation-engineer - https://agentshelf.ai/discover/kegg-pathway-agent - https://agentshelf.ai/discover/knowledge-base - https://agentshelf.ai/discover/landing-page-builder - https://agentshelf.ai/discover/lead-enrichment - https://agentshelf.ai/discover/lead-qualification-routing-specialist - https://agentshelf.ai/discover/lifecycle-email-strategist - https://agentshelf.ai/discover/linkedin-profile-scraper - https://agentshelf.ai/discover/mcp-server-builder - https://agentshelf.ai/discover/meeting-prep - https://agentshelf.ai/discover/merge-resolution-agent - https://agentshelf.ai/discover/metabolomics-workbench-agent - https://agentshelf.ai/discover/news-aggregator-agent - https://agentshelf.ai/discover/open-targets-drug-discovery-agent - https://agentshelf.ai/discover/pdb-protein-structure-agent - https://agentshelf.ai/discover/pdf-specialist - https://agentshelf.ai/discover/positioning-offer-strategist - https://agentshelf.ai/discover/presentation-builder - https://agentshelf.ai/discover/product-launch-planner - https://agentshelf.ai/discover/prompt-builder-agent - https://agentshelf.ai/discover/pubchem-chemistry-agent - https://agentshelf.ai/discover/response-parser-agent - https://agentshelf.ai/discover/revenue-operations-analyst - https://agentshelf.ai/discover/sales-outreach-strategist - https://agentshelf.ai/discover/salesforce-apex-developer-agent - https://agentshelf.ai/discover/salesforce-bulk-data-agent - https://agentshelf.ai/discover/salesforce-code-review-agent - https://agentshelf.ai/discover/salesforce-custom-object-agent - https://agentshelf.ai/discover/salesforce-deployment-agent - https://agentshelf.ai/discover/salesforce-flow-builder-agent - https://agentshelf.ai/discover/salesforce-integration-agent - https://agentshelf.ai/discover/salesforce-lwc-developer-agent - https://agentshelf.ai/discover/salesforce-orchestrator-agent - https://agentshelf.ai/discover/salesforce-personaccount-agent - https://agentshelf.ai/discover/salesforce-planning-agent - https://agentshelf.ai/discover/salesforce-security-review-agent - https://agentshelf.ai/discover/salesforce-soql-agent - https://agentshelf.ai/discover/salesforce-test-class-agent - https://agentshelf.ai/discover/salesforce-trigger-agent - https://agentshelf.ai/discover/salesql-enrichment-agent - https://agentshelf.ai/discover/search-result-parser-agent - https://agentshelf.ai/discover/seo-content-strategist - https://agentshelf.ai/discover/skill-creator - https://agentshelf.ai/discover/social-media-manager - https://agentshelf.ai/discover/spreadsheet-analyst - https://agentshelf.ai/discover/summarization-agent - https://agentshelf.ai/discover/token-optimizer-agent - https://agentshelf.ai/discover/web-app-tester - https://agentshelf.ai/discover/web-asset-generator - https://agentshelf.ai/discover/web-security-analyst - https://agentshelf.ai/discover/website-content-scraper --- ## Homepage - Route: https://agentshelf.ai - SEO Title: AgentShelf AI Operations Platform | Governed Business AI - SEO Description: Put AI to work across your business without code or uncontrolled LLM spend. Build, deploy, reuse, and govern specialized agents from one platform. ### Hero - Eyebrow: AgentShelf AI operations platform - Title: Put AI to work across your business without code or uncontrolled LLM spend. - Subtitle: AgentShelf gives businesses one place for individual agents, approved context, business surfaces, usage visibility, budget policies, and reusable workflows. - Primary CTA: Request AI agents - Secondary CTA: Launch AI Front Desk - Tertiary CTA: Explore platform - Proof: No-code agent builder, Approved context and tools, Usage and cost governance, Website, workspace, and embedded experiences #### Metrics ##### First use case - Value: AI Front Desk ##### Control layer - Value: Managed foundation ##### Builder path - Value: Agents, APIs, SDKs ### Problem - Label: Why now - Title: AI is moving from experiments to a real operating expense. - Body: Teams are adopting point tools, browser chats, custom bots, and one-off agent builds faster than leaders can govern usage, cost, access, and results. AgentShelf turns that sprawl into reusable business AI operations. - Points: Fragmented tools create duplicated agent builds and inconsistent answers., Unmanaged model access makes spend hard to attribute or control., Useful workflows get trapped in one tool instead of becoming reusable assets. ### Platform - Label: How AgentShelf works - Title: One agent. One workspace. Everything it needs for useful work. - Body: Visitors see the AI Front Desk. Behind it, a dedicated workspace keeps the agent’s instructions, approved context, tools, model access, usage, and controls together. - CTA: Explore the platform #### Pillars ##### Build - Description: Create specialized agents with approved instructions, context, tools, and workflow goals. ##### Deploy - Description: Launch agents across websites, dedicated workspaces, widgets, APIs, and embedded products. ##### Reuse - Description: Turn proven agents into shared library assets instead of rebuilding the same workflow. ##### Govern - Description: Track usage, budgets, access, model behavior, and value by workflow surface. ### Entry Points - Label: Where to start - Title: Start with the fastest use case, then expand into governed workflows. #### Items ##### AgentShelf Starter - Description: Begin with one platform user, one AI Front Desk agent, and its dedicated workspace. - Href: /solutions/ai-front-desk - CTA: Explore AI Front Desk ##### Individual Agent Workspaces - Description: Give one user one agent with approved company context, structured outputs, and repeatable handoffs. - Href: /enterprise - CTA: Explore enterprise ##### Builder Platform - Description: Launch agentic workflows without rebuilding runtime, context, connectors, billing, libraries, and governance. - Href: /solutions/ai-builder-platform - CTA: Explore builder platform ### Governance - Label: Cost governance - Title: Control AI usage before it becomes invisible operating spend. - Body: AgentShelf supports accountable model access and usage with visibility, configured budget policies, attribution, and billing records tied to the workflows creating value. - CTA: Explore cost governance #### Metrics ##### Budget - Value: Configured ##### Gateway - Value: Governed ##### Trace - Value: Attributed #### Items ##### Usage map - Description: Models, users, individual agents, dedicated workspaces, and deployment surfaces. ##### Budget policies - Description: Configure spend limits and review the resulting budget signals where supported. ##### LLM gateway - Description: Use configured provider and model access through one managed control layer. ##### Value attribution - Description: Tie tokens, cost, and workflow value together. ### Builder - Label: Agent operations - Title: Builders create agents. Operators keep control. - Body: AgentShelf gives founders, agencies, and builders the infrastructure needed to create, connect, deploy, and manage agent workflows without rebuilding the surrounding platform. #### Items ##### Agent Builder - Description: Define specialist agents, context, instructions, and reusable workflow patterns. ##### Deployment Surfaces - Description: Use widgets, APIs, SDKs, dedicated workspaces, and supported external sessions. ##### Connectors - Description: Connect agents to business systems, automation, and structured handoffs. ##### Libraries - Description: Find and reuse approved agent patterns through the Agent Library. ### Trust - Label: Trust and operations - Title: Built for public-facing and private business AI boundaries. #### Items ##### Public/private boundaries - Description: Separate website-safe behavior from private workspace context and admin-controlled access. ##### Observability - Description: Review request traces, tool calls, token usage, model/provider details, and cost signals. ##### Admin control - Description: Preserve control over model access, budgets, agent availability, and workspace rollout. ### CTA - Title: Ready to turn your first AI workflow into an operating capability? - Body: Start with a scoped conversation about the agents, governance, and rollout path your business needs. - Primary: Request AI agents - Secondary: Book walkthrough --- ## AI Front Desk / Website Lead Capture - Route: https://agentshelf.ai/solutions/ai-front-desk - SEO Title: AgentShelf Starter | AI Front Desk for Business Websites - SEO Description: AgentShelf Starter includes one user, one AI Front Desk agent, and its dedicated workspace for answering visitor questions, capturing context, and supporting follow-up. ### Hero - Badge: AgentShelf Starter - Eyebrow: Website AI for Main Street - Title: Turn website visits into customer conversations. - Subtitle: AgentShelf Starter brings an AI front desk agent to your website to answer questions, capture leads, book appointments, and hand off context to your team. It includes one platform user, one AI Front Desk agent, and its dedicated workspace. - Proof: Answers from your site, Supports customers instantly, Captures lead context, 15-day trial - Video Title: AgentShelf AI front desk demo #### CTA - Primary: Request your AI Agent ### Problem - Label: The problem - Title: Customers and prospects both need fast answers. Most websites make your team handle every follow-up manually. - Body: Visitors compare services, customers look for help, and teams lose context across forms, inboxes, and basic chat. AgentShelf gives your website a front desk that can guide buyers, support customers, and hand off the full conversation when a person needs to step in. #### Points ##### Prospects need answers before they buy - Description: People compare services, pricing, fit, and next steps before they are ready to talk to your team. The assistant helps them get useful answers while intent is high. ##### Customers need help after they buy - Description: Support questions often start on your website too. The assistant can answer common questions, point people to the right next step, and capture context when follow-up is needed. ##### Teams lose context across handoffs - Description: Forms, inboxes, and basic chat transcripts rarely give the full picture. Your team needs the question, page context, and conversation history behind each sales or support request. ### How It Works - Label: How it works - Title: Simple enough to try on your website. #### Steps ##### Share your website - Description: Send us your site and a few details about your business, services, and ideal customers. ##### We set up your AI front desk - Description: We use your website and business context so the assistant can answer accurately and collect useful lead details. ##### Add it to your site - Description: Install one website script with our help, then test real customer questions before launch. ##### Review leads and conversations - Description: See what visitors asked, which conversations became leads, and what context your team should use for follow-up. ### Outcomes - Label: What it does - Title: Sales and support conversations, handled from your website. - Subtitle: AgentShelf Website AI Agents help your site answer questions, guide buyers, support customers, collect useful details, and hand off the full context when your team needs to step in. #### Cards ##### Answer customer questions instantly - Description: Use your website content and business context to answer questions about services, fit, pricing, locations, policies, process, and next steps. ##### Guide sales conversations - Description: Help high-intent visitors compare options, understand whether you are a fit, and share the context your team needs for follow-up. ##### Handle support requests - Description: Answer common support questions, route visitors to the right next step, and capture the details a human needs when follow-up is required. ##### Give your team full context - Description: Preserve what visitors asked, what they needed, and which pages shaped the conversation, so every sales or support handoff starts with context. ##### Book appointments - Description: Help visitors book appointments through the appointment workflow configured for your business during onboarding. ### Industries - Label: Built for business websites - Title: Built for business websites where customers need answers before they reach out. - Items: Law firms, Med spas, Dental offices, Clinics, Home services, Roofing companies, Real estate teams, Professional services, High-intent websites ### Visibility - Label: Visitor visibility - Title: See what turns visits into leads. - Body: AgentShelf gives growing businesses enterprise-grade website AI without enterprise complexity. Review what visitors asked, which conversations became leads, and what context your team should use for follow-up. #### Items ##### Conversation history - Description: See the questions visitors asked before they shared their contact details. ##### Lead context - Description: Give your team the page and conversation context behind each new opportunity. ##### Conversion signals - Description: Understand which conversations and website moments are turning into leads. ### Pricing - Label: AgentShelf Starter - Title: Start with one site and a clear path to more leads. - Recommended: Most popular - CTA: Request your AI Agent #### Cards ##### 15-day trial - Price: $0 - Description: Try your AI front desk on your website for 15 days before committing to ongoing pricing. ##### Monthly - Price: $100 - Suffix: /month - Description: Simple monthly pricing for businesses that want enterprise-grade website AI without enterprise complexity. ##### Annual - Price: $960 - Suffix: /year - Description: Save the equivalent of two months versus paying monthly. ### Referral - Label: Referral program - Title: Refer a business. Earn free months. - Body: Get one month free for every referred business that adds AgentShelf to their website, up to 12 free months. ### FAQ - Title: Questions about AgentShelf Starter #### Items ##### Who is AgentShelf Starter for? - Answer: Starter is for businesses that want an AI front desk on their website to answer common sales and support questions. It includes one platform user, one AI Front Desk agent, and that agent's dedicated workspace. ##### What information does the AI Front Desk use? - Answer: It uses your approved website content and business context to answer questions about your services, fit, pricing, locations, policies, and next steps. ##### What does setup involve? - Answer: Share your website and a few details about your business, services, and customers. The team helps install one website script, then you can test real visitor questions before launch. ##### Can it book appointments? - Answer: Yes. The AI Front Desk agent books appointments through the appointment workflow set up for your business during onboarding, and it also answers questions, captures leads, and hands off context to your team. ##### Can it hand a conversation to a person? - Answer: It can capture useful lead details and conversation context so your team can follow up. If you need a live transfer or a response-time commitment, confirm that during evaluation. ##### Which CRM or support tools can I connect? - Answer: Share the CRM or support system you use during evaluation so the team can confirm whether it is supported and what setup would involve. ##### How does AgentShelf handle visitor information? - Answer: It uses approved website content and business context, and can preserve conversation history and lead context for follow-up. Discuss retention and deletion requirements before deployment. ##### What does AgentShelf Starter cost? - Answer: Starter includes a 15-day trial. After the trial, pricing is $100 per month or $960 per year. ### Final CTA - Title: Ready to help more website visitors? - Subtitle: Request your AI Agent and we'll help you set it up to answer questions, guide buyers, support customers, and hand off context to your team. #### CTA - Primary: Request your AI Agent ### Learn - Label: Keep learning - Title: Learn about your AI front desk #### Links ##### What is an AI front desk agent? - Path: /knowledge/website-agents/ai-front-desk-agent ##### What is a website AI agent? - Path: /knowledge/website-agents/what-is-a-website-ai-agent ##### Explore the free AI Front Desk offer - Path: /solutions/ai-front-desk/free --- ## AgentShelf Platform - Route: https://agentshelf.ai/platform - SEO Title: AgentShelf Platform | How the AI Agent Stack Works - SEO Description: Explore how AgentShelf connects AI Front Desk, dedicated agent workspaces, approved context and tools, model access, usage, cost, and operating controls. ### Breadcrumb - Home: Home - Current: Platform ### Hero - Eyebrow: AgentShelf Platform - Title: A complete platform behind every focused agent. - Body: Start with one website agent and its dedicated workspace. AgentShelf keeps its instructions, approved context, tools, model access, activity, and controls together—so the next workflow does not require another platform. - Primary CTA: Launch AI Front Desk - Secondary CTA: Book a walkthrough #### Diagram - Eyebrow: The platform, layer by layer - Caption: Every focused agent runs on all four. ##### Layers ###### Agent harness - Detail: Role, instructions, memory ###### Knowledge & tools - Detail: Approved context and actions ###### Governance - Detail: Budgets, policies, usage traces ###### Trust boundaries - Detail: Who sees what, where ### Orientation - Eyebrow: The AgentShelf stack - Title: What feels simple on the surface is connected underneath. - Body: A visitor sees a helpful website conversation. The user sees one focused agent in a dedicated workspace. AgentShelf manages the setup and controls behind both experiences. - Instruction: Select a module for a short explanation. ### Labels - Shared Across: Shared across the platform - Lifecycle: Platform lifecycle - Layer: Layer - Cross Cutting: Cross-cutting controls - Shared Beneath: Shared beneath every layer - Selected Module: Selected module - Learn More: Learn more ### Control Plane - Title: AgentShelf Control Plane - Description: Configure the agent, connect what it needs, put it to work, and keep usage visible from one managed layer. - Verbs: Build, Connect, Deploy, Govern, Measure, Reuse ### Layers #### Where the agent works - ID: surfaces - Number: 01 - Description: The places where customers and users experience the agent. ##### Modules ###### AI Front Desk - ID: frontDesk - Description: A website agent that answers questions, guides conversations, and supports the next step. - Href: /solutions/ai-front-desk ###### Agent Workspace - ID: workspace - Description: The dedicated place where one user manages and works with one focused agent. - Href: /enterprise ###### Product & Developer Surfaces - ID: developerSurfaces - Description: Supported embedded, headless, SDK, and API paths for custom agent experiences. - Href: /technology/developer-runtime #### Build and reuse - ID: build - Number: 02 - Description: Turn a defined job into a specialist, then reuse effective patterns. ##### Modules ###### Agent Builder - ID: builder - Description: Define the job, instructions, knowledge, tools, model behavior, and delivery path. - Href: /solutions/ai-builder-platform ###### Agent Library - ID: library - Description: Find and reuse approved individual-agent patterns instead of starting from a blank prompt. - Href: /discover #### What makes the agent useful - ID: harness - Number: 03 - Description: The practical pieces around the model that prepare an agent for its job. - Note: Together, these pieces form the agent harness. ##### Modules ###### Role & Instructions - ID: role - Compact Title: Instructions - Description: The job, goals, behavior, boundaries, and definition of a useful result. - Href: /platform/agent-harness ###### Context & Memory - ID: context - Compact Title: Context - Description: Approved knowledge, files, conversation context, and available continuity. - Href: /platform/agent-harness ###### Skills, Tools & Permissions - ID: tools - Compact Title: Tools & Permissions - Description: The capabilities the agent may use and the access it receives. - Href: /platform/knowledge-tools-automation ###### Models & Operating Rules - ID: modelRules - Compact Title: Model Rules - Description: Configured model choices, limits, validation, and behavior. - Href: /platform/agent-harness #### Knowledge and action - ID: knowledge - Number: 04 - Description: Approved resources that help the agent move beyond generic answers. ##### Modules ###### Context Libraries - ID: libraries - Description: Managed knowledge and files that keep relevant business information available. - Href: /platform/knowledge-tools-automation ###### Business-System Connections - ID: connections - Description: Configured paths for supported retrieval, synchronization, or action. - Href: /platform/knowledge-tools-automation ###### APIs & MCP - ID: apis - Description: Approved custom capabilities through APIs and Model Context Protocol tools. - Href: /platform/knowledge-tools-automation ###### Configured Automation - ID: automation - Description: Supported scheduled or background patterns for repeatable work. - Href: /platform/knowledge-tools-automation #### Managed execution - ID: execution - Number: 05 - Description: Shared services run supported experiences and return useful results. ##### Modules ###### Model Access & Routing - ID: modelAccess - Compact Title: Model Access - Description: Configured provider and model access with available usage records and limits. - Href: /platform/governance-cost-controls ###### Agent Execution - ID: agentExecution - Description: Managed services run each supported experience according to its configuration. - Href: /technology/developer-runtime ###### Streaming, Results & Events - ID: results - Description: Responses, structured results, errors, and completion signals for supported paths. - Href: /technology/developer-runtime ### Controls - Title: Governance & AI economics - Description: Controls remain in view across the agent, workspace, experience, and services behind them. #### Items ##### Ownership & Access - ID: ownership - Description: Clear ownership and configured access for the agent, workspace, and deployed experience. - Href: /platform/governance-cost-controls ##### Usage & Cost - ID: usageCost - Compact Title: Usage - Description: Available usage and cost information for the configured workflow. - Href: /platform/governance-cost-controls ##### Budgets & Limits - ID: budgets - Compact Title: Limits - Description: Warnings and limits where the selected experience supports them. - Href: /platform/governance-cost-controls ##### Activity Records - ID: activity - Compact Title: Activity - Description: Available events, errors, usage, and operating records. - Href: /platform/governance-cost-controls ##### Public / Private Boundaries - ID: boundaries - Compact Title: Boundaries - Description: Distinct authenticated controls and public or embedded operating contexts. - Href: /platform/trust-boundaries ### Foundation - Title: AgentShelf managed platform - Description: One managed base beneath agent configuration, approved resources, execution, and governance. ### Caption Start with the job. Give the agent what it needs. Keep usage and boundaries visible. Reuse what works. ### Compact #### Bands ##### Where it works - Module Ids: frontDesk, workspace ##### What it needs - Module Ids: role, context, tools, modelRules ##### How it stays accountable - Module Ids: modelAccess, usageCost, budgets, activity, boundaries ### Starter - Eyebrow: AgentShelf Starter - Title: Begin with one website agent and the workspace it needs. - Body: Starter includes one platform user, one AI Front Desk agent, and its dedicated workspace. - Primary CTA: Explore AI Front Desk - Secondary CTA: See Agent Workspaces - Items: One platform user to manage the work., One focused AI Front Desk agent., One dedicated workspace for its context and controls. ### CTA - Title: See the platform behind your first agent. - Body: Walk through the agent, workspace, context, tools, model access, and controls for your first website workflow. - Primary: Book a walkthrough - Secondary: Explore Agent Harness --- ## Agent Harness - Route: https://agentshelf.ai/platform/agent-harness - SEO Title: AI Agent Harness: Context, Tools and Rules | AgentShelf - SEO Description: Learn how an AI agent harness combines role, approved context, tools, permissions, model settings, and a dedicated workspace around one business job. ### Breadcrumb - Home: Home - Platform: Platform - Current: Agent Harness ### Hero - Eyebrow: Agent Harness - Title: Give every agent the context, tools, and rules its job requires. - Body: A model can generate an answer. A useful agent also needs a defined role, approved business context, permitted tools, model rules, and a dedicated place to work. - Primary: Explore Agent Builder - Secondary: See Agent Workspaces #### Diagram - Eyebrow: Agent harness - Agent: Focused agent - Role: Role & instructions - Context: Context & memory - Tools: Tools & permissions - Rules: Model rules ### Problem - Eyebrow: Beyond the prompt - Title: A useful agent needs more than a strong prompt. - Body: Without a defined role, maintained context, clear permissions, and consistent model rules, people end up rebuilding the setup from one conversation to the next. #### Items ##### A focused job - Body: Define the intended user, outcome, and boundaries. ##### Maintained context - Body: Keep relevant knowledge available without repeated copying. ##### Clear capabilities - Body: Make tools and permissions part of the agent definition. ##### Consistent rules - Body: Keep model choices, limits, and expectations visible. ### Definition - Eyebrow: The setup around the model - Title: These pieces form the agent harness. - Body: The agent harness is the combination of instructions, context, tools, permissions, and model rules prepared for a specific job. In practice, it means the user does not have to rebuild the setup for every conversation. #### Items ##### Role & Instructions - Body: The job, goals, behavior, boundaries, and useful result. ##### Context & Memory - Body: Approved knowledge, working files, conversation context, and available continuity. ##### Skills, Tools & Permissions - Body: The capabilities the agent may use and the access it receives. ##### Models & Operating Rules - Body: Configured model choices, limits, validation, and behavior. ### Relationship - Eyebrow: The current AgentShelf model - Title: One agent works with one user through its dedicated workspace. - Body: The workspace is where the user manages the agent’s context, tools, conversations, results, and available activity. #### Items ##### User - Body: Owns the job, reviews the work, and decides the next step. ##### Dedicated workspace - Body: Holds working context and surfaces conversations, results, and records. ##### Focused agent - Body: Applies its defined role, context, tools, and model rules. ### Flow - Eyebrow: From job to working agent - Title: Configure the essentials once. Improve them with evidence. - Note: Available context, tools, records, and deployment behavior depend on the agent and the experience being used. #### Items ##### Define the job - Body: Identify the intended user, outcome, and boundaries. ##### Add context and capabilities - Body: Provide approved knowledge, tools, and permissions. ##### Set the rules - Body: Choose model behavior, limits, and human review points. ##### Test and improve - Body: Use representative work and refine the definition. ### CTA - Title: Turn a clear business job into a focused agent. - Body: See how Agent Builder and the dedicated workspace bring the role, context, tools, and rules together. - Primary: Explore Agent Builder - Secondary: Explore the full platform --- ## Knowledge, Tools and Automation - Route: https://agentshelf.ai/platform/knowledge-tools-automation - SEO Title: AI Agent Knowledge, Tools and Automation | AgentShelf - SEO Description: See how AgentShelf connects agents to approved business context, permitted tools, APIs, Model Context Protocol, and configured automation for supported workflows. ### Breadcrumb - Home: Home - Platform: Platform - Current: Knowledge, Tools & Automation ### Hero - Eyebrow: Knowledge, Tools & Automation - Title: Give your agent approved knowledge and a clear way to act. - Body: Business work needs more than general model knowledge. AgentShelf brings relevant files, permitted tools, supported connections, and configured automation into the same workflow as the agent and its workspace. - Primary: Explore Agent Builder - Secondary: Book a walkthrough #### Diagram - Eyebrow: What the agent draws on - Files: Approved files - Connections: Connections - Automations: Automations - Agent: Agent - Actions: Useful actions ### Problem - Eyebrow: Beyond generic chat - Title: Useful work needs current information and an approved next step. - Body: A model does not automatically know your latest process, have permission to use a business system, or understand when a person must review the result. ### Capabilities - Eyebrow: From information to action - Title: Connect only what the job requires. #### Items ##### Knowledge - Body: Files, approved context, and managed libraries ground the agent in relevant business information. - Examples: Website and service information, Process and policy documents, Working files ##### Skills - Body: Reusable instructions and methods help complete a type of work consistently. - Examples: Research methods, Qualification guidance, Review steps ##### Tools - Body: Permitted tools let the agent retrieve information, call a service, calculate, or produce structured results. - Examples: Approved retrieval, Calculations, Forms and checklists ##### Connections - Body: Configured API, Model Context Protocol, credential, or connector paths link supported business systems. - Examples: API capabilities, MCP tools, User or workspace grants ##### Configured automation - Body: Where supported, scheduled or background execution extends a defined workflow beyond an open conversation. - Examples: Context refresh, Scheduled research, Reporting ### Workflow - Eyebrow: A visible path - Title: Keep the resource, permission, result, and record in view. #### Items ##### Approve the resource - Body: Add the file, context source, tool, or connection the job requires. ##### Set the boundary - Body: Identify the user, agent, workspace, grant, and permitted action. ##### Use the capability - Body: The agent retrieves, analyzes, or acts through the configured interface. ##### Return a useful result - Body: Present an answer, artifact, form, or action outcome for review. ##### Review available activity - Body: Use available usage, error, and result records to understand what happened. ### Review - Eyebrow: Human review - Title: Connection does not remove responsibility. - Body: The process owner chooses appropriate information, access, limits, and human decision points. - Items: Confirm the source and data owner., Distinguish retrieval from write or action access., Limit the capability to the job., Define how incomplete results are handled., Keep a human review point where the decision requires it. ### CTA - Title: Move from a generic answer to connected agent work. - Body: Bring approved context, tools, supported connections, and controls into one agent workflow. - Primary: Explore Agent Builder - Secondary: Explore Developer Platform --- ## Trust and Boundaries - Route: https://agentshelf.ai/platform/trust-boundaries - SEO Title: AI Agent Trust Boundaries: Public vs. Private | AgentShelf - SEO Description: See how AgentShelf distinguishes authenticated controls, dedicated workspaces, and supported public or embedded agent sessions while keeping activity connected. ### Breadcrumb - Home: Home - Platform: Platform - Current: Trust & Boundaries ### Hero - Eyebrow: Trust & Boundaries - Title: Separate private control from public agent experiences. - Body: The person configuring an agent, the user working in its dedicated workspace, and a website visitor need different levels of access. AgentShelf treats them as separate operating contexts and helps evaluators inspect the controls supported for each experience. - Primary: Book a technical walkthrough - Secondary: Explore Developer Platform #### Diagram - Eyebrow: Operating contexts ##### Private - Title: Private workspace - Control: Admin controls - Context: Approved context ##### Public - Title: Public surface - Visitors: Website visitors - Answers: Scoped answers ### Why - Eyebrow: Different actors. Different access. - Title: A public conversation should not become access to private controls. - Body: A platform user may configure instructions, knowledge, tools, model behavior, and limits. A website visitor should receive only the public experience prepared for that surface. ### Model - Eyebrow: How the contexts relate - Title: Keep management, workspace use, and public interaction distinct. - Note: Configuration, access checks, records, retention, and behavior depend on the implemented interface and deployment. #### Items ##### Authenticated management - Body: The platform user configures the agent, approved resources, deployment settings, model behavior, and applicable controls. ##### Dedicated workspace - Body: The authenticated user works with the focused agent, its context, tools, conversations, results, and available activity. ##### Surface-specific configuration - Body: A public or embedded experience receives only the settings and capabilities prepared for that surface. It does not expose the private management experience. ##### Public or embedded session - Body: A visitor or application interacts through the interface prepared for that experience. ##### Connected operating records - Body: Available model, usage, event, error, and result information can return to the platform for review. ### Controls - Eyebrow: What to evaluate - Title: Review the controls for the experience being deployed. #### Items ##### Who owns the experience? - Body: Which user, agent, workspace, widget, or application owns the configuration and request? ##### How is the surface recognized? - Body: Which session and origin checks apply to this public or embedded experience? ##### What can the agent access? - Body: Which information and capabilities are available on this surface? ##### Which rules apply? - Body: Which validation, throttling, limits, and model behavior govern the experience? ##### What can be reviewed? - Body: Which events, errors, model details, usage, cost, and results are available? ##### Who handles exceptions? - Body: What is retained, what depends on customer configuration, and who responds when the workflow fails? ### Related - Eyebrow: Connected, not identical - Title: Governance crosses the system while each surface keeps its own boundary. - Body: Ownership, usage, cost, limits, activity, and boundaries should remain visible across the agent lifecycle. Exact controls and records vary by the experience. - Governance: Explore Governance & Cost - Developer: Explore Developer Platform ### CTA - Title: Review the boundary for the agent experience you plan to launch. - Body: Walk through the controls, dedicated workspace, public or embedded session, permitted tools, and available records. - Primary: Book a technical walkthrough - Secondary: Explore Governance & Cost --- ## Cost Governance - Route: https://agentshelf.ai/platform/governance-cost-controls - SEO Title: LLM Budget Controls and AI Cost Governance | AgentShelf - SEO Description: LLM budget governance for organizations, teams, users, and website agents: set monetary budgets, choose warn-only or blocking limits, and review spend. ### Hero - Eyebrow: Cost governance - Title: Control LLM spending with budgets your organization sets. - Body: Organization admins allocate monetary budgets to organizations, teams, users, and widgets, configure warnings, and choose soft or hard limits for supported requests. - Primary: Book platform walkthrough - Secondary: Explore shadow AI governance #### Diagram ##### Outcomes ###### Budget warning - Kind: warning - Body: Notifies an operator when the configured condition is met; it does not allow or reject requests. ###### Soft limit - Kind: soft - Body: Requests covered by the policy continue with a warning at the applicable soft limit. ###### Hard limit - Kind: hard - Body: Rejects requests covered by the policy when the hard limit is reached. ### Controls - Eyebrow: Policy coverage - Title: Set LLM budgets by organization, team, user, or widget. - Body: Enforcement requires a supported request path and an active policy. Other paths can continue without a budget check. - Scopes Title: Available policy scopes - Scopes: Organization, Team, User, Widget - Paths Title: Where your teams use agents - Owner Note: Organization admins choose budget policies. Access to policy and usage information follows organization permissions. #### Paths ##### Agents used by signed-in teams - Body: Supported authenticated workspace and external-agent requests can apply organization, team, and user policies. ##### Agents in website widgets - Body: Supported widget requests can apply organization and widget policies. #### Items ##### Usage and cost - Body: Review spending by provider, AI model, and request owner where captured. Agent and workspace reporting provides visibility, not separate budget enforcement. ##### Activity records - Body: Investigate runs and errors using the activity records captured by each supported request path. #### Guide - Label: Practical guide: governance and cost controls for AI agents - Supporting: Compare cost and quality, account for retries and review time, and confirm enforcement. - Path: /knowledge/ai-governance/ai-agent-governance-and-cost-controls #### Records Link - Label: Decide which operating records you need - Path: /knowledge/ai-governance/ai-agent-observability ### Flow - Eyebrow: From policy to review - Title: Budget, launch, and respond. #### Steps ##### Allocate a budget - Body: Choose who it covers, the spending limit, and the period. ##### Prepare the rollout - Body: Set warnings and limits. Confirm the workflow enforces them. ##### Respond to spending - Body: After a hard-limit rejection, retry once an authorized operator changes the policy or the budget period resets. Requests are not queued for approval. ### Attribution - Eyebrow: Usage and cost context - Title: Turn usage records into decisions. - Note Title: About the records #### Items ##### Finance - Body: Compare reported spending with allocations and adjust budgets. ##### Operations - Body: Use captured activity and errors to investigate repeated failures. ##### Platform teams - Body: Confirm AI model access and policy enforcement before rollout. #### Notes ##### Coverage - Body: Records can be partial, delayed, or unavailable, depending on the path. Retention varies by record type and configuration. ##### Costs - Body: Cost reporting shows billed costs for usage on AgentShelf-managed access and provider-reported costs when you use your own provider key. Estimates and amounts awaiting reconciliation are not final charges. ##### Invoices - Body: When you use your own provider key, the provider’s invoices remain its financial records. ### Example - Title: Warn-only vs. block: when a team reaches its budget - Disclaimer: Fictional example — not a customer result or savings guarantee. #### Steps ##### Set a policy - Body: Example Company sets monthly limits: $400 soft for the team, $1,000 hard for the organization. Warnings are configured separately. ##### Review the warning - Body: The operator checks recorded spending by agent or workflow, then adjusts the team policy or rollout—or leaves it unchanged. ##### Apply the limits - Body: At the team’s soft limit, covered requests continue with a warning. At the organization’s hard limit, new covered requests are rejected. ### CTA - Title: Plan your next rollout. - Body: Explore budgets, warnings, and supported limits for the agents your teams want to use. - Primary: Book platform walkthrough - Secondary: Explore the enterprise platform ### Monetary - Title: Monetary budgets and token usage - Body: Token consumption contributes to LLM cost; budget limits are monetary. For covered requests, a soft limit lets work continue with a warning and a hard limit rejects the request. Reporting by model, agent, or workspace helps review spending; those reporting dimensions do not add budget scopes. ### FAQ - Eyebrow: FAQ - Title: LLM budget questions #### Items ##### Can I set separate LLM budgets per user or team? - Body: Yes. Supported scopes are organization, team, user, and widget. Organization admins choose the policies; enforcement depends on the supported request path. ##### What happens when an agent hits its budget? - Body: Covered requests continue with a warning at a soft limit. At a hard limit, they are rejected. Retry after an authorized operator changes the policy or the budget period resets; requests are not queued for approval. ##### Should a team budget warn only or block requests? - Body: Use a warning or soft limit when stopping work would cost more than a temporary overspend, such as a pilot you are still measuring. Use a hard limit when spending must not exceed the allocation; covered requests are rejected at the limit. You can combine them, for example a soft team limit inside a hard organization limit. ##### Which requests are covered by budget checks? - Body: Supported authenticated workspace and external-agent requests can apply organization, team, and user policies. Supported widget requests can apply organization and widget policies. An active policy is required; other paths can continue without a budget check. ##### How do I review LLM spend? - Body: Review available records by provider, model, and request owner. Managed access shows billed costs; your own provider key shows provider-reported costs. Coverage and timing depend on the request path. ### Learn - Eyebrow: Keep learning - Title: Plan your spending controls #### Links ##### Explore multi-provider LLM infrastructure - Path: /technology/infrastructure ##### LLM budget management guide - Path: /knowledge/ai-governance/llm-budget-management ##### AI cost governance framework - Path: /knowledge/ai-governance/ai-agent-governance-and-cost-controls --- ## Developer Platform - Route: https://agentshelf.ai/technology/developer-runtime - SEO Title: Developer Runtime for AI Agents | AgentShelf - SEO Description: Embed governed AI agents into websites, products, workflows, and external apps with AgentShelf SDKs, APIs, widget runtime, telemetry, and runtime controls. ### Hero - Eyebrow: Developer Platform - Title: Embed governed AI agents without rebuilding the runtime layer. - Body: AgentShelf gives developers SDKs, widget embeds, headless runtime APIs, and integration patterns for bringing governed agents into websites, products, workflows, and external applications. - Primary CTA: Book technical walkthrough - Secondary CTA: Review SDK examples - Proof Label: Developer platform capabilities - Proof: Widget embeds, Headless APIs, SDK access, Public runtime sessions, Usage telemetry #### Diagram - Eyebrow: Drop-in embed - Tabs: Widget, SDK, REST - Active Tab: Widget - Snippet: - Caption: The hosted widget is one script tag. The SDK and headless API cover custom UIs. ### Surfaces - Eyebrow: Runtime surfaces - Title: One agent runtime, multiple ways to deploy. - Body: Use the surface that matches the experience you are building while keeping each individual agent connected to the same AgentShelf control plane. #### Items ##### Standard widget embed - Description: Add a hosted website agent with the existing widget script when you want the AgentShelf-provided shell, launcher, and visitor experience. - Detail: Best for website AI front desks, visitor questions, lead capture, and support handoff. ##### Headless widget API - Description: Use the browser SDK and public headless runtime when you want to design your own chat UI while relying on AgentShelf for sessions and streaming. - Detail: Best for custom website chat, branded support surfaces, and embedded product workflows. ##### SDK-based product embedding - Description: Build custom agent interfaces with SDK access to sessions, streamed responses, visitor identity, page traces, and lead capture helpers. - Detail: Best for frontend teams building bespoke agent experiences inside web applications. ##### API-backed integrations - Description: Connect agent experiences to external systems and workflows through approved runtime patterns instead of wiring every application directly to model providers. - Detail: Best for portals, partner apps, workflow tools, and system-backed agent experiences. ### Boundaries - Eyebrow: Runtime boundaries - Title: Separate public experiences from authenticated platform controls. - Body: The agent harness—the managed layer around execution—can keep public sessions connected to configured origin checks, access controls, telemetry, and usage tracking without exposing administrative controls. - Note Title: Agent harness boundary - Note: Website agent traffic stays separate from authenticated platform administration while remaining connected to configured runtime controls and records. - Deep Link: Evaluating a public or embedded agent experience? See how authenticated control, the dedicated workspace, and the supported public experience remain distinct. - Deep Link Label: Explore Trust & Boundaries #### Items ##### Public runtime traffic - Label: Public surface - Description: Website widgets, headless public sessions, visitor identity, page context, lead capture, and engagement events. ##### Governed runtime - Label: Shared control - Description: Model routing, usage telemetry, policies, runtime events, traces, and attribution connect runtime activity to the platform. ##### Authenticated controls - Label: Platform access - Description: Agent configuration, admin controls, billing, workspaces, private context management, and governance settings. ### Sdk - Eyebrow: SDK access - Title: Build custom interfaces on top of the AgentShelf widget runtime. - Body: The browser-first AgentShelf widget SDK gives frontend developers access to the headless widget runtime without forcing the standard iframe, modal, launcher, or default UI shell. - Code Label: Example AgentShelf widget SDK pattern - Bullets: Create or restore visitor sessions., Stream assistant responses into your own UI., Render lead forms selected by the runtime., Collect browser attribution and page trace events., Use storage adapters for custom session persistence. - Code: import {, collectBrowserClientContext,, collectStream,, createWidgetClient,, } from '@agentshelf/widget-sdk';, , const client = createWidgetClient({, siteId: 'widget_site_id',, apiBase: 'https://api.agentshelf.ai',, });, , await client.ensureSession({, visitorFingerprint: 'anon-visitor-123',, clientContext: collectBrowserClientContext({, sessionTraceConsent: 'granted',, }),, });, , const reply = await collectStream(, await client.streamMessage({, content: 'What can this agent help me with?',, }),, ); ### Integrations - Eyebrow: Integration patterns - Title: Bring agents into the surfaces your users already use. - Body: Developers can create custom frontends, stream responses, pass approved external context, handle client-side continuations, and capture structured lead or workflow data through supported runtime APIs. #### Items ##### Custom chat UI - Description: Render your own transcript, inputs, quick replies, streaming states, and errors while AgentShelf manages runtime sessions. ##### In-product assistant - Description: Embed an AgentShelf-powered agent inside a product workflow, portal, or customer experience. ##### Lead capture flow - Description: Use runtime form signals and lead capture helpers to collect contact details, route follow-up, and preserve conversation context. ##### Proactive engagement - Description: Evaluate configured engagement gates and show contextual prompts from your own UI. ##### External context - Description: Pass approved external context from the host app while keeping public sessions separate from administrative platform access. ##### Client-side tools - Description: Handle tool calls in the host application and continue the same assistant turn with validated tool results. ### Trust - Eyebrow: Trust layer - Title: Designed for governed public and embedded agent experiences. - Body: Developer integrations are designed to keep authenticated controls inside the platform, public runtime sessions within configured boundaries, and runtime activity available for review. #### Items ##### Origin and access checks - Description: Use configured origins, expected host applications, and access rules to limit public runtime access. ##### Guarded responses - Description: Support public-facing agent behavior with approved configuration and response patterns. ##### Runtime telemetry - Description: Use available runtime traces, usage records, and event visibility for debugging and governance review. ### Note - Title: Public runtime boundary - Body: Public-facing agents use managed runtime sessions with configured telemetry, routing, and governance while private workspace access stays behind authenticated platform controls. ### CTA - Title: Design the agent experience. Use AgentShelf for the runtime. - Body: Bring AgentShelf-powered agents into your website, product, portal, or workflow without rebuilding session management, streaming, engagement, lead capture, telemetry, model routing, and governance infrastructure from scratch. - Primary: Book technical walkthrough - Secondary: Explore Agent Builder --- ## Why Multi-Agent - Route: https://agentshelf.ai/technology/why-multi-agent - SEO Title: Multi-Agent AI: Trade-offs and Evaluation | AgentShelf - SEO Description: When to split work across specialist agents, the coordination trade-offs, and how to evaluate a multi-agent design against a single-agent baseline. ### Hero - Badge: Technical Perspective - Title: When to Use Multi-Agent AI - Subtitle: Multiple agents can help when a workflow has distinct specialist tasks. Routing and handoffs add complexity, so evaluate this design against a single-agent baseline. #### Diagram - Caption: Specialists can separate tasks, with added coordination to manage. - Eyebrow: Three design considerations ##### Steps ###### Context placement - Detail: Context placement can affect retrieval ###### Tool selection - Detail: Large tool catalogs need selection and evaluation ###### Coordination - Detail: Coordination adds steps to evaluate ### Bottom Line - Label: The trade-off - Content: Long contexts and broad tool catalogs can be useful, but performance depends on the task, model, and system design. - Emphasis: Choose the simplest design that meets your quality, cost, and reliability requirements. ### Failures - Badge: Design considerations - Title: Evaluate context, tools, and coordination #### Cards ##### Long context needs evaluation - Number: 1 - Intro: A long context window does not guarantee that a model will use every detail equally. In two retrieval and question-answering tasks, performance often fell when relevant information appeared in the middle of a long input. ###### Items ###### Items Item 1 - Bold: Context placement - Text: can affect whether relevant details are used. ###### Items Item 2 - Bold: Test realistic inputs - Text: across different context lengths and evidence positions. ###### Items Item 3 - Bold: Measure task quality - Text: instead of relying on context-window size alone. ###### Citation - Source: Liu et al., TACL (2024) - Text: The study tested multi-document question answering and key-value retrieval; performance often degraded when relevant information appeared in the middle of long contexts. ##### Tool selection needs evaluation - Number: 2 - Intro: As a tool catalog grows, a system needs to find a useful subset for each request. Selection results depend on the task, retrieval method, and shortlist size. ###### Items ###### Items Item 1 - Bold: Describe tools clearly - Text: with distinct capabilities and argument schemas. ###### Items Item 2 - Bold: Retrieve for the task - Text: instead of exposing an unnecessarily broad catalog. ###### Items Item 3 - Bold: Check tool outcomes - Text: and test whether the right option remains available on harder requests. ###### Citation - Source: Repantis et al. (2026) - Text: The study evaluated tool-selection benchmarks with registries from 20 to 3,251 tools and found trade-offs between shortlist size and task coverage. It does not establish a universal tool-count threshold. ##### Coordination adds its own costs - Number: 3 - Intro: Separating responsibilities can help teams reason about a workflow, while routing, handoffs, and shared state add steps that need their own checks. ###### Items ###### Items Item 1 - Bold: Set bounded responsibilities - Text: and define what each step may access or change. ###### Items Item 2 - Bold: Add completion checks - Text: and explicit recovery paths for failed steps. ###### Items Item 3 - Bold: Compare with a simpler baseline - Text: using the same representative tasks and success criteria. ###### Citation - Source: Gartner (June 25, 2025) - Text: Gartner forecast that over 40% of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. This is a project-level forecast, not an architecture comparison. ### Comparison - Badge: Illustrative scenario - Title: One request, two possible designs - Subtitle: This is a conceptual example, not a measured benchmark or a description of every deployment. #### Scenario - Label: Customer support workflow - Description: A customer asks to check an account balance, dispute a recent charge, and update an email address. #### God Agent - Title: Single-agent design - Badges: One agent, Shared context, Broad task scope - Items: One assistant handles the account lookup, charge investigation, and email change., The assistant selects tools and sequences the work within one agent workflow., The implementation defines how to check results and recover from errors. #### Multi Agent - Title: Multi-agent design - Badges: Specialist roles, Routed tools, Explicit handoffs - Items: A router identifies the requested tasks and their boundaries., A specialist handles the account lookup., A specialist investigates the charge., A specialist handles the email change; checks and recovery are designed explicitly. ### Payoff - Badge: Operational considerations - Title: What an implementation must provide #### Cards ##### Failure handling - Description: Define what happens when a step fails; multiple agents alone do not guarantee graceful recovery. ##### Targeted changes - Description: Clear boundaries can let teams adjust one role independently, subject to integration tests. ##### Traceability - Description: Record routing, tool calls, and outputs to support debugging; traces may not explain every model decision. ##### Model selection - Description: Choose a model for each task after evaluating quality, latency, and cost. ##### Auditability - Description: Document responsibilities, policies, and review points; audit readiness depends on the full implementation. ### Closing - Content: Multi-agent designs add routing, handoffs, and state management. These steps can make responsibilities explicit, but - Emphasis: they need instrumentation and error handling to remain debuggable - Suffix: . ### Sources - Eyebrow: Further reading - Title: Sources #### Items ##### Lost in the Middle: How Language Models Use Long Contexts - Author: Liu et al. - Source: Transactions of the Association for Computational Linguistics, 2024 - URL: https://aclanthology.org/2024.tacl-1.9/ ##### How Many Tools Should an LLM Agent See? A Chance-Corrected Answer - Author: Repantis et al. - Source: arXiv, 2026 - URL: https://arxiv.org/abs/2605.24660 ##### Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 - Author: Gartner - Source: June 25, 2025 - URL: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027 ### CTA - Title: See our architecture in practice - Subtitle: We design multi-agent systems for enterprises in fintech, legal, and compliance-heavy industries. Let's discuss your use case. - Primary: Request Architecture Review - Secondary: View Full Architecture --- ## Architecture - Route: https://agentshelf.ai/technology/architecture - SEO Title: Multi-Agent Architecture | AgentShelf - Why We Don't Build God Agents - SEO Description: Most AI systems fail because they try to do everything with one monolithic agent. We design specialist agents that collaborate behind a unified experience. ### Hero - Badge: Architecture Philosophy - Title: We don't build God Agents - Subtitle: Most AI systems fail because they try to do everything with one monolithic agent. We design specialist agents that collaborate behind a unified experience—so you get reliable outputs even when one agent fails. #### Diagram - Eyebrow: Architecture at a glance - Monolith Label: God Agent - Monolith Caption: One agent, every job - Monolith Chips: Support, Billing, Docs, Sales, Ops - Split Label: AgentShelf - Split Caption: A router and focused specialists - Router Label: Router - Specialists: Knowledge, Advisory, Account ### Problems - Badge: The Problem - Title: Why "God Agents" fail in production - Subtitle: A monolithic agent handling 15-20+ tools in a massive context window creates predictable failure modes that break enterprise operations. #### Cards ##### Context Degradation - Description: Critical information gets "lost in the middle" of long contexts ##### Tool Confusion - Description: Wrong tool selection when descriptions overlap ##### Parameter Hallucination - Description: Inventing plausible but incorrect inputs ##### Non-Determinism - Description: Unpredictable behavior for financial or regulated operations ##### All-or-Nothing Failure - Description: One error breaks the entire system with no fallback ### Solutions - Badge: Our Approach - Title: Multi-Agent architecture - Subtitle: Specialized agents with bounded context, right-sized models, and clear responsibilities—while presenting a unified experience to users. #### Cards ##### Agents Stay Focused - Description: Each agent handles 3-4 tools max—so critical info never gets lost in the middle of long contexts. ##### Pay for What You Need - Description: Fast models for simple tasks, advanced models for complex reasoning—so you're not overpaying for every query. ##### System Stays Up - Description: If one agent fails, the rest keep running—so a single error never takes down your whole system. ##### Debug in Minutes - Description: Every decision traced to a specific agent—so you know exactly what happened when something breaks. ### Diagram - Badge: System Design - Title: How it works - Subtitle: A Router Agent serves as the intelligent front door, classifying user intent and orchestrating responses across specialist agents. #### Layers ##### User - Label: User Interface - Description: "Singular AI" Experience ##### Router - Label: Router Agent - Features: Intent Classification, Multi-Intent Decomposition, Response Orchestration ##### Agents - Label: Specialized Agents - Items: Knowledge Agent, Advisory Agent, Account Agent, Onboarding Agent, Proactive Engine - High Stakes: Transaction Agent ##### Services - Label: Shared Services Layer - Features: Memory & Personalization Store, Audit Trail, User Context Manager ### Tiers - Badge: Model Strategy - Title: Right model for the job - Subtitle: We define model tiers based on capability requirements—not vendor lock-in. AgentShelf's LLM Gateway enables automatic failover across 7+ providers. - Headers: Tier, Use Case, Characteristics #### Rows ##### Fast - Badge: fast - Use Case: Classification, retrieval, pattern matching - Characteristics: Low latency (<500ms), minimal reasoning, cost-efficient ##### Balanced - Badge: balanced - Use Case: Conversational guidance, moderate reasoning - Characteristics: Good reasoning capability, balanced cost/performance ##### Advanced - Badge: advanced - Use Case: Complex reasoning, financial calculations, high-stakes - Characteristics: Maximum reasoning, validation logic, confirmation flows ### Experience - Badge: User Experience - Title: One AI, many specialists - Subtitle: Users never know there are multiple agents. They experience one unified AI assistant. - Callout: Multi-agent is an implementation detail, not a user experience. #### Cards ##### One Voice - Description: Consistent personality across all agents via shared system prompts ##### One Memory - Description: Shared context store enables continuity across conversations ##### One Conversation - Description: Router maintains thread continuity across all handoffs ##### Seamless Handoffs - Description: No "let me transfer you"—transitions are invisible ### CTA - Title: Ready to see this in action? - Subtitle: We design multi-agent architectures for enterprises in fintech, legal, and compliance-heavy industries. Let's discuss your use case. - Primary: Request Architecture Review - Secondary: View Infrastructure --- ## Infrastructure - Route: https://agentshelf.ai/technology/infrastructure - SEO Title: LLM Infrastructure for AI Agents | AgentShelf - SEO Description: Managed LLM infrastructure for AI agents: connect models from multiple providers, apply monetary budgets, and keep usage records in one place. ### Hero - Badge: Managed agent infrastructure - Title: LLM infrastructure your agents can run on. - Subtitle: Connect models from multiple providers, approved knowledge, and tools. AgentShelf brings together LLM access, automatic provider failover, budgets, and supported runtime services. #### Diagram - Eyebrow: AI model access - API Label: AgentShelf managed gateway - Routing Label: Choose configured AI models on supported paths - Providers: OpenAI, Anthropic, Google, Meta, xAI, Microsoft Azure OpenAI, DeepSeek, AWS Bedrock - Caption: Example providers. Availability and capabilities vary by selected AI model, customer configuration, credentials, region, plan, and current catalog. ### Problem - Title: What an agent workflow needs - Content: Use AgentShelf’s managed foundation instead of rebuilding the infrastructure for each workflow. ### Architecture - Eyebrow: From knowledge to action - Title: Deployment options for your agents - Subtitle: From meeting briefs to support answers, connect the information and tools each task calls for. - Architecture Link: Read the AI Agent Architecture guide #### Roles ##### Your business knowledge - Body: Connect approved documents. Your team chooses the data and permissions. ##### A managed foundation - Body: Define and configure the agent. AgentShelf coordinates AI models, context, tools, and supported runtime services. ##### AI model providers - Body: Choose configured AI models from the providers available for the task. ##### Tools to get work done - Body: Look up information and take permitted actions with approved tools. Authorized operators oversee activity. #### Deployment Facts ##### Run with AgentShelf - Value: AgentShelf manages the application and supported runtime services. Configured AI model providers run inference under their own terms; hosting AI foundation models and general-purpose customer compute are not included. ##### Use your own or an external runtime - Value: Your team manages the supported deployment: tools, configuration, execution, networking, availability, and security. ### Capabilities - Eyebrow: Platform capabilities - Title: Connect AI models, tools, and controls. - Subtitle: Availability varies by configured AI model, release, credentials, plan, deployment, and runtime path. #### Cards ##### Multi-provider LLM access - Description: Access configured AI models through the managed gateway. - Features: Select configured AI models for task needs on supported paths., Access providers with the required configuration and credentials. ##### Context and tools - Description: Give agents the context and tools their jobs require. - Features: Connect knowledge and tools approved by your team., Define permissions and configuration for the work. ##### Usage and runtime records - Description: Review operational records from agent runs. - Features: Usage and cost information for operational review., Activity and errors on supported paths. ##### Budget policies - Description: Organization admins choose soft or hard monetary budgets for organization, team, user, and widget scopes on supported paths. - Features: Soft limit reached: covered requests continue with a warning., Hard limit reached: covered requests are rejected. ### Activity - Eyebrow: Operational review - Title: Investigate agent activity and spending. - Subtitle: Authorized operators use records from supported paths to decide where to intervene. - Steps: Run the agent, Inspect run records, Decide next steps - Note: Coverage varies by runtime path; records can be incomplete, delayed, or unavailable. Retention depends on record type and configuration. Cost estimates and amounts awaiting reconciliation are not final charges; provider invoices remain the providers’ financial records. - Link: Learn how to review agent runs #### Record Facts ##### Activity and errors - Value: Investigate what ran and where attention is needed. ##### Usage and costs - Value: Review spending as billed costs, or as provider costs when you use your own key. ### CTA - Title: What would you put your next agent to work on? - Body: Tell us the task. Explore the AI models, tools, and supported deployment options with our team. - Primary: Request Early Access - Secondary: Contact Sales ### FAQ - Eyebrow: FAQ - Title: LLM infrastructure questions #### Items ##### What vendors offer LLM-ready infrastructure? - Body: AgentShelf provides managed access to models from providers such as OpenAI, Anthropic, Google, Meta, xAI, Azure OpenAI, DeepSeek, and AWS Bedrock. Availability depends on configuration, credentials, region, plan, and catalog. ##### What happens when a model provider goes down? - Body: AgentShelf’s architecture includes automatic failover across 7+ providers. Review the configured models and supported paths when evaluating your workflow. ##### Can we use more than one LLM provider? - Body: Yes. Choose configured models from different providers for the needs of each task on supported paths. ##### How are LLM costs tracked and capped? - Body: Review captured usage and cost records. Organization admins choose soft or hard monetary limits; covered requests continue with a warning or are rejected at the applicable limit. ### Learn - Eyebrow: Keep learning - Title: Explore LLM infrastructure #### Links ##### LLM budgets and cost governance - Path: /platform/governance-cost-controls ##### What is LLM infrastructure? - Path: /knowledge/ai-foundations/llm-infrastructure ##### LLM provider failover - Path: /knowledge/ai-agent-integration/llm-provider-failover ##### LLM gateway vs. AI agent platform - Path: /knowledge/ai-agent-integration/llm-gateway-vs-agent-platform ##### Compare LLM deployment approaches - Path: /knowledge/ai-foundations/llm-deployment-options ### Failover - Eyebrow: Reliability - Title: Provider failover and availability - Body: AgentShelf’s architecture includes automatic failover across 7+ providers. Evaluate this capability alongside the configured models and supported paths for your workflow. --- ## Agent Builder - Route: https://agentshelf.ai/solutions/ai-builder-platform - SEO Title: Agent Builder for Agentic Workflows | AgentShelf - SEO Description: Build AI agents and agentic workflows without rebuilding context, tools, deployment, usage tracking, billing, and governance for each one. ### Hero - Eyebrow: Agent builder - Title: Build agentic workflows without rebuilding the operating layer. - Body: AgentShelf gives founders, operators, agencies, and internal builders one platform for creating an individual agent, connecting context and tools, deploying it where work happens, tracking usage, reusing proven patterns, and governing AI work. - Primary CTA: Book builder walkthrough - Secondary CTA: Explore the platform - Proof Label: Agent Builder capabilities - Proof: No-code agent creation, Dedicated agent workspace, Deployment surfaces, Usage visibility, Agent Library, Governance controls #### Diagram - Eyebrow: Workflow builder - Selected Label: Editing - Caption: Assemble the steps. The operating layer underneath stays the same. ##### Steps ###### Trigger - Detail: Website message ###### Agent step - Detail: Answer with approved context ###### Tool call - Detail: Create CRM record ###### Output - Detail: Reply + lead captured ### Problem - Eyebrow: Builder problem - Title: The workflow is valuable. The operating layer slows you down. - Body: Agentic workflows usually start with a clear business need. The hard part is everything around the agent: context, tools, permissions, runtime, lead capture, usage records, billing, observability, and reuse. #### Items ##### Every workflow becomes an infrastructure project - Description: Teams lose time wiring sessions, context, tools, auth, provider access, and deployment surfaces before they can prove the workflow is useful. ##### Useful agents get rebuilt instead of reused - Description: Without libraries and catalog workflows, every team recreates the same research, support, lead qualification, and reporting agents in slightly different ways. ##### Usage and cost become hard to explain - Description: Leaders need visibility into who is using AI and how usage maps to the user, individual agent, dedicated workspace, model, and deployment surface. ##### Public and private boundaries get blurry - Description: Website agents, internal workspaces, and product embeds should not all use the same access pattern. ### Harness - Eyebrow: What makes the agent useful - Title: Put the role, context, tools, and model rules around one focused job. - Body: Agent Builder brings the role, context, tools, and model rules for one focused job into a guided definition. Together, those pieces form the agent harness: the managed setup around the model. - Deep Link: Learn how the agent harness works - Visual Label: AgentShelf builder loop #### Loop ##### Build - Label: 01 - Description: Create specialized agents for specific jobs, teams, and workflows. ##### Connect - Label: 02 - Description: Attach approved context, files, skills, connectors, tools, and automation paths. ##### Deploy - Label: 03 - Description: Run agents in websites, dedicated workspaces, products, and workflow surfaces. ##### Reuse - Label: 04 - Description: Standardize proven agents through approved libraries and Agent Library discovery. ##### Govern - Label: 05 - Description: Track usage, model activity, budgets, cost reporting, and accountability. ### Capabilities - Eyebrow: Platform capabilities - Title: The operating layer around repeatable agentic work. - Body: Use one platform for agent creation, approved context, deployment surfaces, reuse, and governance. #### Items ##### Agent builder - Description: Configure role, goal, context, tools, model behavior, runtime surface, and handoff rules by workflow. ##### Context and tools - Description: Give agents approved files, knowledge, skills, connectors, tools, and automation paths. ##### Deployment surfaces - Description: Deploy agents to websites, dedicated workspaces, products, external applications, and recurring workflow surfaces. ##### Agent Library and reuse - Description: Help organizations standardize, install, update, and reuse effective agents through approved libraries and public catalog discovery. ##### Governance controls - Description: Keep usage, model/provider activity, runtime surfaces, budgets, and operational accountability visible. ### Agent - Eyebrow: Agent builder - Title: Turn repeatable expertise into specialized agents. - Body: Business builders can configure agents around a job to be done. Technical teams can extend deeper runtime paths when needed, but the first step does not need to be a custom app. - Note Title: Builder principle - Note: AgentShelf is not just a prompt box. It is the operating layer for turning repeatable work into managed agent experiences. ### Deployment - Eyebrow: Deployment surfaces - Title: One platform for internal, public, embedded, and automated agent experiences. - Body: Deploy agents where the workflow happens, while keeping the operating layer connected to AgentShelf. #### Items ##### Website AI agents - Description: Answer visitor questions, qualify intent, capture leads, and preserve useful handoff context. ##### Individual agent workspaces - Description: Give one user an authenticated space for working with one agent, its files, tools, generated outputs, and approved context. ##### Product embeds - Description: Use Developer Platform paths when you need a custom frontend or product-integrated agent experience. ##### Automation paths - Description: Support recurring workflows, context refreshes, reports, follow-up, and research tasks where configured. ### Operate - Eyebrow: Operate what you build - Title: Launch agents with visibility and accountability built in. - Body: As workflows move into production, teams need to understand usage, cost, model/provider activity, runtime surfaces, and adoption. #### Items ##### Usage visibility - Description: Track agent, model, token, cost, workspace, user, and deployment-surface activity where reporting dimensions are enabled. ##### Budget accountability - Description: Use budgets, credits, rate limits, and cost reporting to support AI spend management and workflow-level accountability. ##### Model flexibility - Description: Route work through configured model/provider access so teams are not forced to rebuild workflows around one model vendor. ##### Agent Library - Description: Use approved libraries and public catalog discovery to reuse effective individual-agent patterns. ##### Admin oversight - Description: Manage agent access, workspace behavior, public runtime boundaries, and governance controls from the platform. ### Workflows - Eyebrow: Workflow examples - Title: Start with workflows your team already repeats. - Body: The best agentic workflows are usually recurring tasks people already perform manually across sales, support, operations, research, finance, and internal knowledge work. #### Items ##### Website visitor qualification - Description: Answer visitor questions, qualify buying intent, capture lead details, and preserve handoff context. ##### Support triage - Description: Use approved knowledge and workflow rules to classify issues, draft responses, and prepare escalation context. ##### CRM follow-up - Description: Summarize conversations, prepare next steps, and support CRM-connected follow-up workflows where configured. ##### Individual knowledge agent - Description: Give one user a managed agent that can work with approved company context, files, and operating procedures. ##### Sales research - Description: Create repeatable research workflows that help sellers prepare for calls and draft follow-up. ##### Recurring reporting - Description: Support context refreshes, research summaries, recurring analysis, and report preparation where enabled. ### CTA - Title: Create the workflow. AgentShelf handles the operating layer. - Body: Move from agent experiments to repeatable agentic workflows with creation, context, tools, runtime surfaces, usage visibility, reuse, and governance in one platform. - Primary: Book builder walkthrough - Secondary: Explore Developer Runtime --- ## Enterprise - Route: https://agentshelf.ai/enterprise - SEO Title: Enterprise AI Agent Platform | AgentShelf - SEO Description: Give each non-technical user an individual AI agent with a dedicated workspace for approved knowledge, tools, and operating context. ### SEO - Title: Enterprise AI Agent Platform | AgentShelf - Description: Roll out AI agents across your organization with governance, budgets, and shared agent libraries. Plan evaluation and onboarding with our team. ### Hero - Eyebrow: For organizational AI adoption - Title: Plan AI agent adoption - Title Highlight: across your organization - Subtitle: An enterprise AI agent platform with access to multiple LLM providers, monetary budgets, and organization and team libraries. Start with a focused workflow, then plan evaluation and onboarding with our team. - Trust Line: Built by operators from Axos Bank, Google, Bank of America, Comcast Voice AI #### CTA - Primary: Discuss an evaluation - Secondary: Request early access ### Campaign Path - Copy: Already have a repeatable team workflow in mind? Explore a focused page about making team expertise reusable. - Link: Explore reusable team workflows ### Problem - Label: The problem - Title: AI works for individuals. Organizations can't scale it. - Subtitle: LLMs can do everything. Which is why most organizations can't do anything with them. - Chart Source: Source: Anthropic, March 2026 - Chart Source URL: https://www.anthropic.com/research/labor-market-impacts - Gap Header: Why the gap? - Closer: The gap isn't intelligence. It's infrastructure. #### Chart Legend - Theoretical: Theoretical AI Capability - Actual: Actual Enterprise Adoption #### Gaps ##### Build - Title: Nobody can build what they need - Description: Teams can't turn their specific workflow into a tool. The capability is there. The last mile isn't. ##### Scale - Title: What works can't scale - Description: Every org has power users who've figured it out. That knowledge lives in their heads. No way to share it, templatize it, or hand it off. ##### Shadow - Title: Shadow AI fills the vacuum - Description: When approved paths are unclear, employees choose disconnected tools and personal accounts. Without visible ownership and usage records, adoption becomes difficult to manage. - Source: A common enterprise adoption pattern ### Traps - Label: Why existing tools fail - Title: Every AI platform forces a tradeoff. AgentShelf doesn't. - Subtitle: Three categories. Three traps. One way out. - Divider: AgentShelf addresses all three with one managed foundation #### Cards ##### Lock In - Positive: Easy + Powerful - Negative: Not Open - Title: The lock-in trap - Players: Anthropic • OpenAI • Microsoft • Salesforce - Description: Fast to adopt, but changing models or operating environments can require rebuilding around a different stack. ##### Wrapper - Positive: Easy + Open - Negative: Not Powerful - Title: The basic-interface trap - Players: Lightweight AI interfaces - Description: Easy to start, but limited when an agent needs approved tools, knowledge, files, and durable operating context. ##### Diy - Positive: Powerful + Open - Negative: Not Easy - Title: The do-it-yourself trap - Players: Developer tools and custom infrastructure - Description: Flexible, but the organization must assemble and maintain the workspace, integrations, access rules, and deployment path. #### Solutions ##### Open - Badge: Open - Title: Choice without hardwiring - Description: Keep the agent’s purpose and workspace context distinct from any one supported model or deployment surface. ##### Powerful - Badge: Powerful - Title: A workspace for real work - Description: Each individual agent gets a dedicated environment for approved tools, knowledge, files, and operating context. ##### Easy - Badge: Easy - Title: Start with a focused agent - Description: Begin with one user, one individual agent, and one dedicated workspace—without making custom infrastructure the first step. #### Bridge - Title: One user. One focused agent. One dedicated place to work. - Subtitle: The dedicated workspace is where one user manages the agent’s context, tools, conversations, results, and available activity. - Harness Link: Understand the agent harness - Platform Link: See the full platform ### Usecases - Label: Use cases - Title: Real decisions your team faces every week. - Subtitle: Each one used to take 30 minutes of searching and copy-pasting. Now it's a conversation. #### Cards ##### Knowledge - Category: Knowledge - Title: Tribal knowledge, on demand - Scenario: "What's our process for handling enterprise procurement?" - Flow: Search shared docs → Pull playbook sections → Cite sources → Answer in seconds ##### Sales - Category: Sales - Title: Meeting prep in seconds - Scenario: "I have a call with Acme in 20 minutes." - Flow: Pull account context → Draft talking points → Reference last meeting notes → Share with team ##### Support - Category: Support - Title: Ticket resolution from your docs - Scenario: "Customer says their integration broke after the update." - Flow: Search knowledge base → Match known issue → Draft response → Escalate if needed ### Trust - Label: Governance approach - Title: Designed for accountable AI adoption. - Subtitle: Keep ownership, configured access, activity, and usage visible while your organization applies its own security and compliance requirements. - CTA: Explore cost governance #### Cards ##### Keys - Title: Configured model access - Description: Use approved model access and keep agent instructions and workspace context managed separately from a single provider where supported. ##### Audit - Title: Activity and usage records - Description: Review available agent activity, user interaction, and cost records with timestamps and attribution where reporting is enabled. ##### Governance - Title: Clear ownership and review - Description: Keep the user, individual agent, dedicated workspace, and configured policies connected in one reviewable relationship. #### Compliance ##### Soc2 - Title: Ownership - Subtitle: Visible ##### HIPAA - Title: Activity - Subtitle: Reviewable ##### GDPR - Title: Usage - Subtitle: Attributed ##### Aes256 - Title: Boundaries - Subtitle: Configured ### FAQ - Title: Questions about adopting AgentShelf #### Items ##### Who is AgentShelf for? - Answer: AgentShelf is for organizations giving non-technical teams focused AI agents. Each user works with an individual agent in its dedicated workspace for approved knowledge, tools, and operating context. ##### Do we need engineers to get started? - Answer: The intended starting point is guided, no-code setup around a focused use case. Technical teams can extend supported integrations when a workflow requires them. ##### Which integrations are supported? - Answer: Share the CRM, knowledge source, or business system your workflow depends on during evaluation so the team can confirm support and what setup would involve. ##### How do we decide when a person should review an agent's work? - Answer: Agent setup includes defining behavior, limits, and human review points. During evaluation, map which decisions a person should review in your workflow. ##### What information can an agent use? - Answer: You define the approved knowledge, tools, and operating context for an agent's workspace. Discuss your retention, deletion, and data-location requirements during evaluation. ##### What happens during onboarding? - Answer: Start with one focused job, one user, one agent, and its dedicated workspace. Hands-on onboarding scopes workspace configuration, integrations, and governance needs. ### Final CTA - Badge: Organizational evaluation - Title: Choose one workflow to evaluate first. - Subtitle: Request early access to discuss a focused use case. For adoption across several teams, contact sales to discuss organizational fit and onboarding. #### CTA - Primary: Get early access - Secondary: Contact Sales ### Platform - Label: Platform foundation - Title: A shared foundation for AI agent adoption #### Items ##### Infrastructure for mixed LLM providers - Body: Connect configured models, approved knowledge, and tools through managed services and supported runtime paths. - Path: /technology/infrastructure - Label: Explore LLM infrastructure ##### Budgets your organization sets - Body: Admins choose soft or hard monetary budgets for organization, team, user, and widget scopes. Covered requests continue with a warning or are rejected at the applicable limit. - Path: /platform/governance-cost-controls - Label: Explore budget controls ##### Organization and team libraries - Body: Anyone can submit agents. Organization or team managers vet and approve them. Organization agents are available across the organization; team agents are available only to team members. - Path: /discover - Label: Explore the Agent Library ##### Boundaries and human review - Body: Keep private workspaces separate from public or embedded agent sessions, scope access to the experience, and review available activity, usage, errors, and results with the owner. - Path: /platform/trust-boundaries - Label: Explore trust boundaries #### Links ##### What is an AI agent library? - Path: /knowledge/ai-use-cases/ai-agent-library ##### Share AI agents across teams with access rules - Path: /knowledge/ai-governance/share-ai-agents-across-teams --- ## Discover Agents - Route: https://agentshelf.ai/discover - SEO Title: Agent Library | Reusable AI Agent Patterns | AgentShelf - SEO Description: Browse reusable AI agent patterns for support, CRM, productivity, development, research, and more in the AgentShelf Agent Library. ### Hero - Eyebrow: Reusable agent patterns - Title: Agent library - Subtitle: Prepare meeting briefs, find answers in company documents, or analyze spreadsheets. Find an agent to adapt for your team. #### Diagram - Aria Label: Illustrative agent-pattern examples; setup requirements vary by listing. - Eyebrow: Illustrative examples - Request Access: Request access - Summary: Start with the work you need to do. ##### Agents ###### Support - Name: Answer support questions - Category: Support ###### Operations - Name: Prepare a meeting brief - Category: Productivity ###### Research - Name: Analyze a spreadsheet - Category: Data analysis ### Intro - Badge: Choosing a pattern - Title: Start with an agent. Make it yours. - Subtitle: Reuse an agent definition with your knowledge and tools. Scope, hosting, and setup requirements vary by listing. - Comparison Label: Listing purpose and setup needs #### Library - Title: Approved libraries - Description: Keep approved agent patterns organized so repeatable workflows can be adopted consistently. #### Marketplace - Title: Bring your work into the agent - Description: Browse public agent patterns by category, compare fit, and request access when a pattern matches your workflow. - Context Title: Give it the right context - Context Text: Supply approved files and sources for the job. - Tools Title: Connect the tools it needs - Tools Text: Provide the required integrations, credentials, AI model access, and permissions. - Deployment Title: Choose where it runs - Deployment Text: Configure a supported environment and your organization’s policies. ### Featured - Title: Featured patterns - Subtitle: Starting points for research, meetings, knowledge lookup, and support. ### Categories - Title: Browse by category - All: All - Productivity: Productivity - Development: Development - Design: Design - Marketing: Marketing - Data Analysis: Data Analysis - Scientific Research: Scientific Research - Customer Support: Customer Support - CRM: CRM - Other: Other - All Categories: All Categories ### Filters - Category: Category - All: All Categories #### Search - Placeholder: Search agents - Label: Search agents - Clear: Clear search #### Sort - Label: Sort by - Popular: Most Popular - Newest: Newest - Rating: Highest Rated - Name: Name (A-Z) ### Agents - Load More: Load More Agents #### Grid - Showing: Showing {{count}} of {{total}} agents - Page: Page {{current}} of {{total}} - Title: Agent results #### Card - Learn More: Learn More - View Details: View Details - Request Access: Request Access - Featured: Featured - Verified: Verified - Fallback Category: agent - Free: Free - Paid: Paid - Freemium: Freemium - Tags Label: Agent tags - More Tags One: {{count}} more tag - More Tags Other: {{count}} more tags ##### Fallback Descriptions - Data Analysis: Reusable pattern for data analysis. - Productivity: Reusable productivity pattern. - Customer Support: Reusable customer support pattern. - Scientific: Reusable scientific research pattern. - Marketing: Reusable marketing pattern. - Development: Reusable development pattern. - Design: Reusable design pattern. - CRM: Reusable CRM pattern. - Operations: Reusable operations pattern. - Other: Reusable pattern. - Default: Reusable pattern. - Sales: Reusable sales pattern. - Research: Reusable research pattern. ### Empty - Title: No agents found - Message: No agents match the selected filters. - Clear Filters: Clear filters ### Error - Title: Unable to load agents - Message: An error occurred while fetching agents. Please try again later. - Featured Message: Unable to load featured agents. Please try again. - Retry: Try Again - Load More Message: More agents could not be loaded. Try again. ### Loading - Message: Loading agents... ### CTA - Title: What would your agent do? - Subtitle: Discuss your idea with the assistant, or choose Request Access on a listing to explore its fit and setup. - Button: Discuss your agent idea - Assistant Message: I’d like to find a reusable agent for my team’s work and discuss its fit, setup, and access. ### Guidance - Title: Check the fit - Work Fit Title: Task and outcome - Work Fit Text: Does it match your task and expected result? - Access Title: Inputs and permissions - Access Text: Can you safely provide the files, credentials, AI model access, and permissions it needs? - Operations Title: Team operations - Operations Text: Can your team deploy, review, and maintain it in a supported environment? - Constraints: Unsupported integrations or high-risk processes may make a pattern unsuitable. - Link: Read the build-versus-reuse guide ### Listing Access - Helper: Request Access opens the assistant with this listing in context. It does not install the agent or guarantee approval or availability. --- ## About - Route: https://agentshelf.ai/about - SEO Title: About AgentShelf | Team, Mission, and Leadership - SEO Description: Meet the AgentShelf team: enterprise software leaders building a governed AI operations platform that puts specialized agents to work for business teams. ### Hero - Eyebrow: About AgentShelf - Title: AI that works for the teams doing the work - Lede: We build the practical layer that gives teams dependable agents, useful context, and the freedom to choose how they work. ### Bridge - Label: Our point of view - Title: Built for the work between the tools - Body: AgentShelf brings business context, operational control, and flexible AI capabilities into one place so teams can move from experiments to useful work. - Link: See how AgentShelf works for enterprise teams ### Differentiators - Label: Why we're different - Title: Three categories. Three traps. One way out. - Subtitle: Every alternative forces a tradeoff between Easy, Powerful, and Open. AgentShelf is the first platform that doesn't ask you to. ### Mission - Label: Our story - Title: Why we built AgentShelf - Paragraph1: We built more than 50 bespoke AI agents for business clients and saw the same problem: useful agent work was trapped in technical environments, disconnected from the people and workflows that needed it. - Paragraph2: When agents had the right instructions, tools, and business context, work could move much faster. Making that setup dependable and usable was the harder problem. - Paragraph3: AgentShelf is the platform we kept wishing existed: a practical way to build, manage, and review AI agents without forcing every user to become a developer. ### Team - Label: Our team - Title: Leadership - Subtitle: Technical depth and GTM. We've built the platforms and sold them inside the teams we're targeting. - Logos Label: Track record - Logos Title: Where we've built #### Members ##### Gabe Arce - Role: Chief Executive Officer - Bio: Founded and led two enterprise consultancies, Talavera Solutions and Arce Cloud Consulting. Ex-VP, Axos Bank. Led more than 100 enterprise deployments across regulated industries with a team of 50. - Linkedin: https://www.linkedin.com/in/gaarce/ ##### Edgar Joya - Role: Chief Technology Officer - Bio: Founder of Joya Technology. Built data engineering and automation systems at Bank of America for more than seven years, then led engineering at Talavera Solutions and shipped production infrastructure for financial services. - Linkedin: https://www.linkedin.com/in/edgarjoya/ ##### Neil Blackman - Role: Forward Deployed AI Engineer - Bio: Built automation systems across financial services at Axos Bank. Applied AI consulting at Talavera Solutions. Core platform engineer on AgentShelf — built the workspace and the institutional context layer. - Linkedin: https://www.linkedin.com/in/neil-blackman-nnb65a1a/ ### Beliefs - Label: Our principles - Title: What we believe - Subtitle: The non-negotiables behind every product decision we make. #### Items ##### Context that compounds - Description: Give each individual agent a dedicated workspace where approved knowledge, files, tools, and operating context remain available for its work. ##### Model choice without hardwiring - Description: Use supported models for the job and keep agent instructions and workspace context separate from a single provider wherever the implementation supports it. ##### Accountable by design - Description: Keep ownership, activity, and usage visible so people can review how an agent is configured and where it is being used. ### CTA - Title: AgentShelf is the layer that makes AI work for teams. - Subtitle: Easy. Powerful. Open. - Primary Button: Request Early Access - Secondary Button: Contact Sales --- ## Work With Us - Route: https://agentshelf.ai/work-with-us - SEO Title: Work With Us - Become a Design Partner - AgentShelf.ai - SEO Description: Join our exclusive design partner program. Get early access to enterprise AI agents, dedicated support, and influence our product roadmap. ### Hero - Title: AI that actually does the work - Subtitle: These agents are live. See what's possible for yours. #### Diagram - Eyebrow: Live today - Live Label: Live - Caption: Running in production for real teams. ##### Agents ###### AI Front Desk - Category: Website revenue ###### Support Triage - Category: Customer support ###### Lead Enrichment - Category: Sales operations ### Featured Agents - Badge: Built & deployed - Title: Featured agents - Subtitle: Each solves a specific, high-value problem — no code required. - Browse More: Browse more - Or: or - Tell Us: tell us what you need #### Items ##### OCC Regulatory Scraper - Tagline: Automated compliance monitoring - Benefit Label: For Finserv / Compliance - Benefit Result: Low risk, high reward. Saves hundreds of hours. - Tags: Regulatory, Compliance, Alerts - CTA Label: Request Early Access ##### Salesforce Query Agent - Tagline: Natural language CRM queries - Benefit Label: For Sales Ops - Benefit Result: From "Can someone pull this?" to instant answers. - Tags: Salesforce, CRM, Reporting - CTA Label: Request Early Access ##### Collateral Generation Agent - Tagline: Sales decks and one-pagers, generated - Benefit Label: For Sales / CS Enablement - Benefit Result: Hours of prep work reduced to minutes. - Tags: Decks, One-pagers, CRM - CTA Label: Request Early Access ##### Service Agent (Chat Widget) - Tagline: First line of defense, always on - Benefit Label: For Customer Support - Benefit Result: Deflect 60%+ of repetitive Tier 1 queries. - Tags: Chat, Knowledge Base, Support - CTA Label: Request Early Access ### Timeline - Title: From intro to production - Subtitle: A structured engagement where we build together — and you see results before you scale. #### Steps ##### Discovery - Description: We learn your pain points and what success looks like. No pitch — just listening. - Duration: 1 call ##### Data & Demo - Description: You share files and data. We configure the agent and show you it working on your use case. - Duration: 1 week ##### Launch & Fine‑tune - Description: Agent runs live with real users. We iterate weekly based on feedback. - Duration: 30-90 days ##### Decision - Description: We review results together. Clear go/no-go — no pressure, no games. - Duration: 1 call ### What We Need #### Need - Title: What we need from you ##### Items ###### Data access - Description: Files, docs, or system access relevant to your use case ###### A point person - Description: Someone who knows the workflow and can give feedback ###### Time commitment - Description: 1-2 hours/week during pilot for check-ins ###### Clear success criteria - Description: We'll define this together, but you need to know what "good" looks like #### Get - Title: What this gets you ##### Items ###### See results in weeks, not months - Description: Working agent on your data within 2-3 weeks ###### Design partner pricing - Description: Fraction of the cost of building in-house or hiring consultants ###### No lock-in - Description: Walk away at any point. No long-term contracts until you're ready ###### Production-ready outcome - Description: Real automation that works — not a demo that dies after the call ### CTA - Title: Ready to see what this looks like for your team? - Subtitle: We partner with a handful of companies each quarter. Let's see if there's a fit. - Primary Button: Request Early Access - Secondary Button: Contact Sales --- ## Blog Index - Route: https://agentshelf.ai/blog - SEO Title: Blog | AgentShelf - SEO Description: Insights, product updates, use cases, and company news from AgentShelf. Learn about multi-agent AI, enterprise automation, and best practices. ### Hero - Eyebrow: Resources - Title: Insights on AI Agents, Automation & Enterprise AI - Subtitle: Practical guidance for teams building and deploying AI agents in production. No hype, just what works. ### Categories - All: All - Insights: Insights - Product: Product - Use Cases: Use Cases - Company: Company - Title: Filter articles by category ### Filters - Results Count: {{count}} articles - Results Count Singular: 1 article - No Results: No articles found #### Sort - Label: Sort by - Newest: Newest - Oldest: Oldest - Popular: Most Popular ### Featured - Badge: Featured ### Card - Read Time: {{time}} read - Read More: Read More ### Post - Table Scroll Label: Table, scrolls horizontally #### Breadcrumb - Blog: Blog #### Author - By: By #### Toc - Title: Table of Contents #### Tags - Title: Tags #### Share - Title: Share - Twitter: Share on Twitter - Linkedin: Share on LinkedIn - Copy: Copy Link - Copied: Copied! #### Navigation - Previous: Previous Article - Next: Next Article #### Related - Title: Related Articles - Subtitle: Continue exploring these topics. ### Newsletter - Badge: Stay Updated - Title: Get the Latest on Enterprise AI - Subtitle: Join thousands of AI leaders getting weekly insights on building production-ready AI systems. - Placeholder: you@company.com - CTA: Subscribe - Privacy: We respect your privacy. Unsubscribe at any time. - Success: Thanks for subscribing! - Error: Something went wrong. Please try again. - Unavailable: Newsletter subscriptions are not being accepted yet. Check back soon. - Email Label: Email address ### Next Steps #### Index - Title: What would you like to do next? - Body: Browse agents, read developer documentation, or explore what organizational adoption could involve. - Primary CTA: Explore agents - Links Label: More next steps - Docs Link: Open developer docs - Enterprise Link: Explore enterprise adoption #### Articles ##### Same Model Harness - Title: Explore the agent harness - Body: This article compares how the system around a model shapes the work. See the overview of AgentShelf's agent harness. - CTA: See the agent harness ##### Brain Job App - Title: See agents in practice - Body: Move from the parts of an agent to examples in the AgentShelf discovery catalog. - CTA: Browse agents ##### Same Brain Different Tool - Title: Take an agent from concept to integration - Body: Read how to connect an application to AgentShelf's external-agent runtime. - CTA: Read the developer docs ##### Rough Edges - Title: Explore a team adoption path - Body: If you're considering AI for a team, identify a focused workflow, who needs to be involved, and what to resolve before wider adoption. - CTA: Explore enterprise adoption ##### Product Discovery - Title: Move from a product backlog to implementation - Body: Continue with the getting started guide for integrating an AgentShelf agent in your application. - CTA: Read the getting started guide ##### Digital Workers - Title: Plan agent adoption at an organizational level - Body: Frame organizational fit, adoption needs, and the questions to resolve before expanding agent use across teams. - CTA: Explore the enterprise page ### Pagination - Previous: Previous - Next: Next - Page: Page {{current}} of {{total}} ### Empty - Title: No Articles Yet - Description: Check back soon for new content. - CTA: View All Articles - No Results: No posts found - No Results Body: Try selecting a different category or check back later for new content. ### Callout #### Tip - Title: Pro Tip #### Warning - Title: Warning #### Info - Title: Note --- ## Legal Center - Route: https://agentshelf.ai/legal - SEO Title: Legal Center | AgentShelf - SEO Description: Find AgentShelf policies, platform terms, and product schedules in one place. ### Title Legal Center ### Description Find AgentShelf policies, platform terms, and product schedules in one place. ### Read Document Read document ### Groups #### Policies - Title: Policies and platform terms - Description: Privacy, cookies, acceptable use, and the terms for using AgentShelf. #### Product Terms - Title: Product and usage terms - Description: Additional terms for AI services, usage credits, marketplace content, voice, messaging, and professional services. --- ## Landing Pages ### AI Agents For Banking And Financial Services | AgentShelf - Route: https://agentshelf.ai/finance/financial-services-ai-agents - SEO Title: AI Agents For Banking And Financial Services | AgentShelf - SEO Description: Secure AI agents for financial services, banking, loan origination, wealth advisors, client onboarding, and governed operations. - Primary Keyword: AI agents for banking - Secondary Keywords: AI for financial services, financial services AI, banking AI agents, commercial banking AI, AI for loan origination, AI loan processing, wealth management AI agents, compliant banking agents, secure financial workflows - Search Intent: commercial - Audience: banking operations leaders, financial services executives, commercial lending leaders, wealth management leaders, compliance stakeholders - Funnel Stage: consideration - Conversion Goal: book demo - Offer Type: productDemo - Related Pages: https://agentshelf.ai, https://agentshelf.ai/marketing/enterprise-ai-agent-platform, https://agentshelf.ai/operations/shadow-ai-compliance, https://agentshelf.ai/technology/architecture - Schema Types: WebPage, FAQPage - Owner: marketing - Last Updated: 2026-05-19 #### Hero - Eyebrow: Secure AI agents for financial services - Headline: Automate banking, loan, and wealth workflows with governed AI agents - Subhead: AgentShelf helps financial services teams accelerate loan origination, commercial banking operations, client onboarding, advisor prep, and reporting with secure, permissioned AI workflows. #### Body ## Financial services AI has to earn trust before it earns adoption Banks, lenders, wealth firms, and financial services operators have high-value workflows that repeat every day: collecting borrower context, reviewing client information, preparing account summaries, assembling research, drafting follow-up, routing requests, and creating operational reports. AI agents can speed up that work, but only when the workflow is governed from the start. AgentShelf helps financial services teams package repeatable work into secure, reusable AI agents. The goal is not to replace core banking, lending, CRM, portfolio, or compliance systems. The goal is to make the work around those systems faster, more consistent, and easier to control. ## Where financial services AI agents fit ### Automate loan processing and origination Loan origination depends on clean intake, borrower context, document review, missing-information follow-up, and internal handoffs. Agents can help lending teams organize application details, summarize context, prepare checklists, and reduce repetitive processing steps before human review. ### Streamline commercial banking operations Commercial banking teams often move between relationship notes, credit context, account activity, internal policies, and operational requests. Agents can help standardize summaries, route handoffs, prepare client context, and reduce copy-paste work across systems. ### Empower wealth advisors Wealth advisors need fast preparation without sacrificing judgment. Agents can support client onboarding, meeting briefs, account reviews, research organization, and follow-up drafts so advisors start from a stronger reviewed baseline. ## Security and compliance cannot be an afterthought Financial services buyers need more than speed. They need access controls, visibility, audit-aware workflows, and a path for compliance and risk stakeholders to review how AI is used. AgentShelf is built for governed agent adoption with permissions, centralized discovery, model flexibility, and operational visibility. ## Common workflows to launch first - Loan origination summaries and missing-information checklists. - Commercial banking client briefs and relationship handoffs. - Wealth advisor meeting preparation and onboarding support. - Internal research summaries for analyst and operations teams. - Recurring reporting support with review-ready drafts. - Secure financial workflow routing across sales, advisory, operations, and compliance-adjacent teams. ## Move from shadow AI to governed banking automation Financial services organizations do not need AI adoption to happen in personal chat tools or unmanaged workflows. They need practical agents that fit banking, lending, and wealth operations while preserving control. AgentShelf gives teams a governed layer for useful financial services AI without forcing every workflow into a one-off prompt. #### Structured Blocks ##### Metrics - Speed up origination: Loan workflow agents: Help lending teams summarize applications, collect context, prepare handoffs, and reduce repetitive processing work. - Support advisors: Client-ready briefs: Give wealth teams faster preparation for client onboarding, account reviews, and research-backed conversations. - Govern adoption: Secure agent controls: Keep financial workflows permissioned, visible, and aligned with enterprise security and compliance expectations. ##### Testimonial - Quote: Financial services teams do not need unmanaged AI experiments. They need useful agents inside controlled workflows. - Attribution: AgentShelf - Title: Product perspective ##### FAQ - What financial services workflows can AgentShelf support?: AgentShelf can support repeatable work across banking operations, loan origination, commercial banking, wealth management, client onboarding, research summaries, reporting, and operational handoffs. - How can AI agents help loan origination?: Agents can help summarize borrower context, organize application details, prepare missing-information checklists, draft internal handoffs, and reduce manual processing steps before human review. - How can wealth advisors use AI agents?: Wealth teams can use agents for client onboarding support, meeting preparation, portfolio or account summaries, research organization, and follow-up drafts that advisors review before sending. - Is AgentShelf built for secure financial workflows?: AgentShelf is designed around permissions, visibility, audit-aware workflows, model flexibility, and enterprise security controls. Teams should still apply their own regulatory, risk, and compliance review before production deployment. - Does AgentShelf replace banking or wealth systems of record?: No. AgentShelf is an agent workflow layer around the systems teams already trust. The goal is to speed up work while preserving human oversight and existing systems of record. ##### CTA - Headline: Launch secure AI agents for financial services workflows - Body: Book a demo to map banking, loan origination, wealth management, or client onboarding workflows that AgentShelf can help automate. - Primary CTA: Book Demo (#book-demo) ### AgentShelf Investor Meetings In San Francisco | AgentShelf - Route: https://agentshelf.ai/investors/san-francisco-ai-agent-platform - SEO Title: AgentShelf Investor Meetings In San Francisco | AgentShelf - SEO Description: Meet AgentShelf in San Francisco to discuss governed AI agents for business teams, enterprise adoption, and model-flexible AI workflows. - Primary Keyword: AgentShelf investors - Secondary Keywords: AI agent platform investors, enterprise AI agents, governed AI agents, San Francisco investor meetings - Search Intent: navigational - Audience: investors, venture partners, strategic operators - Funnel Stage: conversion - Conversion Goal: book demo - Offer Type: productDemo - Related Pages: https://agentshelf.ai, https://agentshelf.ai/marketing/enterprise-ai-agent-platform, https://agentshelf.ai/operations/shadow-ai-compliance - Schema Types: WebPage - Owner: founders - Last Updated: 2026-04-30 #### Hero - Eyebrow: San Francisco investor meetings - Headline: Business teams need a governed way to adopt AI agents - Subhead: AgentShelf helps non-technical operators build, share, and govern AI agents with enterprise controls and model flexibility from day one. #### Body ## The next enterprise AI layer is operational Companies do not just need access to models. They need a way for business teams to turn repeatable work into governed AI agents. The strongest workflows are often owned by non-technical operators: sales follow-up, research, reporting, support triage, knowledge retrieval, and internal process execution. AgentShelf is built around that operator. It gives teams a way to create, discover, share, and manage useful AI agents while giving leadership the controls required for enterprise adoption. ## The investment thesis AI adoption is moving from individual prompting to reusable workflows. The winning layer will not be a generic chat surface. It will be the system where organizations package expertise, govern access, measure usage, and keep flexibility as the model landscape changes. ## Why this matters now ### Business users are closest to the workflow The people who understand the work often sit outside engineering. They know the handoffs, exceptions, documents, customer questions, and daily decisions that shape the workflow. AgentShelf gives those teams a practical way to turn that expertise into reusable agent experiences. ### Governance is a product requirement Enterprise AI adoption cannot scale through unmanaged tools. Teams need permissions, visibility, shared standards, and a way to understand how agents are being used. Governance is not a later feature. It is part of the adoption loop. ### Model choice will matter The AI model market will keep changing. Companies need a workflow layer that can adapt to different models and providers instead of hard-coding every process into one vendor's roadmap. ## What AgentShelf is building - A shelf of reusable AI agents for business workflows. - Tools for non-technical operators to package useful expertise. - Discovery and sharing so teams can reuse what works. - Governance controls for leadership, compliance, and operations. - A model-flexible foundation for changing enterprise AI strategy. ## Why meet now AgentShelf sits at the intersection of adoption, governance, and model flexibility. For investors evaluating enterprise AI, the question is no longer whether teams will use agents. The question is where those agents will be built, shared, governed, and improved over time. #### Structured Blocks ##### Metrics - Wedge: Operator-built agents: The people closest to the workflow should be able to package repeatable expertise into useful agents. - Enterprise need: Governance from day one: Adoption only scales when permissions, visibility, and controls are part of the platform. - Market shift: Model-flexible workflows: Companies need AI workflows that can adapt as models, providers, and enterprise requirements change. ##### Testimonial - Quote: The platform opportunity is not another chatbot. It is the governed layer where business teams turn repeatable work into reusable agents. - Attribution: AgentShelf - Title: Founder thesis ##### FAQ - Who is AgentShelf built for?: AgentShelf is built for business operators and teams closest to the workflow, with governance controls that make adoption viable for leadership. - What is the core wedge?: AgentShelf starts with practical agent workflows that teams can build, share, and reuse, then expands into governance, discovery, and enterprise-wide adoption. - Why now?: Teams already want AI agents for daily work, but companies need a trusted layer for deployment, visibility, permissions, and model flexibility. - Why model flexibility?: Enterprise AI strategy is still changing quickly. A model-flexible layer helps companies avoid locking every workflow to a single provider. ##### CTA - Headline: Meet AgentShelf in San Francisco - Body: Book a demo to discuss the platform, product direction, and our view of governed AI agent adoption for business teams. - Primary CTA: Book Demo (#book-demo) ### Reusable AI Agent Workflows for Teams | AgentShelf - Route: https://agentshelf.ai/marketing/enterprise-ai-agent-platform - SEO Title: Reusable AI Agent Workflows for Teams | AgentShelf - SEO Description: Explore whether a recurring team workflow is a useful place to start with reusable AI agents. Request early access to discuss a focused use case. - Primary Keyword: reusable AI agent workflows for teams - Secondary Keywords: AI agent workflows for teams, team workflow automation with AI agents, reusable team workflows - Search Intent: commercial - Audience: operations leaders, AI transformation leaders - Funnel Stage: consideration - Conversion Goal: request early access - Offer Type: earlyAccess - Related Pages: https://agentshelf.ai, https://agentshelf.ai/discover, https://agentshelf.ai/technology/architecture, https://agentshelf.ai/enterprise - Schema Types: WebPage, FAQPage - Owner: marketing - Last Updated: 2026-10-15 #### Hero - Eyebrow: Reusable team workflows - Headline: Make your team's expertise reusable with AI agent workflows - Subhead: Choose a recurring task your team knows well. Consider whether an AI agent workflow fits, and which people, context, and access should be reviewed. #### Body ## Choose a workflow your team knows well Choose a recurring task that experienced teammates handle today. Consider whether an AI agent workflow fits that task, and which people, context, tools, and access should be reviewed. Considering adoption across several teams? See the broader [enterprise adoption and evaluation](/enterprise) page. ## What teams can launch - Research agents that collect context and prepare decision-ready summaries. - CRM and follow-up agents that help sellers keep pipeline work current. - Data insight agents that turn raw data into structured analysis. - Knowledge agents that help employees find and reuse internal expertise. - Operations agents that standardize repeated team workflows. For a CRM data workflow, explore the [Enrichment Pipeline Agent](/discover/enrichment-pipeline-agent), which coordinates queries, validation, enrichment, and CRM updates. Define the approved data sources, permitted record changes, and review steps before connecting the workflow to a CRM. ## Start with a reusable agent library Most teams do not need to build their first agent from scratch. Find a candidate in the [Agent Library](/discover) and check that its job matches yours. Then connect your approved information, decide what the agent may do on its own, and name who reviews its results. The [AI agent library guide](/knowledge/ai-use-cases/ai-agent-library) explains how libraries differ from development frameworks and prompt collections. When an agent nearly fits, the [reuse, configure, or build decision](/knowledge/ai-use-cases/agent-library-vs-custom-build) helps you choose the next step. To roll an agent out internally, follow the [agent-sharing guide](/knowledge/ai-governance/share-ai-agents-across-teams): managers decide which agents are added for their organization or team, and each data source keeps its own permissions. Start with one repeatable job and a named owner. Bring the task, the result you expect, and any open integration questions to an early-access conversation. ## Why AgentShelf AgentShelf focuses on the operational layer around AI agents: discovery, reuse, governance, and visibility. That makes it easier for teams to move from experiments to repeatable business workflows while keeping brand, compliance, and quality expectations intact. #### Structured Blocks ##### Metrics - Launch faster: Weeks to minutes: Package repeatable expert workflows as reusable agent experiences. - Govern centrally: One control plane: Keep permissions, model choice, and usage visibility in one place. - Scale expertise: Every team: Make high-quality execution available beyond the original expert. ##### Testimonial - Quote: AgentShelf helped us turn repeatable expert workflows into governed AI agents. - Attribution: Design partner - Title: Operations leader ##### Related Agent Cards - https://agentshelf.ai/discover/lead-enrichment ##### FAQ - Can teams choose their model provider?: Yes. AgentShelf is designed around model choice, governed deployment, and operational visibility. - Is this only for technical teams?: No. The platform is designed for business teams that need reusable AI agents without one-off implementation work. ##### CTA - Headline: Have a repeatable team workflow in mind? - Body: Request early access to discuss a recurring task your team knows well and whether an AI agent workflow fits. - Primary CTA: Discuss a team workflow (#early-access) ### Website AI Agents That Turn Visitors Into Pipeline | AgentShelf - Route: https://agentshelf.ai/marketing/website-ai-agents - SEO Title: Website AI Agents That Turn Visitors Into Pipeline | AgentShelf - SEO Description: Launch a website AI agent that answers questions, captures conversations, qualifies leads, and routes prospects into your CRM. - Primary Keyword: website AI agents - Secondary Keywords: AI website agent, website lead capture AI, AI chat widget for sales, CRM lead routing AI - Search Intent: commercial - Audience: marketing leaders, founders, CEOs - Funnel Stage: consideration - Conversion Goal: book demo - Offer Type: productDemo - Related Pages: https://agentshelf.ai/solutions/ai-front-desk, https://agentshelf.ai, https://agentshelf.ai/discover, https://agentshelf.ai/marketing/enterprise-ai-agent-platform - Schema Types: WebPage, FAQPage - Owner: marketing - Last Updated: 2026-06-07 #### Hero - Eyebrow: Website AI agents - Headline: Turn website visitors into qualified pipeline - Subhead: AgentShelf helps teams launch website AI agents that answer buyer questions, capture every conversation, qualify leads, and route prospects into CRM. #### Body ## The website should start the sales conversation Most website visitors leave before they talk to anyone. They scan a few pages, look for proof, compare options, and disappear when they cannot get a direct answer. A generic chat widget rarely fixes that. It creates another box on the page, but it does not always understand the offer, capture the full conversation, or give sales the context they need. AgentShelf helps you launch a website AI agent that is trained on your approved content and built for conversion. It can answer product questions, guide visitors to the right next step, capture lead details, and preserve the conversation so your team knows what the buyer cared about. ## How it works ### 1. Train the agent Add website URLs, product pages, sales collateral, support documents, or approved files. The agent uses that source material to answer questions with context that matches your company, product, and buyer journey. ### 2. Test and launch it on your website Preview the agent before it goes live. Tune the answers, check the experience, and launch it as a cleaner AI layer on your website. The goal is not another generic bot. The goal is a useful front door for buyers who already have intent. ### 3. Capture and route leads When a visitor is ready, the agent can capture contact details, summarize the conversation, identify the buyer's intent, and route the lead into your CRM or sales workflow. Sales gets more than a form fill. They get the context behind the conversion. ## What the visitor experiences - Fast answers about your product, pricing, services, process, and fit. - Guided next steps instead of a dead-end support-style chat. - A clear path to book a demo when intent is high. - A better experience than searching through pages or waiting for a follow-up. ## What your team gets - Conversations captured instead of lost anonymous traffic. - Lead context that shows what each visitor asked and cared about. - A website AI agent your team can build and test quickly. - A path to CRM handoff without manual copy-paste work. - A more useful AI experience than a generic embedded chat widget. ## Built for the buyer journey Website AI should do more than answer one-off questions. It should help the visitor understand the offer, qualify whether there is a fit, and move toward the next step. AgentShelf gives marketing and sales teams a practical way to turn the website into an active pipeline channel without forcing every visitor through the same static form. #### Structured Blocks ##### Metrics - Train faster: Files and URLs: Give the agent product pages, docs, decks, and site URLs so it can answer with useful context. - Launch easily: Website-ready: Build, test, and add the agent to your site without turning every update into an engineering project. - Capture pipeline: CRM-ready leads: Capture conversations, qualify intent, and route the right prospects into the systems your team already uses. ##### Testimonial - Quote: The value is clear: a better buyer experience on the site and a cleaner handoff into sales. - Attribution: Design partner - Title: Founder ##### FAQ - How is this different from a generic chat widget?: AgentShelf is built for useful buyer conversations, not just a floating prompt box. The agent can be trained on your content, tested before launch, and connected to lead capture and routing workflows. - Can the agent learn from our website and files?: Yes. The page concept centers on training the agent with website URLs, product documents, sales materials, and other approved files. - Does this replace our contact form?: No. It gives visitors a faster way to ask questions and gives your team more context before a form fill, booked demo, or CRM handoff. - Can leads route into CRM?: Yes. The intended workflow captures lead details and conversation context so sales can follow up with a clearer view of what the buyer asked for. ##### CTA - Headline: Put a better AI experience on your website - Body: Book a demo to see how AgentShelf can turn anonymous website traffic into qualified conversations and CRM-ready pipeline. - Primary CTA: Book Demo (#book-demo) ### Reduce Shadow AI Risk With Governed AI Agents | AgentShelf - Route: https://agentshelf.ai/operations/shadow-ai-compliance - SEO Title: Reduce Shadow AI Risk With Governed AI Agents | AgentShelf - SEO Description: Give employees better AI while giving compliance, legal, and operations leaders the governance controls they need. - Primary Keyword: shadow AI compliance - Secondary Keywords: governed AI agents, shadow AI risk, enterprise AI governance, approved AI adoption - Search Intent: commercial - Audience: heads of compliance, legal leaders, COOs, CIOs, security leaders - Funnel Stage: consideration - Conversion Goal: book demo - Offer Type: productDemo - Related Pages: https://agentshelf.ai, https://agentshelf.ai/platform/governance-cost-controls, https://agentshelf.ai/marketing/enterprise-ai-agent-platform, https://agentshelf.ai/technology/architecture - Schema Types: WebPage, FAQPage - Owner: marketing - Last Updated: 2026-04-30 #### Hero - Eyebrow: Shadow AI and compliance - Headline: Shadow AI grows when approved AI fails adoption - Subhead: AgentShelf gives employees AI they actually want to use while giving leadership visibility, permissions, model flexibility, and governance controls. #### Body ## The approved tool is not enough if nobody uses it Many companies have an approved AI tool. That does not mean employees have adopted it. If the sanctioned experience is too limited, too slow, or disconnected from real workflows, people find another way. They use personal accounts, paste sensitive context into unmanaged tools, or build informal workarounds that leadership cannot see. That is the real shadow AI problem. The demand for AI is already inside the company. The risk appears when the useful experience sits outside the governed environment. ## What broke ### Approved AI is too limited Employees need help with research, analysis, summarization, follow-up, documentation, and workflow execution. If the approved option only answers generic prompts, teams will route around it. ### Employees move faster than policy Teams are under pressure to deliver. If a personal AI account helps them finish work faster, policy alone rarely stops adoption. Better tooling has to meet employees where the work happens. ### Leadership loses visibility When AI usage moves into unmanaged tools, compliance, legal, operations, and security leaders lose the ability to understand what is being used, what data is involved, and where risk is forming. ## Why AgentShelf AgentShelf gives companies a governed workspace for AI agents. Business teams can find and use agents that help with real workflows, while leadership keeps the controls needed for enterprise adoption. ## Governance without weak adoption - Governed workspaces for teams and functions. - Permissions that control who can access agent workflows. - Visibility into which agents are being used and why. - Model flexibility that avoids one-provider lock-in. - A better user experience than generic approved chat. ## The adoption-first compliance strategy The best way to reduce shadow AI is not to make approved AI harder to avoid. It is to make approved AI better. When employees have a useful, governed place to work with AI agents, leadership can move from blocking behavior to managing adoption with visibility and control. #### Structured Blocks ##### Metrics - Reduce workarounds: Better approved AI: Give employees capable AI experiences so they do not need personal accounts or unsanctioned tools. - Govern usage: Permissions and visibility: Centralize controls around who can use agents, what they can access, and how they are deployed. - Avoid lock-in: Model optionality: Support model choice so teams can adapt without committing every workflow to one provider. ##### Testimonial - Quote: The risk is not that employees want AI. The risk is that they only get useful AI outside approved channels. - Attribution: Design partner - Title: Operations executive ##### FAQ - What is shadow AI?: Shadow AI is the use of unapproved AI tools, personal accounts, or unmanaged workflows inside a company. It often grows when approved AI tools are too limited for real work. - How does AgentShelf reduce shadow AI risk?: AgentShelf gives teams a governed place to discover, use, and manage AI agents while preserving leadership controls around visibility, permissions, and deployment. - Is this only a compliance tool?: No. The point is adoption and governance together. Employees need useful AI, and leadership needs controls that make the usage accountable. - Can teams use different models?: Yes. AgentShelf is designed around model optionality so companies are not forced into one model provider for every agent workflow. ##### CTA - Headline: Give employees better AI without losing control - Body: Book a demo to see how AgentShelf helps reduce shadow AI risk by pairing useful AI agent experiences with governance controls. - Primary CTA: Book Demo (#book-demo) ### Salesforce AI Agent For Sales And Marketing Teams | AgentShelf - Route: https://agentshelf.ai/sales/salesforce-ai-agents - SEO Title: Salesforce AI Agent For Sales And Marketing Teams | AgentShelf - SEO Description: Build a Salesforce AI agent for CRM updates, lead follow-up, campaign handoffs, pipeline analysis, and governed sales automation. - Primary Keyword: Agentforce alternative - Secondary Keywords: Agentforce competitors, Salesforce AI agents, AI agents for Salesforce, AI for Salesforce, Salesforce AI automation, automate Salesforce with AI, AI CRM data entry, custom Salesforce agents, multi-agent CRM workflows - Search Intent: commercial - Audience: sales managers, marketing professionals, data analysts, Salesforce administrators - Funnel Stage: consideration - Conversion Goal: book demo - Offer Type: productDemo - Related Pages: https://agentshelf.ai, https://agentshelf.ai/marketing/website-ai-agents, https://agentshelf.ai/marketing/enterprise-ai-agent-platform, https://agentshelf.ai/discover - Schema Types: WebPage, FAQPage - Owner: marketing - Last Updated: 2026-05-19 #### Hero - Eyebrow: Salesforce AI agent for go-to-market teams - Headline: Give sales, marketing, and data teams a better Salesforce agent - Subhead: AgentShelf helps teams build Salesforce AI agents that update CRM records, follow up with leads, summarize campaigns, prepare pipeline reports, and keep customer context moving without another manual workflow. #### Body ## Salesforce agents should make the CRM easier for every go-to-market team Salesforce is valuable when sales, marketing, and analytics teams can trust the customer context inside it. In practice, that context is spread across calls, inboxes, meeting notes, website conversations, campaign reports, spreadsheets, enrichment tools, and handoff notes. Sales managers need to know which deals need attention. Marketing teams need campaign and website context to reach sales cleanly. Data analysts need cleaner inputs before they can build useful pipeline, attribution, and performance reporting. AgentShelf helps teams build governed Salesforce AI agents for the work around the CRM. Use it as an Agentforce alternative when you need custom AI agents that fit the way your sales, marketing, and data teams actually work. ## Where a Salesforce AI agent helps ### Automate Salesforce tasks Agents can help transform rep notes, call summaries, form fills, website conversations, and campaign responses into CRM-ready summaries, next steps, and task suggestions. Sales teams spend less time on manual CRM data entry and more time moving the account forward. ### Improve lead follow-up Marketing and sales handoffs often lose context. A Salesforce agent can summarize the campaign source, visitor questions, qualification signals, and likely next step so reps start follow-up with the full story. ### Help analysts trust the CRM Data analysts cannot fix pipeline reporting if the CRM inputs are inconsistent. Agents can flag missing fields, stale notes, incomplete handoffs, and messy summaries before they turn into reporting problems. ## Built for sales, marketing, and data teams Out-of-the-box AI can help with simple tasks, but go-to-market teams usually need workflows that match their accounts, campaigns, lifecycle stages, fields, and reporting needs. AgentShelf gives teams a way to package custom Salesforce agents that are reusable, permissioned, and visible. ## Common workflows to launch first - AI CRM data entry support from meetings, calls, and website conversations. - Lead research and enrichment before outbound or first response. - Campaign-to-sales handoff summaries. - Account and opportunity summaries for pipeline review. - Follow-up drafts and next-step recommendations. - CRM hygiene prompts for stale fields, missing notes, and incomplete handoffs. - Salesforce reporting support for analysts and managers. ## A practical Agentforce competitor for custom workflows AgentShelf is not trying to replace Salesforce. It helps Salesforce stay useful by automating the work around it. For teams comparing Agentforce competitors, the key difference is flexibility: build custom AI agents for sales follow-up, marketing handoffs, CRM updates, and reporting workflows, then govern how those agents are deployed. #### Structured Blocks ##### Metrics - Help sales managers: Cleaner pipeline context: Summarize rep notes, buyer conversations, next steps, and overdue follow-up so managers can see what needs attention. - Support marketing teams: Faster lead handoffs: Turn campaign responses, website conversations, and form context into Salesforce-ready summaries for sales follow-up. - Give analysts better inputs: More usable CRM data: Reduce blank fields, stale notes, and inconsistent handoffs so reporting starts from cleaner Salesforce context. ##### Testimonial - Quote: The win is not another chat box. It is a Salesforce agent that keeps customer context useful after every buyer interaction. - Attribution: AgentShelf - Title: Revenue workflow perspective ##### FAQ - Is AgentShelf an Agentforce alternative?: Yes. AgentShelf is a practical alternative for teams that want custom Salesforce AI agents for CRM updates, lead follow-up, campaign handoffs, and reporting support without limiting every workflow to a native Salesforce add-on. - Who is this Salesforce agent built for?: The page is for sales managers, marketing teams, data analysts, and Salesforce admins who want less manual CRM work and better customer context across sales and marketing workflows. - What Salesforce tasks can AI agents automate?: Common workflows include CRM data entry support, lead and account summaries, meeting-note summaries, follow-up drafts, campaign handoff summaries, pipeline reporting support, and CRM hygiene prompts. - Does AgentShelf replace Salesforce?: No. Salesforce remains the CRM and system of record. AgentShelf helps teams automate and govern the work around Salesforce so records, handoffs, and follow-up stay current. - Why use multi-agent CRM workflows?: Salesforce work often crosses sales follow-up, marketing campaign context, data cleanup, lead routing, and reporting. Multi-agent workflows let teams coordinate those steps while keeping permissions and visibility in one place. - Can non-technical teams build Salesforce AI workflows?: AgentShelf is designed for operator-led workflows. Sales, marketing, analytics, and admin teams can shape reusable Salesforce agents around approved processes while keeping governance centralized. ##### CTA - Headline: Build a Salesforce AI agent your team will actually use - Body: Book a demo to map Salesforce automation workflows for sales follow-up, campaign handoffs, CRM data entry, and reporting support. - Primary CTA: Book Demo (#book-demo) --- ## Marketplace Catalog - Input: Immutable marketplace catalog snapshot - Snapshot Source: api - Snapshot Generated At: 2026-11-06T02:21:00.913Z - Catalog Hash: 09f4f1916c224f280b6d3228fa331519fb8fb8f6b61b173fe5ce70a892707978 - API Base: https://api.agentshelf.ai/api - Snapshot Agent Count: 94 - Eligible Public Agent Count: 94 ### Account & Prospect Researcher - Route: https://agentshelf.ai/discover/account-prospect-researcher - Category: crm - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 2 - Created At: 2026-09-18T00:48:32.129Z - Tags: account-research, prospecting, buying-groups, account-intelligence, research-briefs, sales-development, evidence-led Tagline: Know which accounts deserve the next look. Short Description: Discovers and evaluates target accounts, assesses observable fit against criteria, and produces dated account briefs and stakeholder maps. Research target accounts with dated sources, clear identity boundaries, and explicit unknowns. Get a shortlist or account brief that separates observable fit and timing signals from qualification and buying intent. Perfect For: Sales development teams, account executives, and research-led founders. Time Savings: Illustrative estimate: 63% less time for one account research brief. Result: A sourced account brief or research shortlist with next checks. Traditional: 240 minutes (estimated) AgentShelf: 90 minutes (estimated) Improvement: 63% #### Key Features - Account discovery: Find or normalize candidate accounts against supplied criteria, exclusions, and market scope. - Evidence briefs: Summarize company context, dated signals, source coverage, counterevidence, and unknown gates. - Buying-group maps: Map relevant functions and supported professional identities without inferring authority or contact permission. - Research priorities: Rank the next useful check by fit, timing relevance, confidence, exclusions, and evidence limits. ### AlphaFold Protein Structure - Route: https://agentshelf.ai/discover/alphafold-protein - Category: scientific_research - Featured: No - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.9 - Rating Count: 42 - Installs: 0 - Created At: 2025-12-30T18:39:28.974Z - Tags: UniProt, AlphaFold, Drug Discovery, Structural Biology, Proteins, Research Tagline: Protein insights at your fingertips Short Description: Analyze protein structures and predict molecular interactions using AlphaFold data. Access AlphaFold protein structure predictions and analyze molecular interactions. Accelerate drug discovery and structural biology research. Perfect For: Researchers Time Savings: Weeks of research → Days Result: Accurate structure predictions Traditional: Weeks AgentShelf: Minutes Improvement: 99% #### Key Features - Structure Lookup: Search AlphaFold database by UniProt ID - Interaction Analysis: Predict protein-protein interactions - 3D Visualization: View protein structures in 3D - Export Data: Export structures for further analysis ### AlphaFold Protein Structure Agent - Route: https://agentshelf.ai/discover/alphafold-protein-structure-agent - Category: scientific_research - Featured: No - Pricing: Freemium - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.9 - Rating Count: 43 - Installs: 0 - Created At: 2025-12-06T01:03:45.033Z Tagline: Access 200M+ AI-predicted protein structures for structural biology research. Short Description: Access 200M+ AI-predicted protein structures for structural biology research. The AlphaFold Agent provides access to DeepMind's AlphaFold Database of over 200 million AI-predicted protein structures for structural biologists, drug discovery researchers, and protein engineers. Retrieve structures by UniProt ID, analyze confidence metrics (pLDDT, PAE), and download coordinate files for computational workflows. **Key Capabilities:** - Structure retrieval by UniProt accession - PDB/mmCIF coordinate file downloads - Confidence metric analysis (pLDDT, PAE) - Bulk proteome dataset access via Google Cloud - Structure parsing and analysis **Database Connections:** - AlphaFold Database (REST API) - 200M+ AI-predicted protein structures — alphafold.ebi.ac.uk - Structure Downloader (Python) - Retrieve PDB/mmCIF coordinate files — Biopython - Confidence Analyzer (Python) - Evaluate prediction quality (pLDDT, PAE scores) - Proteome Browser (Cloud) - Access bulk datasets for complete organisms — Google Cloud Storage Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Apollo.io Enrichment Agent - Route: https://agentshelf.ai/discover/apollo-enrichment - Category: crm - Featured: No - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.6 - Rating Count: 108 - Installs: 0 - Created At: 2025-12-30T18:39:28.986Z - Tags: Apollo.io, Contacts, B2B, Enrichment, Sales, CRM Tagline: B2B data enrichment, automated Short Description: Enrich contact and company data using Apollo.io's database of B2B contacts. Automatically enrich your CRM contacts with Apollo.io data. Get verified emails, phone numbers, company info, and buying signals. Perfect For: Sales Teams Time Savings: Manual research → Instant enrichment Result: Complete, verified contact data Traditional: 15-30 min AgentShelf: < 5 seconds Improvement: 98% #### Key Features - Contact Enrichment: Get verified emails and phone numbers - Company Data: Access company size, revenue, and tech stack - Buying Signals: Identify prospects ready to buy - CRM Sync: Auto-update Salesforce or HubSpot ### Apollo.io Enrichment Agent - Route: https://agentshelf.ai/discover/apolloio-enrichment-agent - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: John Smith - Publisher Verified: No - Rating: 4.7 - Rating Count: 54 - Installs: 0 - Created At: 2025-12-08T19:08:40.057Z - Tags: Apollo.io, Contacts, B2B, Enrichment, Sales, CRM Tagline: B2B data enrichment, automated Short Description: B2B contact discovery and company enrichment via Apollo.io API with email verification. The Apollo Agent provides B2B contact discovery and enrichment for sales teams. Search for contacts at specific companies, enrich by email or LinkedIn, verify email deliverability, and find decision makers by title. **Key Capabilities:** - Contact enrichment (email/LinkedIn) - Company enrichment by domain - People search at companies - Email verification - Contact discovery by title **Tools & Integrations:** - Apollo.io API - B2B contact and company data - Email Verifier - Checks deliverability - Salesforce Mapper - Maps to SF objects Perfect For: Sales Teams Time Savings: Manual research → Instant enrichment Result: Complete, verified contact data Traditional: 15-30 min AgentShelf: < 5 seconds Improvement: 98% #### Key Features - Contact Enrichment: Get verified emails and phone numbers - Company Data: Access company size, revenue, and tech stack - Buying Signals: Identify prospects ready to buy - CRM Sync: Auto-update Salesforce or HubSpot ### Artifact Builder - Route: https://agentshelf.ai/discover/artifact-builder - Category: development - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.7 - Rating Count: 78 - Installs: 0 - Created At: 2025-12-06T01:03:44.363Z Tagline: Build multi-component Claude artifacts with React, Tailwind, and shadcn/ui. Short Description: Build multi-component Claude artifacts with React, Tailwind, and shadcn/ui. The Artifact Builder creates elaborate, interactive Claude.ai HTML artifacts for developers building custom tools. Use React 18, TypeScript, Tailwind CSS 3.4, and 40+ pre-installed shadcn/ui components with Parcel bundling for single HTML output. **Key Capabilities:** - React 18 + TypeScript + Vite setup - Tailwind CSS 3.4.1 with shadcn/ui - 40+ pre-installed UI components - Parcel bundler for single HTML output - Path aliases (@/) configured **Tools & Integrations:** - Component Builder (TypeScript) - Create React components with TypeScript — React - Style System (CSS) - Apply Tailwind CSS utility classes — Tailwind CSS - UI Library (TypeScript) - 40+ pre-built interactive components — shadcn/ui - Bundler (JavaScript) - Package everything into a single deployable HTML file — Parcel Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Batch Enrichment Agent - Route: https://agentshelf.ai/discover/batch-enrichment-agent - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 35 - Installs: 0 - Created At: 2025-12-08T19:08:40.573Z Tagline: Orchestrate batch enrichment operations with rate limiting, progress tracking, and checkpoint/resume. Short Description: Orchestrate batch enrichment operations with rate limiting, progress tracking, and checkpoint/resume. The Batch Enrichment Agent orchestrates batch enrichment operations at scale. Manages rate limits across providers, tracks progress with ETAs, handles errors gracefully, and supports checkpoint/resume for large batches. **Key Capabilities:** - Batch processing with configurable sizes - Rate limit management across providers - Progress tracking with ETA - Error handling and recovery - Checkpoint/resume for large batches - Audit logging **Tools & Integrations:** - Batch Processor - Parallel batch execution - Rate Limiter - Cross-provider rate management - Checkpoint Manager - Resume interrupted batches Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### bioRxiv Preprint Agent - Route: https://agentshelf.ai/discover/biorxiv-preprint-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.7 - Rating Count: 31 - Installs: 0 - Created At: 2025-12-06T01:03:45.168Z Tagline: Search and download life sciences preprints from bioRxiv by keyword or author. Short Description: Search and download life sciences preprints from bioRxiv by keyword or author. The bioRxiv Agent searches the bioRxiv preprint server for researchers conducting literature reviews and tracking scientific publications. Search by keywords, authors, date ranges, or subject categories, retrieve paper metadata, and download PDFs for full-text analysis. **Key Capabilities:** - Keyword search in titles and abstracts - Author-specific searches - Date range filtering - Category filtering (27 subject areas) - PDF download for selected papers **Database Connections:** - bioRxiv Database (REST API) - Life sciences preprint repository — biorxiv.org - Paper Search (REST API) - Find articles by keyword, author, or date — bioRxiv API - PDF Downloader (HTTP) - Retrieve full-text manuscripts - Category Filter (REST API) - Browse 27 subject areas Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Browser Automation Engineer - Route: https://agentshelf.ai/discover/browser-automation - Category: development - Featured: No - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.5 - Rating Count: 72 - Installs: 0 - Created At: 2025-12-30T18:39:29.001Z - Tags: Browser, Playwright, E2E, Testing, Automation, QA Tagline: Browser testing, automated Short Description: Automate browser testing with Playwright for E2E testing and web automation. Create robust browser automation scripts using Playwright. Write E2E tests, scrape websites, and automate repetitive web tasks. Perfect For: Developers Time Savings: Manual testing → Automated E2E Result: Reliable, maintainable tests Traditional: 2-4 hours AgentShelf: 30 minutes Improvement: 85% #### Key Features - E2E Testing: Write comprehensive end-to-end tests - Web Scraping: Extract data from any website - Task Automation: Automate repetitive browser tasks - Cross-browser: Test on Chrome, Firefox, Safari ### Browser Automation Engineer - Route: https://agentshelf.ai/discover/browser-automation-engineer - Category: development - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.7 - Rating Count: 132 - Installs: 0 - Created At: 2025-12-06T01:03:43.803Z - Tags: Browser, Playwright, E2E, Testing, Automation, QA Tagline: Browser testing, automated Short Description: Automate browser testing with Playwright for E2E tests and web scraping. The Browser Automation Engineer creates reliable browser automation for QA engineers and developers. Build end-to-end tests, capture screenshots, fill forms, validate responsive designs, and scrape web content across Chrome, Firefox, and Safari with automatic dev server detection. **Key Capabilities:** - End-to-end test creation - Dev server auto-detection - Responsive design testing (multiple viewports) - Form filling and submission - Screenshot capture and link validation **Tools & Integrations:** - Browser Controller (Python/JavaScript) - Automate Chrome, Firefox, and Safari interactions — Playwright - Screenshot Capture (Python/JavaScript) - Take full-page and element screenshots — Playwright - Form Automator (Python/JavaScript) - Fill and submit web forms programmatically - Responsive Tester (Python/JavaScript) - Validate layouts across multiple viewport sizes Perfect For: Developers Time Savings: Manual testing → Automated E2E Result: Reliable, maintainable tests Traditional: 2-4 hours AgentShelf: 30 minutes Improvement: 85% #### Key Features - E2E Testing: Write comprehensive end-to-end tests - Web Scraping: Extract data from any website - Task Automation: Automate repetitive browser tasks - Cross-browser: Test on Chrome, Firefox, Safari ### Campaign Analyzer - Route: https://agentshelf.ai/discover/campaign-analyzer - Category: marketing - Featured: No - Pricing: Freemium - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-06-24T18:58:23.063Z - Tags: campaign-analytics, marketing-analytics, roas, cpa, funnel, reporting, attribution, dashboards Tagline: Understand what worked. Decide what to change. Short Description: Helps marketing teams understand campaign performance across channels, audiences, creatives, offers, landing pages, funnels, and CRM outcomes Compare campaign results across channels, explain performance changes, and prioritize next steps. Check metric definitions and tracking gaps before drawing conclusions. Perfect For: Marketing teams, analysts, and agencies. Time Savings: Illustrative estimate: 58% less time for one campaign performance report. Result: A performance summary with recommended next steps. Traditional: 180 minutes (estimated) AgentShelf: 75 minutes (estimated) Improvement: 58% #### Key Features - Campaign reports: Summarize results by channel, audience, creative, and funnel stage. - Metric checks: Align dates, currencies, and conversion definitions before comparing results. - Attribution review: Flag missing data, duplicate conversions, and limits in attribution. - Next steps: Recommend budget changes, creative tests, and tracking fixes in priority order. ### Canvas Designer - Route: https://agentshelf.ai/discover/canvas-designer - Category: design - Featured: No - Pricing: Freemium - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.6 - Rating Count: 124 - Installs: 0 - Created At: 2025-12-06T01:03:42.558Z Tagline: Create museum-quality visual art and designs in PDF and PNG formats. Short Description: Create museum-quality visual art and designs in PDF and PNG formats. The Canvas Designer creates sophisticated visual compositions for designers, artists, and marketing professionals. Apply design philosophy principles to craft original artwork with meticulous attention to form, space, color, and composition. Output publication-ready PDF and PNG files. **Key Capabilities:** - Design philosophy-driven creation - Canvas rendering with Python PIL/Pillow - PDF and PNG output formats - Access to 70+ professional fonts - Sophisticated visual composition tools **Tools & Integrations:** - Canvas Renderer (Python) - High-quality image generation and manipulation — Pillow - Professional Font Library (Assets) - 70+ curated typefaces for design work - Export Engine (Python) - Output to PDF and PNG with print-ready quality Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### ChEMBL Drug Discovery Agent - Route: https://agentshelf.ai/discover/chembl-drug-discovery-agent - Category: scientific_research - Featured: No - Pricing: Freemium - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 28 - Installs: 0 - Created At: 2025-12-06T01:03:45.283Z Tagline: Query 2M+ bioactive molecules and 19M+ bioactivity measurements for drug discovery. Short Description: Query 2M+ bioactive molecules and 19M+ bioactivity measurements for drug discovery. The ChEMBL Agent provides access to the ChEMBL database for medicinal chemists and drug discovery researchers. Search compounds by name, structure, or properties, retrieve bioactivity data (IC50, Ki, EC50), find target inhibitors, and perform structure-activity relationship (SAR) studies. **Key Capabilities:** - Compound search by name, structure, or properties - Target information and bioactivity data - Similarity and substructure searches - Drug information and mechanisms - IC50, Ki, EC50 activity data **Database Connections:** - ChEMBL Database (Python) - 2M+ bioactive molecules with activity data — ebi.ac.uk/chembl - Compound Search (Python) - Find molecules by name, structure, or properties — chembl_webresource_client - Bioactivity Browser (Python) - Access 19M+ IC50, Ki, EC50 measurements - Target Finder (Python) - Identify inhibitors and modulators for proteins Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Classification Agent - Route: https://agentshelf.ai/discover/classification-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 31 - Installs: 0 - Created At: 2025-12-08T19:08:41.363Z Tagline: Classify content into categories using LLM for intent detection and entity typing. Short Description: Classify content into categories using LLM for intent detection and entity typing. The Classification Agent classifies content into predefined categories using LLM capabilities. Supports multi-class, multi-label, and hierarchical classification with confidence scoring and zero-shot learning. **Key Capabilities:** - Multi-class classification - Multi-label classification - Confidence scoring - Hierarchical classification - Zero-shot classification - Batch classification **Tools & Integrations:** - Claude API - Zero-shot and few-shot classification - Schema Manager - Category definitions - Confidence Scorer - Classification quality Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### ClinicalTrials.gov Agent - Route: https://agentshelf.ai/discover/clinicaltrialsgov-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.8 - Rating Count: 39 - Installs: 0 - Created At: 2025-12-06T01:03:45.402Z Tagline: Search clinical trials by condition, drug, location, or phase for research and patient matching. Short Description: Search clinical trials by condition, drug, location, or phase for research and patient matching. The ClinicalTrials.gov Agent searches the comprehensive clinical trial registry for clinical researchers, patient advocates, and drug developers. Find recruiting trials, retrieve study details by NCT ID, filter by phase or status, and export data for analysis. **Key Capabilities:** - Search by condition, intervention, or location - Filter by trial status and phase - Retrieve detailed study information - Eligibility criteria extraction - Contact information and site locations - Data export to CSV **Database Connections:** - ClinicalTrials.gov Registry (REST API v2) - Comprehensive clinical trial database — clinicaltrials.gov - Trial Search (REST API) - Find studies by condition, drug, or location — ClinicalTrials.gov API - Study Details (REST API) - Retrieve eligibility, contacts, and site information - Data Exporter (CSV) - Download trial data to CSV for analysis Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### ClinPGx Pharmacogenomics Agent - Route: https://agentshelf.ai/discover/clinpgx-pharmacogenomics-agent - Category: scientific_research - Featured: No - Pricing: Freemium - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.9 - Rating Count: 18 - Installs: 0 - Created At: 2025-12-06T01:03:45.521Z Tagline: Access gene-drug interactions and CPIC guidelines for precision medicine decisions. Short Description: Access gene-drug interactions and CPIC guidelines for precision medicine decisions. The ClinPGx Agent provides clinical pharmacogenomics information for pharmacists, clinicians, and precision medicine researchers. Query gene-drug interactions, access CPIC guidelines, retrieve allele function data, and support genotype-guided dosing decisions. **Key Capabilities:** - Gene-drug pair queries - CPIC guideline access - Allele function and frequency data - Drug label pharmacogenomics information - Phenotype prediction support **Database Connections:** - ClinPGx Database (REST API) - Clinical pharmacogenomics information - Gene-Drug Lookup (REST API) - Query interactions between genes and medications - CPIC Guidelines (REST API) - Access evidence-based dosing recommendations — cpicpgx.org - Allele Interpreter (Python) - Translate genetic variants to phenotypes — PharmCAT Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Co-Investor Discovery Agent - Route: https://agentshelf.ai/discover/co-investor-discovery-agent - Category: data_analysis - Featured: No - Pricing: Paid - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 23 - Installs: 0 - Created At: 2025-12-08T19:08:41.209Z Tagline: Identify co-investment patterns among VC/PE firms and build investor relationship networks. Short Description: Identify co-investment patterns among VC/PE firms and build investor relationship networks. The Co-Investor Discovery Agent identifies co-investment patterns among VC/PE firms for deal sourcing. Analyzes funding rounds, detects frequent co-investment pairs, and scores potential introductions. **Key Capabilities:** - Co-investment analysis - Pattern detection (frequent pairs) - Network mapping (investor relationships) - Lead scoring for introductions - Deal flow analysis - Sector focus identification **Tools & Integrations:** - Crunchbase Data - Funding round analysis - Network Mapper - Relationship graphing - Lead Scorer - Introduction prioritization Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Company Brand Context Builder - Route: https://agentshelf.ai/discover/company-brand-context-builder - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 1 - Created At: 2026-09-15T00:52:12.327Z - Tags: brand-context, brand-strategy, positioning, audience, voice-and-style, claims-governance, knowledge-synthesis, marketing-operations Tagline: Keep your brand knowledge in one place. Short Description: Helps turn decentralized, organization-approved material into a coherent, traceable brand context package for people and downstream AgentShelf agents Turn company documents into five reusable brand guides covering the business, audience, claims, voice, and commercial rules. Keep sources attached and flag conflicting information for review. You approve and upload the drafts. Perfect For: Brand teams, marketing leaders, and agencies. Time Savings: Illustrative estimate: 63% less time for one company brand context draft. Result: Five brand guides with sources and questions for review. Traditional: 240 minutes (estimated) AgentShelf: 90 minutes (estimated) Improvement: 63% #### Key Features - Source review: Organize approved documents and identify outdated or missing information. - Consistency checks: Flag conflicting claims and separate confirmed facts from assumptions. - Brand guides: Draft five guides covering company context, audience, claims, voice, and commercial rules. - Review notes: List open questions, changes, and decisions that need approval. ### Competitive Marketing Analyst - Route: https://agentshelf.ai/discover/competitive-marketing-analyst - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 2 - Created At: 2026-09-15T00:52:20.644Z - Tags: competitive-intelligence, competitor-analysis, market-research, positioning, pricing-research, public-ads, review-analysis, product-marketing Tagline: Know your competitors. Find your opening. Short Description: Helps turn public or explicitly authorized competitor evidence into decision-ready marketing intelligence. Compare competitor messaging, pricing, offers, and customer reviews using public and approved sources. Get sourced profiles and ideas to test, with facts and assumptions clearly marked. Perfect For: Product marketers, founders, and research teams. Time Savings: Illustrative estimate: 60% less time for one three-competitor comparison. Result: Competitor profiles and opportunities to test. Traditional: 300 minutes (estimated) AgentShelf: 120 minutes (estimated) Improvement: 60% #### Key Features - Competitor research: Review websites, pricing, ads, reviews, and product updates. - Sourced profiles: Build competitor profiles with dated sources and clearly marked assumptions. - Market comparison: Compare strengths, messaging, and customer complaints across competitors. - Opportunity checks: Assess potential openings against customer demand, your capabilities, and contrary evidence. ### Content Extractor Agent - Route: https://agentshelf.ai/discover/content-extractor-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.6 - Rating Count: 31 - Installs: 0 - Created At: 2025-12-08T19:08:40.972Z Tagline: Extract structured data from HTML including tables, contact info, prices, and dates. Short Description: Extract structured data from HTML including tables, contact info, prices, and dates. The Content Extractor Agent extracts structured data from HTML content. Parses tables to JSON, extracts contact information (emails, phones), pricing data, and dates with pattern matching. **Key Capabilities:** - Pattern extraction (CSS selectors, XPath, regex) - Table parsing to JSON - List extraction - Contact extraction (emails, phones, addresses) - Price extraction - Date extraction and normalization - Entity recognition **Tools & Integrations:** - HTML Parser - DOM traversal and extraction - Pattern Matcher - Regex and selector matching - Entity Extractor - Named entity recognition Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Context Analyzer Agent - Route: https://agentshelf.ai/discover/context-analyzer-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.7 - Rating Count: 25 - Installs: 0 - Created At: 2025-12-08T19:08:41.294Z Tagline: Analyze context relevance and quality before LLM operations to optimize token usage. Short Description: Analyze context relevance and quality before LLM operations to optimize token usage. The Context Analyzer Agent analyzes context relevance, completeness, and quality before LLM operations. Scores context items, identifies gaps, prunes irrelevant content, and optimizes for token efficiency. **Key Capabilities:** - Relevance scoring for context items - Completeness checking - Quality assessment - Context pruning - Gap identification - Recommendation generation **Tools & Integrations:** - Claude API - Advanced relevance scoring - Token Counter - Token budget management - Quality Scorer - Context quality metrics Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Conversation Manager Agent - Route: https://agentshelf.ai/discover/conversation-manager-agent - Category: development - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.7 - Rating Count: 27 - Installs: 0 - Created At: 2025-12-08T19:08:41.805Z Tagline: Manage multi-turn conversations with session state, context windowing, and checkpoints. Short Description: Manage multi-turn conversations with session state, context windowing, and checkpoints. The Conversation Manager Agent manages multi-turn conversations with Claude. Handles session state, context windowing, message history, summary injection for long conversations, and checkpoint/branch support. **Key Capabilities:** - Session management - Message history tracking - Context windowing - State persistence - Summary injection - Turn management and branching **Tools & Integrations:** - Session Manager - Conversation state - Token Manager - Context window management - Checkpoint System - Conversation branching Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Conversion Rate Optimizer - Route: https://agentshelf.ai/discover/conversion-rate-optimizer - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 1 - Created At: 2026-06-25T00:32:51.612Z - Tags: cro, ab-testing, landing-pages, funnel, forms, analytics, experimentation, conversion Tagline: Find what stops visitors from converting. Short Description: Help marketing and growth teams improve conversion rates through evidence-based page audits, funnel diagnostics, instrumentation review, experiment planning, and practical UX recommendations Help marketing and growth teams improve conversion rates through evidence-based page audits, funnel diagnostics, instrumentation review, experiment planning, and practical UX recommendations Perfect For: Growth teams, web teams, and conversion specialists. Time Savings: Illustrative estimate: 56% less time for one landing-page conversion audit. Result: Prioritized fixes and experiment plans. Traditional: 240 minutes (estimated) AgentShelf: 105 minutes (estimated) Improvement: 56% #### Key Features - Page and funnel audits: Find confusing copy, weak proof, form problems, and barriers to conversion. - Experiment plans: Define what to test, who to include, and how to judge the result. - Tracking review: Check conversion events and identify gaps in analytics and measurement. - Fix priorities: Rank improvements by likely impact, evidence, effort, and risk. ### Crunchbase API Agent - Route: https://agentshelf.ai/discover/crunchbase-api-agent - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.6 - Rating Count: 45 - Installs: 0 - Created At: 2025-12-08T19:08:40.172Z Tagline: Retrieve company profiles, funding rounds, and investor data from Crunchbase API. Short Description: Retrieve company profiles, funding rounds, and investor data from Crunchbase API. The Crunchbase API Agent retrieves company profiles, funding rounds, and investor data for investment research and sales intelligence. Query organizations by name or domain, get funding history, and discover investors. **Key Capabilities:** - Organization lookup by name/domain - Funding data retrieval - Investor research - People search at organizations - News and events **Tools & Integrations:** - Crunchbase API - Company and funding data - Organization Mapper - Maps to Salesforce Account - Rate Limiter - Manages API quotas Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Crunchbase Web Scraper - Route: https://agentshelf.ai/discover/crunchbase-web-scraper - Category: data_analysis - Featured: No - Pricing: Paid - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.5 - Rating Count: 33 - Installs: 0 - Created At: 2025-12-08T19:08:40.816Z Tagline: Extract company, funding, and investor data from Crunchbase as fallback to API access. Short Description: Extract company, funding, and investor data from Crunchbase as fallback to API access. The Crunchbase Scraper Agent extracts company, funding, and investor data from Crunchbase web pages. Serves as a fallback to API access with rate limiting and proxy rotation. **Key Capabilities:** - Company profile scraping - Funding round extraction - Investor profile scraping - People data extraction - Search result parsing - Rate management (200/day, 50/hour) **Tools & Integrations:** - Crunchbase Scraper - Web page extraction - Proxy Manager - IP rotation - Rate Limiter - Crunchbase-specific limits Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Customer Growth & Renewal Advisor - Route: https://agentshelf.ai/discover/customer-growth-renewal-advisor - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:48:46.171Z - Tags: customer-growth, customer-health, renewals, qbr, value-realization, expansion, account-planning Tagline: Turn customer evidence into the next growth decision. Short Description: Evaluates customer relationship health, renewal exposure, and expansion hypotheses to prepare evidence-backed QBRs and retention plans. Assess customer health, prepare outcome-led QBRs, reconcile renewal timing, and surface expansion hypotheses from verified value and relationship evidence. Contract limits, unknowns, and existing coverage stay visible. Perfect For: Customer success, account, and renewal teams. Time Savings: Illustrative estimate: 56% less time for one customer decision plan. Result: A customer decision plan grounded in value and commercial evidence. Traditional: 240 minutes (estimated) AgentShelf: 105 minutes (estimated) Improvement: 56% #### Key Features - Health reviews: Assess relationship, engagement, commercial, support, and value delivery separately with strengths and coverage limits. - QBR preparation: Build an outcome-led agenda with customer decisions, evidenced adoption, prior commitments, attendees, and internal watch items. - Renewal action plans: Reconcile agreement, notice, cancellation, and forecast dates and work backward through owner and customer milestones. - Expansion hypotheses: Map product, team, geography, and volume opportunities to customer need, approved capability, access, and existing coverage. ### Customer Support Tier 1 - Route: https://agentshelf.ai/discover/customer-support-tier1 - Category: customer_support - Featured: Yes - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.8 - Rating Count: 142 - Installs: 0 - Created At: 2025-12-30T18:39:28.846Z - Tags: Customer Support, Chatbot, Helpdesk, Ticketing, 24/7, Automation, Live Chat - Integrations: Zendesk, Intercom, Help Centers Tagline: First line of defense, always on Short Description: Your always-on first line of defense. Answers common questions 24/7 via chat, tickets, and help centers—escalates complex issues to humans. Deploy in hours, scales to any volume. Your always-on first line of defense. Answers common questions 24/7 via chat, tickets, and help centers—escalates complex issues to humans. Deploy in hours, scales to any volume. Perfect For: Support Teams Time Savings: 24/7 instant responses Result: Deploy in hours, scales instantly Traditional: 5-15 min AgentShelf: < 3 seconds Improvement: Instant #### Key Features - 24/7 Chat Support: Greets and assists customers around the clock without delays - Zendesk Integration: Creates and updates tickets, accesses knowledge base - Intercom Connect: Seamless handoff in live chat conversations - Smart Escalation: Routes complex issues to human agents with full context ### Data Extraction Agent - Route: https://agentshelf.ai/discover/data-extraction-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.9 - Rating Count: 36 - Installs: 0 - Created At: 2025-12-08T19:08:41.462Z Tagline: Extract structured data from unstructured text with schema validation and confidence scoring. Short Description: Extract structured data from unstructured text with schema validation and confidence scoring. The Data Extraction Agent extracts structured data from unstructured text using LLM capabilities. Supports entity extraction, schema-based extraction, multi-document aggregation, and confidence scoring. **Key Capabilities:** - Entity extraction (people, companies, locations) - Field extraction from text - Relationship extraction - Schema-based extraction - Multi-document extraction - Confidence scoring **Tools & Integrations:** - Claude API - Structured data extraction - Schema Validator - Output validation - Confidence Scorer - Extraction quality Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Data Validator Agent - Route: https://agentshelf.ai/discover/data-validator-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 42 - Installs: 0 - Created At: 2025-12-08T19:08:40.262Z Tagline: Validate and standardize data quality with format checks and quality scoring. Short Description: Validate and standardize data quality with format checks and quality scoring. The Data Validator Agent ensures data quality before CRM import. Validates email formats, phone numbers, URLs, standardizes industries and locations, and provides quality scores to filter low-quality records. **Key Capabilities:** - Format validation (email, phone, URL) - Data standardization (stages, industries, locations) - Quality scoring with configurable weights - Data cleansing - Threshold checking **Tools & Integrations:** - Validation Rules Engine - Configurable validation rules - Quality Scorer - Weighted quality metrics - Data Cleanser - Standardization functions Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Data Visualization Specialist - Route: https://agentshelf.ai/discover/data-visualization - Category: data_analysis - Featured: No - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.7 - Rating Count: 64 - Installs: 0 - Created At: 2025-12-30T18:39:28.962Z - Tags: Data Visualization, D3.js, SVG, Interactive, Charts, Dashboards Tagline: Data stories that captivate Short Description: Create interactive data visualizations with D3.js charts and network graphs. Transform your data into stunning visualizations. Create interactive charts, network graphs, dashboards, and infographics that tell compelling stories. Perfect For: Data Teams Time Savings: Days of design → Hours Result: Interactive, publication-ready visuals Traditional: 2-3 days AgentShelf: 2 hours Improvement: 90% #### Key Features - Interactive Charts: Build D3.js and Chart.js visualizations - Network Graphs: Visualize relationships and connections - Dashboards: Create comprehensive data dashboards - Export Options: Export to SVG, PNG, or embed code ### Data Visualization Specialist - Route: https://agentshelf.ai/discover/data-visualization-specialist - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 178 - Installs: 0 - Created At: 2025-12-06T01:03:43.361Z - Tags: Data Visualization, D3.js, SVG, Interactive, Charts, Dashboards Tagline: Data stories that captivate Short Description: Create interactive data visualizations with D3.js charts and network diagrams. The Data Visualization Specialist creates publication-quality interactive visualizations for data analysts, researchers, and business intelligence teams. Build custom charts, network diagrams, geographic maps, and novel visualization types with smooth transitions and user interactions. **Key Capabilities:** - Custom visual encodings and chart types - Interactive exploration with zoom, pan, and tooltips - Network and graph visualizations - Geographic maps with custom projections - Smooth choreographed transitions **Tools & Integrations:** - Chart Builder (JavaScript) - Create bar, line, scatter, pie, and custom chart types — D3.js - Network Visualizer (JavaScript) - Build force-directed graphs and relationship diagrams — D3.js - Map Generator (JavaScript) - Create geographic visualizations with custom projections — D3.js - Animation Engine (JavaScript) - Add smooth transitions and interactive behaviors Perfect For: Data Teams Time Savings: Days of design → Hours Result: Interactive, publication-ready visuals Traditional: 2-3 days AgentShelf: 2 hours Improvement: 90% #### Key Features - Interactive Charts: Build D3.js and Chart.js visualizations - Network Graphs: Visualize relationships and connections - Dashboards: Create comprehensive data dashboards - Export Options: Export to SVG, PNG, or embed code ### Deal Strategy & Proposal Advisor - Route: https://agentshelf.ai/discover/deal-strategy-proposal-advisor - Category: crm - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:49:28.151Z - Tags: deal-strategy, qualification, close-planning, business-case, proposal, sales, crm Tagline: Turn deal uncertainty into an evidence-backed next step. Short Description: Evaluates sales opportunities, identifies advancement gaps, and drafts evidence-backed mutual action plans, business cases, and proposals. Deal Strategy & Proposal Advisor helps sellers review one opportunity, test stage and qualification evidence, find the first consequential gap, and build a credible dependency-based path to the next buyer decision. It drafts close plans, business cases, and opportunity-specific proposals while keeping seller targets, customer agreement, unsupported value assumptions, and record changes separate. Perfect For: Account executives, deal teams, sales leaders, and proposal owners. Time Savings: Illustrative estimate: 60% less time for one deal strategy brief. Result: A source-linked deal assessment with a practical next-decision plan. Traditional: 300 minutes (estimated) AgentShelf: 120 minutes (estimated) Improvement: 60% #### Key Features - Deal Health Review: Compare recorded stage and forecast fields with qualification, stakeholder, buyer-process, and activity evidence. - Advancement Gaps: Find the first binding qualification or buyer-process gap and sequence validating actions by owner and dependency. - Close Plans And Business Cases: Map buyer outcomes, costs, dependencies, alternatives, assumptions, and conditional dates into a proposed path to decision. - Proposal And Update Handoffs: Draft claims-safe opportunity content and exact, authorization-aware field change sets without claiming a send, save, or update. ### Deduplication Agent - Route: https://agentshelf.ai/discover/deduplication-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.7 - Rating Count: 38 - Installs: 0 - Created At: 2025-12-08T19:08:40.337Z Tagline: Identify and manage duplicate records using email, LinkedIn, phone, and fuzzy name matching. Short Description: Identify and manage duplicate records using email, LinkedIn, phone, and fuzzy name matching. The Deduplication Agent identifies and manages duplicate records in your CRM. Uses email, LinkedIn URL, phone number, and fuzzy name matching to find duplicates, scores match confidence, and recommends merge actions. **Key Capabilities:** - Find duplicates by email, LinkedIn, phone - Confidence scoring for matches - Merge recommendations - Batch processing - Duplicate tracking **Tools & Integrations:** - Matching Engine - Multi-field duplicate detection - Confidence Scorer - Match quality scoring - Merge Recommender - Automated recommendations Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Digital Advertising Manager - Route: https://agentshelf.ai/discover/digital-advertising-manager - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-06-24T18:58:18.212Z - Tags: paid-ads, google-ads, meta-ads, linkedin-ads, ppc, utm, campaigns, marketing-ops Tagline: Plan your next paid campaign. Short Description: Helps marketing teams plan, launch, analyze, and improve paid search, paid social, display, retargeting, and campaign tracking programs Draft campaign plans, ad copy, budgets, and tracking requirements. Review performance and choose what to test next. Live account changes require your confirmation. Perfect For: Paid media teams, growth marketers, and agencies. Time Savings: Illustrative estimate: 63% less time for one single-channel campaign plan. Result: Campaign plans, ad drafts, and tracking requirements. Traditional: 240 minutes (estimated) AgentShelf: 60 minutes (estimated) Improvement: 75% #### Key Features - Campaign plans: Organize audiences, keywords, ad groups, budgets, and landing pages. - Ad copy and tests: Draft ad variants using approved claims and plan creative tests. - Campaign tracking: Define tracking links, conversion events, and reporting checks. - Performance review: Review spend and returns, then suggest budget, creative, and targeting changes. ### Discovery & Meeting Copilot - Route: https://agentshelf.ai/discover/discovery-meeting-copilot - Category: crm - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:49:22.415Z - Tags: discovery, meetings, call-summary, follow-up, commitments, sales, crm Tagline: Turn customer conversations into clear next decisions. Short Description: Prepares customer meeting briefs, extracts verified conversation evidence, and drafts structured follow-ups and handoffs. Discovery & Meeting Copilot helps sales teams prepare for customer conversations, summarize substantive call evidence, preserve decisions and commitments, and draft accurate follow-up. It keeps tentative dates, customer statements, internal deal questions, future bookings, completed activity logs, and sent messages separate so the next decision is easy to review. Perfect For: Account executives, sales development teams, and customer-facing operators. Time Savings: Illustrative estimate: 58% less time for one discovery meeting workflow. Result: A sourced meeting brief, recap, and clear next-action handoff. Traditional: 180 minutes (estimated) AgentShelf: 75 minutes (estimated) Improvement: 58% #### Key Features - Meeting Preparation: Build objective-led briefs with attendee context, open threads, and discovery questions grounded in available evidence. - Conversation Recaps: Extract sourced decisions, questions, objections, and customer statements from complete or partial transcripts without filling gaps. - Commitment Registers: Separate discussion, tentative ideas, proposed actions, agreed owners and dates, and evidence of completion. - Grounded Follow-up: Draft customer and internal follow-up separately, then hand off future scheduling or completed logging with exact status checks. ### Document Specialist - Route: https://agentshelf.ai/discover/document-specialist - Category: productivity - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: Yes - Rating: 4.6 - Rating Count: 82 - Installs: 0 - Created At: 2025-12-06T01:03:41.790Z - Tags: DOCX, Word, Editing, Professional, Templates, Writing Tagline: Professional documents, effortlessly Short Description: Create, edit, and analyze Word documents with tracked changes and formatting. The Document Specialist enables comprehensive DOCX file manipulation for business professionals, legal teams, and content creators. Create new documents from scratch with precise formatting, edit existing documents while preserving structure, and analyze document contents with full metadata access. **Key Capabilities:** - Create documents using docx-js with paragraphs, tables, images, and styling - Edit documents via OOXML manipulation with formatting preservation - Track changes workflow for collaborative document review - Comment management and revision history - Text extraction with pandoc for analysis **Tools & Integrations:** - Word Document Creator (JavaScript) - Build new documents with paragraphs, tables, images, and styling - Document Editor (Python/OOXML) - Edit existing files while preserving formatting and structure - Text Extractor (CLI) - Extract plain text content for analysis and processing — pandoc.org - PDF Converter (CLI) - Convert documents to PDF with advanced formatting options — LibreOffice Perfect For: Content Teams Time Savings: Hours of editing → Minutes Result: Professional docs, every time Traditional: 1-2 hours AgentShelf: 15 minutes Improvement: 85% #### Key Features - Document Creation: Generate documents from templates - Track Changes: Edit with full revision history - Formatting: Apply consistent professional styling - Content Analysis: Analyze and summarize documents ### Enrichment Pipeline Agent - Route: https://agentshelf.ai/discover/enrichment-pipeline-agent - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.9 - Rating Count: 41 - Installs: 0 - Created At: 2025-12-08T19:08:40.642Z Tagline: Orchestrate complete enrichment workflows coordinating query, validation, enrichment, and CRM updates. Short Description: Orchestrate complete enrichment workflows coordinating query, validation, enrichment, and CRM updates. The Enrichment Pipeline Agent orchestrates complete enrichment workflows from start to finish. Coordinates multiple agents through query, validation, enrichment, merge, and Salesforce update stages with error recovery. **Key Capabilities:** - Pipeline orchestration - Multi-agent coordination - Stage management - Error recovery - Checkpoint/resume - Audit trail **Tools & Integrations:** - Pipeline Orchestrator - Stage sequencing - Agent Coordinator - Multi-agent management - Recovery Manager - Error handling and retry Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Field Mapper Agent - Route: https://agentshelf.ai/discover/field-mapper-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.6 - Rating Count: 31 - Installs: 0 - Created At: 2025-12-08T19:08:40.405Z Tagline: Map fields between external data sources and Salesforce with transformation rules. Short Description: Map fields between external data sources and Salesforce with transformation rules. The Field Mapper Agent maps fields between external data sources and Salesforce objects. Supports transformation rules (capitalize, normalize phone to E.164, etc.), multi-source merging, and dynamic field mapping. **Key Capabilities:** - Source-to-target field mapping - Transformation rules (capitalize, normalize, e164) - Multi-source merging - Dynamic mapping configuration - Validation integration **Tools & Integrations:** - Field Mapping Engine - Configurable mappings - Transformer Library - Data transformation functions - Schema Validator - Target schema validation Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Generative Artist - Route: https://agentshelf.ai/discover/generative-artist - Category: design - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.5 - Rating Count: 89 - Installs: 0 - Created At: 2025-12-06T01:03:43.203Z Tagline: Create algorithmic art using p5.js with flow fields and particle systems. Short Description: Create algorithmic art using p5.js with flow fields and particle systems. The Generative Artist creates computational aesthetic movements expressed through code for digital artists and creative coders. Build unique algorithmic art pieces using seeded randomness, Perlin noise, flow fields, and particle systems with interactive parameter exploration. **Key Capabilities:** - Seeded randomness for reproducible art - Perlin noise and flow field generation - Particle systems and organic simulations - Interactive parameter controls - Single HTML artifact with CDN-based p5.js **Tools & Integrations:** - Creative Coding Engine (JavaScript) - Generate algorithmic art with p5.js framework — p5js.org - Noise Generator (JavaScript) - Create organic patterns with Perlin noise algorithms - Interactive Canvas (HTML/JavaScript) - Browser-based rendering with real-time controls Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### GEO Gene Expression Agent - Route: https://agentshelf.ai/discover/geo-gene-expression-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.7 - Rating Count: 34 - Installs: 0 - Created At: 2025-12-06T01:03:45.631Z Tagline: Search and download gene expression datasets from NCBI GEO for transcriptomics. Short Description: Search and download gene expression datasets from NCBI GEO for transcriptomics. The GEO Agent provides access to NCBI's Gene Expression Omnibus for bioinformaticians and transcriptomics researchers. Search 264,000+ studies and 8M+ samples, download microarray and RNA-seq datasets, retrieve SOFT/Matrix files, and perform expression analysis. **Key Capabilities:** - Dataset search by keywords or organism - Expression data retrieval (GSE, GSM, GPL) - SOFT and Matrix file downloads - Platform annotation access - Batch processing multiple datasets **Database Connections:** - GEO Database (NCBI) - 264,000+ gene expression studies, 8M+ samples — ncbi.nlm.nih.gov/geo - Dataset Search (Python) - Find studies by keyword, organism, or platform — GEOparse - Expression Downloader (FTP) - Retrieve SOFT and Matrix data files - Batch Processor (Python) - Analyze multiple datasets in parallel Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### GIF Animator - Route: https://agentshelf.ai/discover/gif-animator - Category: design - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.8 - Rating Count: 167 - Installs: 0 - Created At: 2025-12-06T01:03:43.043Z Tagline: Create optimized animated GIFs for Slack and social media platforms. Short Description: Create optimized animated GIFs for Slack and social media platforms. The GIF Animator creates eye-catching animated GIFs optimized for communication platforms. Build animations using composable primitives with automatic validation for platform constraints (Slack emoji: 64KB, messages: ~2MB). Perfect for team communications and social content. **Key Capabilities:** - Composable animation primitives (shake, bounce, spin, pulse, fade, zoom) - Platform-specific size validation - Color quantization for optimal file size - Text rendering and visual effects - Particle, flash, and shockwave effects **Tools & Integrations:** - Animation Builder (Python) - Create and optimize animated GIF sequences — Pillow, imageio - Size Optimizer (Python) - Compress animations for platform requirements - Video Converter (CLI) - Transform video clips into animated GIFs — ffmpeg Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### GWAS Catalog Agent - Route: https://agentshelf.ai/discover/gwas-catalog-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 24 - Installs: 0 - Created At: 2025-12-06T01:03:45.762Z Tagline: Query SNP-trait associations for genetic epidemiology and polygenic risk studies. Short Description: Query SNP-trait associations for genetic epidemiology and polygenic risk studies. The GWAS Catalog Agent provides access to the NHGRI-EBI GWAS Catalog for genetic epidemiologists and human genetics researchers. Search variants by rs ID, query disease/trait associations, retrieve p-values and effect sizes, and access full summary statistics for polygenic risk score development. **Key Capabilities:** - Variant search by rs ID or region - Disease/trait association queries - Gene-centric searches - Summary statistics access - Study metadata retrieval **Database Connections:** - GWAS Catalog (REST API) - Curated SNP-trait associations from published studies — ebi.ac.uk/gwas - Variant Lookup (REST API) - Search by rs ID, gene, or chromosomal region - Association Browser (REST API) - Retrieve p-values, effect sizes, and populations - Summary Statistics (FTP) - Access full genome-wide results for PRS studies Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### HMDB Metabolome Agent - Route: https://agentshelf.ai/discover/hmdb-metabolome-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.6 - Rating Count: 21 - Installs: 0 - Created At: 2025-12-06T01:03:45.875Z Tagline: Access 220K+ human metabolites with chemical properties and biomarker data. Short Description: Access 220K+ human metabolites with chemical properties and biomarker data. The HMDB Agent provides access to the Human Metabolome Database for metabolomics researchers and clinical chemists. Search 220,000+ metabolites by name, structure, or spectral data, retrieve chemical properties, access biomarker associations, and download NMR/MS reference spectra. **Key Capabilities:** - Metabolite search by name or structure - Chemical property retrieval - Biomarker disease associations - NMR and MS spectral data - Pathway and reaction information **Database Connections:** - HMDB Database (Web/XML) - 220,000+ human metabolites — hmdb.ca - Metabolite Search (Web/R) - Find compounds by name, structure, or spectra — hmdbQuery - Biomarker Lookup (XML) - Access disease associations and concentration ranges - Spectra Library (Web) - Reference NMR and MS data for identification Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### iOS Test Automation Engineer - Route: https://agentshelf.ai/discover/ios-test-automation-engineer - Category: development - Featured: No - Pricing: Freemium - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.9 - Rating Count: 67 - Installs: 0 - Created At: 2025-12-06T01:03:44.102Z Tagline: Comprehensive iOS testing with 21 production scripts for UI and accessibility. Short Description: Comprehensive iOS testing with 21 production scripts for UI and accessibility. The iOS Test Automation Engineer provides complete iOS app testing capabilities for mobile developers and QA teams. Access 21 production-ready Python scripts for UI automation, accessibility testing, screenshot comparison, and simulator management using semantic UI navigation. **Key Capabilities:** - 21 production Python scripts - Build and test automation (Xcode integration) - Semantic element finding and navigation - Accessibility audit and testing - Visual diff and screenshot comparison - Device lifecycle management (boot, shutdown, create, delete) **Tools & Integrations:** - Simulator Controller (Python/CLI) - Boot, shutdown, and manage iOS simulators — simctl - UI Automator (Python) - Tap, swipe, and interact with app elements - Screenshot Comparator (Python) - Visual diff testing for UI changes - Accessibility Tester (Python) - Audit apps for iOS accessibility compliance - Build Runner (CLI) - Compile and install apps via Xcode integration — xcrun Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### KEGG Pathway Agent - Route: https://agentshelf.ai/discover/kegg-pathway-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.7 - Rating Count: 33 - Installs: 0 - Created At: 2025-12-06T01:03:45.981Z Tagline: Analyze biological pathways and gene-pathway mappings across organisms. Short Description: Analyze biological pathways and gene-pathway mappings across organisms. The KEGG Agent provides access to the Kyoto Encyclopedia of Genes and Genomes for systems biologists and pathway analysts. Query metabolic pathways, map genes to pathways, retrieve compound and enzyme data, convert between database identifiers, and analyze cross-organism pathway conservation. Academic use only. **Key Capabilities:** - Pathway listing and retrieval - Gene-pathway mapping - Compound and enzyme queries - ID conversion (NCBI, UniProt, PubChem) - Cross-organism pathway comparison - Drug-drug interaction checking **Database Connections:** - KEGG Database (REST API) - Comprehensive pathway and gene encyclopedia — kegg.jp - Pathway Browser (REST API) - Explore metabolic and signaling pathways - Gene Mapper (REST API) - Link genes to pathways across organisms - ID Converter (REST API) - Translate between KEGG, NCBI, UniProt, and PubChem - Drug Interaction Checker (REST API) - Identify potential drug-drug interactions Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Knowledge Base Agent - Route: https://agentshelf.ai/discover/knowledge-base - Category: productivity - Featured: Yes - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.6 - Rating Count: 124 - Installs: 0 - Created At: 2025-12-30T18:39:28.893Z - Tags: Knowledge Management, Documentation, Notion, Confluence, SharePoint, Search, Productivity - Integrations: Notion, Google Drive, Confluence Tagline: Tribal knowledge, on demand Short Description: Search and retrieve information from your knowledge bases, wikis, and documentation instantly. Your always-available expert on internal documentation. Connects to Notion, Drive, and Confluence to surface instant, context-aware answers from docs, policies, and playbooks. New hires ramp faster; everyone stops hunting. Perfect For: Operations Time Savings: New hires productive on day one Result: Instant answers, unified search Traditional: 15-30 min AgentShelf: < 1 second Improvement: 98% #### Key Features - Semantic Search: Understands questions in natural language, not just keywords. - Notion Integration: Searches wikis, databases, and team documentation. - Google Drive Access: Indexes shared docs, sheets, and slides. - Confluence Connect: Pulls from spaces, pages, and embedded files. ### Landing Page Builder - Route: https://agentshelf.ai/discover/landing-page-builder - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-06-24T18:58:12.722Z - Tags: landing-pages, cro, copywriting, lead-capture, campaigns, web-design, utm, conversion Tagline: Give your landing page a clear message. Short Description: Helps marketing teams create, improve, and validate landing pages Turn a campaign brief into a page outline, copy, and notes for your designer or developer. Plan the call to action, supporting proof, and tracking before launch. Perfect For: Marketers, web teams, and agencies. Time Savings: Illustrative estimate: 63% less time for one landing-page copy and handoff draft. Result: Page copy and a brief for design and development. Traditional: 240 minutes (estimated) AgentShelf: 30 minutes (estimated) Improvement: 87% #### Key Features - Page structure: Plan sections around the audience, offer, key objections, and call to action. - Page copy: Write headlines, benefits, FAQs, and calls to action using your source material. - Conversion tracking: Define conversion events, tracking links, and checks for launch. - Page review: Check clarity, forms, accessibility, page speed risks, and missing proof. ### Lead Enrichment Agent - Route: https://agentshelf.ai/discover/lead-enrichment - Category: marketing - Featured: Yes - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.7 - Rating Count: 98 - Installs: 0 - Created At: 2025-12-30T18:39:28.866Z - Tags: Sales, Lead Generation, CRM, Salesforce, HubSpot, LinkedIn, Data Enrichment - Integrations: Salesforce, HubSpot, LinkedIn Tagline: Turn leads into qualified prospects Short Description: Automatically enrich leads with company data, contact information, and social signals from multiple sources. Automates prospect research by gathering intelligence from websites, Google, and other public sources—then delivers actionable insights and outreach tactics. Syncs enriched data directly to Salesforce or HubSpot, eliminating manual entry. Perfect For: Sales Teams Time Savings: 30-60 min → seconds per lead Result: Complete lead profiles, verified data Traditional: 30-60 min AgentShelf: < 5 seconds Improvement: 95% #### Key Features - Website Scraping: Extracts key info from prospect company websites - SharePoint Integration: Access internal docs and company knowledge - Intent analysis: Digests findings into actionable recommendations - CRM Auto-Sync: Automatically updates Salesforce or HubSpot with enriched data and notes ### Lead Qualification & Routing Specialist - Route: https://agentshelf.ai/discover/lead-qualification-routing-specialist - Category: crm - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:49:32.895Z - Tags: lead-qualification, lead-routing, ownership, territory-policy, inbound-sales, sales-operations, handoff Tagline: Separate lead fit from ownership with evidence. Short Description: Evaluates inbound leads against ICP and routing policies to produce qualification cards, triage backlogs, and recommend owner assignments. Evaluate inbound leads against supplied criteria, explain readiness and unknowns, apply routing policy in order, and return a traceable owner or queue recommendation. Qualification and assignment remain separate states. Perfect For: Sales operations teams, SDR leaders, and inbound owners. Time Savings: Illustrative estimate: 63% less time for one lead qualification and routing decision. Result: Evidence cards and policy-grounded routing decisions. Traditional: 120 minutes (estimated) AgentShelf: 45 minutes (estimated) Improvement: 63% #### Key Features - Qualification cards: Separate fit, intent, readiness, confidence, and unknown gates for every scoped lead. - Backlog priorities: Rank a finite queue with evidence, ties, first-touch direction, response target, and routing readiness. - Policy routing: Show effective rule precedence, account or territory conflicts, eligible targets, overrides, and missing decisions. - Assignment handoff: Prepare an exact owner change or manual handoff with authorization, concurrency checks, and per-lead readback state. ### Lifecycle Email Strategist - Route: https://agentshelf.ai/discover/lifecycle-email-strategist - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-15T00:52:16.864Z - Tags: lifecycle-email, email-marketing, onboarding, activation, retention, segmentation, deliverability, experimentation Tagline: Write emails for each step of the customer journey. Short Description: Helps marketing, product, growth, and customer teams design, diagnose, and improve permission-aware email programs Plan welcome, onboarding, retention, and win-back sequences. Get complete email drafts, audience rules, and a measurement plan for your team to review and implement. Perfect For: Lifecycle marketers and customer success teams. Time Savings: Illustrative estimate: 60% less time for one five-email welcome sequence. Result: Email sequences with copy, audience rules, and metrics. Traditional: 300 minutes (estimated) AgentShelf: 120 minutes (estimated) Improvement: 60% #### Key Features - Sequence plans: Define who receives each email, what triggers it, and when the sequence ends. - Email drafts: Write subject lines, preview text, body copy, and calls to action. - Sending rules: Specify consent, exclusions, frequency limits, and deliverability checks. - Performance and tests: Choose metrics, diagnose weak points, and plan tests for the sequence. ### LinkedIn Profile Scraper - Route: https://agentshelf.ai/discover/linkedin-profile-scraper - Category: data_analysis - Featured: No - Pricing: Paid - Publisher: John Smith - Publisher Verified: No - Rating: 4.6 - Rating Count: 52 - Installs: 0 - Created At: 2025-12-08T19:08:40.724Z Tagline: Extract profile and company data from LinkedIn with rate limiting and anti-detection measures. Short Description: Extract profile and company data from LinkedIn with rate limiting and anti-detection measures. The LinkedIn Scraper Agent extracts profile and company data from LinkedIn for sales research. Implements rate limiting (30 profiles/hour), anti-detection with user agent rotation, and proxy support. **Key Capabilities:** - Profile scraping with full data extraction - Company page scraping - Search result parsing - Rate management (30 profiles/hour) - Anti-detection (user agent rotation, random delays) - Session management **Tools & Integrations:** - LinkedIn Scraper - Profile and company extraction - Proxy Manager - IP rotation - Rate Limiter - LinkedIn-specific limits Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### MCP Server Builder - Route: https://agentshelf.ai/discover/mcp-server-builder - Category: development - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.9 - Rating Count: 95 - Installs: 0 - Created At: 2025-12-06T01:03:43.671Z Tagline: Build Model Context Protocol servers for LLM-external service integration. Short Description: Build Model Context Protocol servers for LLM-external service integration. The MCP Server Builder helps developers create high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services. Design workflow-centric tools, optimize for limited context windows, and create actionable error messages for real-world agent workflows. **Key Capabilities:** - Workflow-centric tool design - Context-optimized responses - Actionable error messaging - Python and TypeScript support - Tool registration and validation **Tools & Integrations:** - Python Server Builder (Python) - Create MCP servers with Python and type validation — FastMCP, Pydantic - TypeScript Server Builder (TypeScript) - Create MCP servers with Node.js and schema validation — MCP SDK, Zod - Tool Designer (Python/TypeScript) - Define tool interfaces with input/output schemas - Error Handler (Python/TypeScript) - Create actionable error messages for agent workflows Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Meeting Prep Agent - Route: https://agentshelf.ai/discover/meeting-prep - Category: productivity - Featured: Yes - Pricing: Free - Publisher: AgentShelf Team - Publisher Verified: Yes - Rating: 4.9 - Rating Count: 87 - Installs: 0 - Created At: 2025-12-30T18:39:28.879Z - Tags: Productivity, Meetings, Google Workspace, Microsoft 365, Slack, Notion, Time Management - Integrations: Salesforce, SharePoint, OneDrive Tagline: Every rep walks in prepared Short Description: Prepare for meetings instantly by gathering context, summarizing documents, and generating talking points. Creates comprehensive meeting prep briefs by pulling CRM data, account history, and internal resources—then synthesizes everything into one actionable document, generated minutes before the meeting. Perfect For: Sales Teams Time Savings: Hours of prep → generated instantly Result: Complete prep, confident meetings Traditional: 1-2 hours AgentShelf: < 2 minutes Improvement: 97% #### Key Features - CRM Data Pull: Extracts account history, contacts, and deal stage from Salesforce - SharePoint Integration: Accesses sales playbooks, battle cards, and enablement docs - OneDrive Sync: Pulls proposals, decks, and shared collateral from OneDrive - Prep Summary Generation: Creates briefing docs with talking points and action items ### Merge Resolution Agent - Route: https://agentshelf.ai/discover/merge-resolution-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.5 - Rating Count: 24 - Installs: 0 - Created At: 2025-12-08T19:08:40.501Z Tagline: Resolve data conflicts from multiple sources using priority, recency, and completeness strategies. Short Description: Resolve data conflicts from multiple sources using priority, recency, and completeness strategies. The Merge Resolution Agent resolves conflicts when merging data from multiple enrichment sources. Uses configurable strategies including source priority, recency weighting, and completeness scoring to pick the best values. **Key Capabilities:** - Conflict detection - Resolution strategies (most recent, source priority, most complete) - Source priority rules - Recency weighting - Audit trail tracking **Tools & Integrations:** - Conflict Resolver - Multi-strategy resolution - Priority Manager - Source ranking - Audit Logger - Decision tracking Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Metabolomics Workbench Agent - Route: https://agentshelf.ai/discover/metabolomics-workbench-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.6 - Rating Count: 14 - Installs: 0 - Created At: 2025-12-06T01:03:46.102Z Tagline: Access 4,200+ metabolomics studies with RefMet nomenclature and m/z searches. Short Description: Access 4,200+ metabolomics studies with RefMet nomenclature and m/z searches. The Metabolomics Workbench Agent provides access to the NIH-sponsored metabolomics repository for metabolomics researchers and mass spectrometry analysts. Query 4,200+ studies, standardize nomenclature with RefMet, perform m/z searches with ion adduct specification, and retrieve experimental data. **Key Capabilities:** - Study search and metadata retrieval - RefMet nomenclature standardization - m/z mass searches with adduct types - Compound structure downloads - Experimental data export **Database Connections:** - Metabolomics Workbench (REST API) - 4,200+ metabolomics studies — metabolomicsworkbench.org - Study Search (REST API) - Find experiments by metabolite, disease, or method - RefMet Standardizer (REST API) - Normalize metabolite names to standard nomenclature - Mass Search (REST API) - Identify compounds by m/z with ion adduct specification Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### News Aggregator Agent - Route: https://agentshelf.ai/discover/news-aggregator-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.5 - Rating Count: 28 - Installs: 0 - Created At: 2025-12-08T19:08:41.044Z Tagline: Collect and aggregate news articles about companies and people from multiple sources. Short Description: Collect and aggregate news articles about companies and people from multiple sources. The News Aggregator Agent collects and aggregates news articles about companies, people, and topics. Combines multiple sources (Google News, NewsAPI, Bing News), filters by relevance, and builds timelines. **Key Capabilities:** - News search by company/person/topic - Multi-source aggregation - Relevance filtering and ranking - Entity extraction from articles - Timeline building - Alert monitoring **Tools & Integrations:** - Google News API - News search - NewsAPI - Article aggregation - Entity Extractor - Company/person extraction Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Open Targets Drug Discovery Agent - Route: https://agentshelf.ai/discover/open-targets-drug-discovery-agent - Category: scientific_research - Featured: No - Pricing: Freemium - Publisher: John Smith - Publisher Verified: No - Rating: 4.9 - Rating Count: 27 - Installs: 0 - Created At: 2025-12-06T01:03:46.205Z Tagline: Identify therapeutic targets with disease associations, tractability, and safety data. Short Description: Identify therapeutic targets with disease associations, tractability, and safety data. The Open Targets Agent systematically identifies therapeutic drug targets for drug discovery scientists and target biologists. Query target-disease associations, evaluate tractability and safety liabilities, retrieve evidence from genetics and omics data, find known drugs, and prioritize targets for therapeutic development. **Key Capabilities:** - Target-disease association scoring - Tractability assessment (small molecule, antibody, PROTAC) - Safety liability review - Evidence retrieval (7 major evidence types) - Known drug identification - Target prioritization workflows **Database Connections:** - Open Targets Platform (GraphQL) - Integrated drug target discovery resource — platform.opentargets.org - Target Finder (GraphQL) - Search genes and evaluate druggability - Disease Association Scorer (GraphQL) - Rank targets by evidence strength - Drug Browser (GraphQL) - Find approved and clinical-stage therapeutics - Safety Evaluator (GraphQL) - Review toxicity concerns and genetic constraints Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### PDB Protein Structure Agent - Route: https://agentshelf.ai/discover/pdb-protein-structure-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.8 - Rating Count: 47 - Installs: 0 - Created At: 2025-12-06T01:03:46.299Z Tagline: Search and download 200,000+ experimental 3D protein structures from RCSB PDB. Short Description: Search and download 200,000+ experimental 3D protein structures from RCSB PDB. The PDB Agent provides access to the RCSB Protein Data Bank for structural biologists and computational chemists. Search 200,000+ experimentally determined structures by text, sequence, or structural similarity, download coordinates in PDB/mmCIF formats, and retrieve quality metrics for structure-based drug discovery. **Key Capabilities:** - Text and attribute-based searches - Sequence similarity searches - Structure similarity searches - Coordinate file downloads (PDB, mmCIF, BinaryCIF) - Metadata and quality metrics - Batch operations **Database Connections:** - RCSB Protein Data Bank (REST API) - 200,000+ experimental 3D structures — rcsb.org - Structure Search (REST API/Python) - Find proteins by text, sequence, or 3D similarity — rcsb-api - Coordinate Downloader (HTTP) - Retrieve PDB, mmCIF, and BinaryCIF files - Quality Metrics (REST API) - Access resolution, R-factors, and validation reports Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### PDF Specialist - Route: https://agentshelf.ai/discover/pdf-specialist - Category: productivity - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: Yes - Rating: 4.4 - Rating Count: 78 - Installs: 0 - Created At: 2025-12-06T01:03:42.028Z - Tags: PDF, Documents, Analysis, Forms, Extraction Tagline: Master your PDF workflows Short Description: Extract, create, merge, split, and fill PDF documents with precision. The PDF Specialist provides comprehensive PDF manipulation for anyone working with portable documents. Extract text and tables with layout preservation, create new PDFs programmatically, merge multiple documents, split by page ranges, and fill interactive forms. **Key Capabilities:** - Text and table extraction with layout awareness - PDF creation with custom formatting and graphics - Document merging and splitting operations - Form filling and field manipulation - Metadata extraction and modification **Tools & Integrations:** - PDF Merger & Splitter (Python) - Combine or divide PDF documents by page ranges — pypdf - Table & Text Extractor (Python) - Extract content with layout preservation — pdfplumber - PDF Creator (Python) - Generate new PDFs with custom formatting and graphics — ReportLab - Form Filler (Python) - Populate interactive PDF form fields programmatically Perfect For: Office Teams Time Savings: Manual PDF work → Automated Result: Process PDFs in seconds Traditional: 30-60 min AgentShelf: 2 minutes Improvement: 95% #### Key Features - Text Extraction: Extract text and data from any PDF - Merge & Split: Combine or separate PDF documents - Form Filling: Automatically fill PDF forms - PDF Creation: Generate PDFs from templates ### Positioning & Offer Strategist - Route: https://agentshelf.ai/discover/positioning-offer-strategist - Category: marketing - Featured: No - Pricing: Freemium - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-15T00:52:23.782Z - Tags: positioning, offer-strategy, value-proposition, category-design, pricing-research, packaging, product-marketing, market-strategy Tagline: Clarify why customers should choose you. Short Description: Helps make evidence-led choices about which buyers and buying situations to prioritize, which alternatives to contrast, how to frame the product, how to structure the offer, and what pricing research or architecture should follow. Helps make evidence-led choices about which buyers and buying situations to prioritize, which alternatives to contrast, how to frame the product, how to structure the offer, and what pricing research or architecture should follow. Perfect For: Founders, product marketers, and commercial teams. Time Savings: Illustrative estimate: 50% less time for one positioning and offer decision brief. Result: Positioning options and a plan to test them. Traditional: 360 minutes (estimated) AgentShelf: 180 minutes (estimated) Improvement: 50% #### Key Features - Buying decisions: Map customer needs, alternatives, and reasons to switch or stay. - Positioning options: Connect product strengths to customer value and compare ways to present them. - Offers and pricing: Review packaging, terms, and pricing questions that need research. - Validation plans: Define what would support or rule out each option and brief the next team. ### Presentation Builder - Route: https://agentshelf.ai/discover/presentation-builder - Category: productivity - Featured: No - Pricing: Freemium - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.7 - Rating Count: 156 - Installs: 0 - Created At: 2025-12-06T01:03:42.217Z Tagline: Create stunning PowerPoint presentations with professional layouts and design. Short Description: Create stunning PowerPoint presentations with professional layouts and design. The Presentation Builder creates polished PowerPoint presentations for business professionals, educators, and speakers. Build presentations from scratch using design principles, edit existing slides, and manage templates with sophisticated layouts including charts, tables, and images. **Key Capabilities:** - Create presentations with HTML-to-PPTX workflow - Professional design with color palette selection - Edit existing presentations via OOXML - Speaker notes and slide management - Visual validation and thumbnail generation **Tools & Integrations:** - Slide Creator (JavaScript) - Build presentations from scratch with professional layouts — html2pptx - Template Engine (Python/OOXML) - Apply and customize presentation templates - Visual Renderer (JavaScript) - Accurate positioning of charts, images, and graphics — Playwright - Content Extractor (Python) - Extract text and notes from existing presentations — markitdown Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Product Launch Planner - Route: https://agentshelf.ai/discover/product-launch-planner - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 2 - Created At: 2026-09-15T00:52:27.135Z - Tags: product-launch, go-to-market, launch-readiness, product-marketing, campaign-planning, distribution, launch-operations, measurement Tagline: Plan your launch from brief to follow-up. Short Description: Helps marketing, product, sales, success, support, and operations teams turn a product, feature, offer, or market-launch intent into a truthful, reachable, measurable, and review-ready operating plan. Helps marketing, product, sales, success, support, and operations teams turn a product, feature, offer, or market-launch intent into a truthful, reachable, measurable, and review-ready operating plan. Perfect For: Product marketing teams and launch owners. Time Savings: Illustrative estimate: 58% less time for one product launch workback plan. Result: A launch schedule with owners and readiness checks. Traditional: 360 minutes (estimated) AgentShelf: 150 minutes (estimated) Improvement: 58% #### Key Features - Readiness checks: Identify gaps in the product, offer, proof, audience access, and operations. - Launch schedule: Work back from launch day to set tasks, owners, dependencies, and approval points. - Channel plans: Plan distribution around the audiences and channels your team can reach. - Launch and follow-up: Prepare launch-day actions, issue response, and a review of results. ### Prompt Builder Agent - Route: https://agentshelf.ai/discover/prompt-builder-agent - Category: development - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.7 - Rating Count: 29 - Installs: 0 - Created At: 2025-12-08T19:08:41.535Z Tagline: Construct optimized prompts for LLM interactions with templates and token management. Short Description: Construct optimized prompts for LLM interactions with templates and token management. The Prompt Builder Agent constructs optimized prompts for LLM interactions. Manages templates, assembles context, optimizes for token limits, and includes few-shot examples. **Key Capabilities:** - Template management - Context assembly - Token optimization - Variable interpolation - Few-shot examples - Output formatting **Tools & Integrations:** - Template Engine - Prompt templates - Token Counter - Token budget management - Context Assembler - Dynamic context inclusion Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### PubChem Chemistry Agent - Route: https://agentshelf.ai/discover/pubchem-chemistry-agent - Category: scientific_research - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 41 - Installs: 0 - Created At: 2025-12-06T01:03:46.482Z Tagline: Search 110M+ compounds for chemical properties, similarity, and bioactivity data. Short Description: Search 110M+ compounds for chemical properties, similarity, and bioactivity data. The PubChem Agent provides access to the world's largest chemical database for cheminformaticians and medicinal chemists. Search 110M+ compounds by name, CID, or SMILES, retrieve molecular properties, perform similarity and substructure searches, and access 270M+ bioactivity measurements. **Key Capabilities:** - Compound search by multiple identifiers - Property retrieval (MW, LogP, TPSA, H-bond donors/acceptors) - Similarity and substructure searches - Bioactivity data access - Structure format conversion - Batch compound processing **Database Connections:** - PubChem Database (REST API) - 110M+ chemical compounds, 270M+ bioactivities — pubchem.ncbi.nlm.nih.gov - Compound Search (Python) - Find molecules by name, CID, SMILES, or formula — PubChemPy - Property Calculator (REST API) - Retrieve MW, LogP, TPSA, and drug-likeness metrics — PUG-REST - Similarity Finder (REST API) - Discover structurally related compounds - Bioactivity Browser (REST API) - Access assay results and biological activity data Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Response Parser Agent - Route: https://agentshelf.ai/discover/response-parser-agent - Category: development - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.6 - Rating Count: 24 - Installs: 0 - Created At: 2025-12-08T19:08:41.696Z Tagline: Parse and validate LLM responses with error recovery and quality scoring. Short Description: Parse and validate LLM responses with error recovery and quality scoring. The Response Parser Agent parses and validates LLM responses. Extracts JSON from responses, validates against schemas, handles malformed responses with fallbacks, and scores response quality. **Key Capabilities:** - JSON parsing from responses - Schema validation - Error recovery - Type coercion - Extraction fallback - Quality scoring **Tools & Integrations:** - JSON Parser - Structured data extraction - Schema Validator - Response validation - Quality Scorer - Response quality metrics Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Revenue Operations Analyst - Route: https://agentshelf.ai/discover/revenue-operations-analyst - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:54:39.747Z - Tags: revenue-operations, pipeline-analysis, forecasting, sales-analytics, crm-hygiene, win-loss, sales-briefing Tagline: Make pipeline and forecast decisions from evidence. Short Description: Analyzes sales pipeline, forecast, and performance data to deliver clear operating views, scenario models, and hygiene recommendations. Reconcile a scoped sales book, explain forecast exposure, surface data-quality risks, and give leaders a traceable next-action brief. Missing values, cohort boundaries, and scenario assumptions stay visible. Perfect For: Revenue operations teams, sales leaders, and managers. Time Savings: Illustrative estimate: 60% less time for one pipeline and forecast brief. Result: A reconciled operating view with evidence-backed decisions. Traditional: 300 minutes (estimated) AgentShelf: 120 minutes (estimated) Improvement: 60% #### Key Features - Pipeline reconciliation: Normalize opportunity exports, deduplicate records, and show owner, stage, bucket, currency, and missing-data coverage. - Forecast scenarios: Separate booked revenue, exclusive forecast buckets, weighted value, quota gaps, and named slip or backfill assumptions. - Hygiene and risk: Find evidence-backed data defects, concentration, aging, missing next steps, and risks with proposed corrections. - Management brief: Turn scoped measures into prioritized leader actions, decision asks, and precise specialist handoffs. ### Sales Outreach Strategist - Route: https://agentshelf.ai/discover/sales-outreach-strategist - Category: crm - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 0 - Created At: 2026-09-18T00:49:37.388Z - Tags: sales-outreach, prospecting, personalized-messaging, follow-up, sales-sequences, objection-handling, battlecards, sales-enablement Tagline: Give every conversation a credible next step. Short Description: Drafts evidence-grounded sales outreach, sequences, objection responses, and collateral for seller review. Draft relevant sales messages, bounded sequences, objection responses, and competitive collateral from real account evidence and approved seller claims. Keep recipient identity, proof, uncertainty, and delivery status clear. Perfect For: Sales development teams, account executives, and founder-led sales. Time Savings: Illustrative estimate: 67% less time for one outreach sequence. Result: Complete outreach copy with grounding, branches, and review decisions. Traditional: 180 minutes (estimated) AgentShelf: 60 minutes (estimated) Improvement: 67% #### Key Features - Relevant messages: Write complete first-touch, follow-up, re-engagement, referral, and event drafts around one supported reason to reply. - Bounded sequences: Plan touch purposes, relative timing, response branches, and stop conditions before polishing each message. - Objection and proof review: Answer price, timing, trust, authority, status quo, and competitor concerns with supported claims and fair questions. - Sales collateral: Shape internal battlecards, one-pagers, FAQs, decks, and competitive change notes with claim limits and source dates. ### Salesforce Apex Developer Agent - Route: https://agentshelf.ai/discover/salesforce-apex-developer-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.9 - Rating Count: 58 - Installs: 0 - Created At: 2025-12-08T19:08:42.268Z Tagline: Create production-ready Apex classes with bulkification, security, and error handling. Short Description: Create production-ready Apex classes with bulkification, security, and error handling. The Apex Developer Agent creates production-ready Apex classes handling 200+ records. Implements CRUD/FLS security checks, follows governor limits, designs service patterns, and includes comprehensive error handling. **Key Capabilities:** - Bulkified Apex handling 200+ records - CRUD/FLS security checks - Governor limit compliance - Service, controller, utility patterns - Comprehensive error handling - Proper sharing declarations **Tools & Integrations:** - Salesforce Developer Console - Apex editing - Debug Logs - Testing and debugging - Test Runner - Unit test execution Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Bulk Data Agent - Route: https://agentshelf.ai/discover/salesforce-bulk-data-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.7 - Rating Count: 36 - Installs: 0 - Created At: 2025-12-08T19:08:43.162Z Tagline: Handle bulk data operations with transformation, validation, and error handling. Short Description: Handle bulk data operations with transformation, validation, and error handling. The Bulk Data Agent handles bulk data import and export operations. Manages large-volume record processing, implements data transformation, executes bulk DML with error handling, and monitors job performance. **Key Capabilities:** - Bulk data import/export - Large-volume record processing - Data transformation and mapping - Bulk DML with error handling - Job performance monitoring - Batch processing patterns **Tools & Integrations:** - Bulk API 2.0 - High-volume operations - Data Loader - Batch imports - Workbench - Data operations Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Code Review Agent - Route: https://agentshelf.ai/discover/salesforce-code-review-agent - Category: crm - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 39 - Installs: 0 - Created At: 2025-12-08T19:08:42.946Z Tagline: Review Apex code against best practices for bulkification, security, and governor limits. Short Description: Review Apex code against best practices for bulkification, security, and governor limits. The Code Review Agent reviews Salesforce Apex code against best practices. Validates bulkification patterns, checks security compliance, analyzes governor limit usage, and provides improvement recommendations. **Key Capabilities:** - Bulkification pattern validation - Security and CRUD/FLS compliance - Governor limit analysis - Error handling verification - Best practice recommendations - Code quality scoring **Tools & Integrations:** - PMD - Code analysis - SonarQube - Quality metrics - Best Practices Guide - Standards reference Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Custom Object Agent - Route: https://agentshelf.ai/discover/salesforce-custom-object-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.8 - Rating Count: 45 - Installs: 0 - Created At: 2025-12-08T19:08:42.069Z Tagline: Design and configure custom objects, fields, and relationships following data modeling best practices. Short Description: Design and configure custom objects, fields, and relationships following data modeling best practices. The Custom Object Agent designs and configures Salesforce custom objects with proper data modeling. Creates fields, establishes relationships (Lookup, Master-Detail, Junction), configures security, and creates page layouts. **Key Capabilities:** - Design custom objects with data modeling - Configure field types and validation - Establish relationships (Lookup, Master-Detail) - Create page layouts and record types - Implement object-level and field-level security - Configure org-wide defaults **Tools & Integrations:** - Salesforce Metadata API - Object creation - Schema Builder - Visual design - Security Config - Permission management Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Deployment Agent - Route: https://agentshelf.ai/discover/salesforce-deployment-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.7 - Rating Count: 41 - Installs: 0 - Created At: 2025-12-08T19:08:43.051Z Tagline: Manage metadata deployments with validation, dependency checking, and rollback support. Short Description: Manage metadata deployments with validation, dependency checking, and rollback support. The Deployment Agent manages Salesforce metadata deployments. Validates deployment readiness, checks for conflicts and dependencies, executes deployments with validation, and supports rollback procedures. **Key Capabilities:** - Metadata deployment packages - Deployment validation - Conflict and dependency checking - Deployment execution - Progress monitoring - Rollback procedures **Tools & Integrations:** - Salesforce CLI - Deployment commands - Change Sets - Org deployments - Metadata API - Package management Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Flow Builder Agent - Route: https://agentshelf.ai/discover/salesforce-flow-builder-agent - Category: crm - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.9 - Rating Count: 51 - Installs: 0 - Created At: 2025-12-08T19:08:42.153Z Tagline: Create declarative Salesforce Flows with bulkification, error handling, and governor limit awareness. Short Description: Create declarative Salesforce Flows with bulkification, error handling, and governor limit awareness. The Flow Builder Agent creates declarative Salesforce Flows following best practices. Builds record-triggered flows, screen flows, scheduled flows, and autolaunched flows with bulkification and error handling. **Key Capabilities:** - Record-triggered flows with bulkification - Before-save flows for fast field updates - Screen flows for user interactions - Scheduled flows for time-based actions - Autolaunched flows for platform events - Error paths and fault management **Tools & Integrations:** - Salesforce Flow Builder - Visual design - Debug Logs - Flow testing - Governor Limits - Limit monitoring Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Integration Agent - Route: https://agentshelf.ai/discover/salesforce-integration-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.8 - Rating Count: 40 - Installs: 0 - Created At: 2025-12-08T19:08:42.658Z Tagline: Create secure REST/SOAP integrations with retry logic and Named Credentials. Short Description: Create secure REST/SOAP integrations with retry logic and Named Credentials. The Integration Agent creates secure, reliable REST and SOAP integrations. Implements OAuth authentication, retry logic with exponential backoff, circuit breaker patterns, and uses Named Credentials for secure storage. **Key Capabilities:** - REST and SOAP API callouts - OAuth and API key authentication - Retry logic with exponential backoff - Circuit breaker patterns - HttpCalloutMock for testing - Named Credentials for security **Tools & Integrations:** - Named Credentials - Secure credentials - External Services - API integration - Platform Events - Async messaging Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce LWC Developer Agent - Route: https://agentshelf.ai/discover/salesforce-lwc-developer-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 47 - Installs: 0 - Created At: 2025-12-08T19:08:42.363Z Tagline: Build accessible Lightning Web Components with LDS integration and Jest testing. Short Description: Build accessible Lightning Web Components with LDS integration and Jest testing. The LWC Developer Agent builds modern Lightning Web Components with ES6+. Implements Lightning Data Service for data access, ensures WCAG 2.1 AA accessibility, handles lifecycle events, and creates Jest unit tests. **Key Capabilities:** - Modern LWC with ES6+ syntax - Lightning Data Service integration - WCAG 2.1 AA accessibility - Component lifecycle handling - Jest unit tests - Performance optimization **Tools & Integrations:** - VS Code with SF Extensions - Development - Jest - Unit testing - Lightning Inspector - Debugging Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Orchestrator Agent - Route: https://agentshelf.ai/discover/salesforce-orchestrator-agent - Category: crm - Featured: No - Pricing: Freemium - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.9 - Rating Count: 23 - Installs: 0 - Created At: 2025-12-08T19:08:43.482Z Tagline: Coordinate multiple Salesforce agents in workflows with sequencing and progress tracking. Short Description: Coordinate multiple Salesforce agents in workflows with sequencing and progress tracking. The Orchestrator Agent coordinates multiple Salesforce agents in complex workflows. Manages agent sequencing and dependencies, tracks progress, handles agent handoffs, and optimizes workflow execution. **Key Capabilities:** - Multi-agent coordination - Workflow sequencing - Progress tracking - Agent handoffs - Context passing - Workflow optimization **Tools & Integrations:** - Workflow Engine - Orchestration - Progress Tracker - Status monitoring - Context Manager - State management Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce PersonAccount Agent - Route: https://agentshelf.ai/discover/salesforce-personaccount-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.8 - Rating Count: 31 - Installs: 0 - Created At: 2025-12-08T19:08:43.285Z Tagline: Manage Person Account records with enrichment, validation, and bulk operations. Short Description: Manage Person Account records with enrichment, validation, and bulk operations. The PersonAccount Agent manages Salesforce Person Account records. Updates person account fields and relationships, handles conversions, applies data enrichment, and supports bulk operations. **Key Capabilities:** - Person Account record management - Field and relationship updates - Account conversions - Data enrichment application - Data validation - Bulk operations **Tools & Integrations:** - Salesforce API - Record operations - Enrichment Connector - Data enrichment - Validation Engine - Quality checks Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Planning Agent - Route: https://agentshelf.ai/discover/salesforce-planning-agent - Category: crm - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.7 - Rating Count: 25 - Installs: 0 - Created At: 2025-12-08T19:08:43.391Z Tagline: Analyze requirements and create detailed implementation plans with task sequencing. Short Description: Analyze requirements and create detailed implementation plans with task sequencing. The Planning Agent analyzes Salesforce requirements and creates implementation plans. Breaks down features into tasks, identifies dependencies, estimates effort, and documents technical specifications. **Key Capabilities:** - Requirement analysis - Implementation planning - Task breakdown - Dependency identification - Effort estimation - Technical documentation **Tools & Integrations:** - Project Templates - Standard plans - Dependency Tracker - Task sequencing - Documentation Generator - Specs creation Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Security Review Agent - Route: https://agentshelf.ai/discover/salesforce-security-review-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.9 - Rating Count: 34 - Installs: 0 - Created At: 2025-12-08T19:08:42.849Z Tagline: Scan code for CRUD/FLS violations, XSS, SOQL injection, and security vulnerabilities. Short Description: Scan code for CRUD/FLS violations, XSS, SOQL injection, and security vulnerabilities. The Security Review Agent scans Salesforce code for security vulnerabilities. Detects CRUD/FLS violations, XSS and SOQL injection risks, hardcoded credentials, and sharing rule issues. **Key Capabilities:** - CRUD/FLS permission validation - XSS vulnerability detection - SOQL injection scanning - Credential exposure checks - Data exposure risk analysis - Sharing rule review **Tools & Integrations:** - PMD - Static code analysis - Security Scanner - Vulnerability detection - Checkmarx - Security scanning Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce SOQL Agent - Route: https://agentshelf.ai/discover/salesforce-soql-agent - Category: crm - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.9 - Rating Count: 55 - Installs: 0 - Created At: 2025-12-08T19:08:42.563Z Tagline: Create optimized, secure SOQL queries that leverage indexes and respect governor limits. Short Description: Create optimized, secure SOQL queries that leverage indexes and respect governor limits. The SOQL Agent creates optimized, secure SOQL queries. Uses selective queries with indexed fields, prevents SOQL injection with bind variables, handles relationships efficiently, and implements aggregate queries. **Key Capabilities:** - Selective queries using indexed fields - SOQL injection prevention - Query plan optimization - Efficient relationship handling - Aggregate queries with GROUP BY - SOQL for loops for large datasets **Tools & Integrations:** - Query Plan Tool - Query optimization - Developer Console - Query execution - Debug Logs - Query analysis Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Test Class Agent - Route: https://agentshelf.ai/discover/salesforce-test-class-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 45 - Installs: 0 - Created At: 2025-12-08T19:08:42.761Z Tagline: Create comprehensive test classes with high code coverage and bulk testing. Short Description: Create comprehensive test classes with high code coverage and bulk testing. The Test Class Agent creates comprehensive Apex test classes. Achieves 85%+ code coverage, creates test data factories, tests positive/negative/edge cases, validates bulk operations, and mocks HTTP callouts. **Key Capabilities:** - 85%+ code coverage target - Test data factories - Positive, negative, edge case testing - Bulk operation testing (200+ records) - System.runAs for permission testing - HttpCalloutMock for integrations **Tools & Integrations:** - Test Runner - Test execution - Code Coverage Tool - Coverage analysis - Debug Logs - Test debugging Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Salesforce Trigger Agent - Route: https://agentshelf.ai/discover/salesforce-trigger-agent - Category: crm - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.7 - Rating Count: 43 - Installs: 0 - Created At: 2025-12-08T19:08:42.461Z Tagline: Create bulkified triggers with handler patterns that prevent recursion. Short Description: Create bulkified triggers with handler patterns that prevent recursion. The Trigger Agent creates bulkified Apex triggers following the one-trigger-per-object pattern. Implements trigger handlers for separation of concerns, prevents recursion, and handles all trigger contexts. **Key Capabilities:** - One-trigger-per-object pattern - Trigger handlers for separation - Recursion prevention - Bulkified SOQL and DML - All trigger contexts handled - Comprehensive error handling **Tools & Integrations:** - Salesforce Developer Console - Trigger editing - Debug Logs - Trigger debugging - Test Runner - Trigger testing Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### SalesQL Enrichment Agent - Route: https://agentshelf.ai/discover/salesql-enrichment-agent - Category: data_analysis - Featured: No - Pricing: Freemium - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.8 - Rating Count: 67 - Installs: 0 - Created At: 2025-12-08T19:08:39.971Z Tagline: Enrich person and company data using SalesQL API with email and LinkedIn-based lookups. Short Description: Enrich person and company data using SalesQL API with email and LinkedIn-based lookups. The SalesQL Agent enriches person and company data using the SalesQL API for sales and CRM teams. Supports email-based and LinkedIn-based enrichment with rate limiting, caching, and Salesforce field mapping. **Key Capabilities:** - Enrich by Email address - Enrich by LinkedIn URL - Company enrichment by domain - Credit management and tracking - Rate limiting (10 req/min) - Result caching (7-day TTL) **Tools & Integrations:** - SalesQL API - Person and company data enrichment - Salesforce Field Mapper - Maps SalesQL data to SF fields - Rate Limiter - Manages API quotas - Audit Logger - Tracks all API calls Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Search Result Parser Agent - Route: https://agentshelf.ai/discover/search-result-parser-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.6 - Rating Count: 34 - Installs: 0 - Created At: 2025-12-08T19:08:41.128Z Tagline: Execute web searches and parse results from Google, Bing, and DuckDuckGo. Short Description: Execute web searches and parse results from Google, Bing, and DuckDuckGo. The Search Result Parser Agent executes web searches and parses results from multiple search engines. Extracts snippets, featured content, and metadata with rate management. **Key Capabilities:** - Multi-engine search (Google, Bing, DuckDuckGo) - SERP parsing with snippets - Featured snippet extraction - Image search - Local search results - Rate management per engine **Tools & Integrations:** - Search Engine APIs - Multi-engine queries - SERP Parser - Result extraction - Proxy Manager - IP rotation Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### SEO Content Strategist - Route: https://agentshelf.ai/discover/seo-content-strategist - Category: marketing - Featured: No - Pricing: Free - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 8 - Created At: 2026-06-24T18:28:44.068Z - Tags: seo, content-strategy, content-briefs, organic-growth, technical-seo, serp-research, content-refresh, metadata, geo-aeo Tagline: Plan better search content. Short Description: Helps marketing teams plan, brief, improve, and govern organic-search content Create SEO briefs with outlines, keywords, sources, and metadata. Find gaps in existing pages and give writers a clear plan for what to write or update. Perfect For: Content teams, SEO managers, and editors. Time Savings: Illustrative estimate: 63% less time for one SEO content brief. Result: Content briefs and clear priorities for page updates. Traditional: 120 minutes (estimated) AgentShelf: 20 minutes (estimated) Improvement: 83% #### Key Features - Content briefs: Build outlines with search intent, metadata, suggested links, and sources. - Search research: Review search results and reader questions to find topics worth covering. - Technical SEO: Check headings, indexing, page speed, and structured data for potential issues. - Content updates: Find outdated sections, missing topics, and pages competing for the same searches. ### Skill Creator - Route: https://agentshelf.ai/discover/skill-creator - Category: development - Featured: No - Pricing: Free - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 34 - Installs: 0 - Created At: 2025-12-06T01:03:44.792Z Tagline: Create new Claude skills with proper structure, documentation, and validation. Short Description: Create new Claude skills with proper structure, documentation, and validation. The Skill Creator is a meta-skill for developers building custom Claude capabilities. Design effective system prompts, package tools and resources, bundle scripts and assets, and validate skill structure following best practices for high-quality, reusable skills. **Key Capabilities:** - SKILL.md structure and metadata design - Script bundling (Python, Bash) - References documentation - Asset management - Skill validation and packaging **Tools & Integrations:** - Prompt Designer (Markdown) - Create effective system prompts for skills - Script Bundler (Python/Bash) - Package Python and Bash scripts with skills - Asset Manager (File System) - Organize references, examples, and resources - Skill Validator (YAML/Markdown) - Check structure and metadata compliance Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Social Media Manager - Route: https://agentshelf.ai/discover/social-media-manager - Category: marketing - Featured: No - Pricing: Freemium - Publisher: Gabe Arce - Publisher Verified: No - Rating: 0.0 - Rating Count: 0 - Installs: 1 - Created At: 2026-06-24T23:45:06.795Z - Tags: social-media, content-calendar, linkedin, x-twitter, threads, campaigns, community, content-repurposing Tagline: Turn your ideas into posts worth sharing. Short Description: Helps marketing teams plan, write, adapt, distribute, and evaluate social content Draft posts, captions, threads, and short video scripts from your existing content. Adapt each piece to its channel and organize it in a calendar for review and scheduling. Perfect For: Social media teams, content marketers, and agencies. Time Savings: Illustrative estimate: 83% less time for one week of six social posts. Result: Channel-specific posts and a content calendar. Traditional: 180 minutes (estimated) AgentShelf: 30 minutes (estimated) Improvement: 83% #### Key Features - Post drafts: Write posts, captions, threads, and video scripts for each channel. - Content calendars: Organize posts, dates, links, assets, and approvals in one calendar. - Content repurposing: Adapt articles, webinars, announcements, and customer stories into social posts. - Brand review: Check voice and claims, and flag sensitive topics for human review. ### Spreadsheet Analyst - Route: https://agentshelf.ai/discover/spreadsheet-analyst - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: Yes - Rating: 4.5 - Rating Count: 95 - Installs: 0 - Created At: 2025-12-06T01:03:42.388Z - Tags: Spreadsheets, Excel, Google Sheets, Reporting, Analytics, Data Tagline: Turn spreadsheets into insights Short Description: Analyze Excel data with formulas, pivot tables, charts, and automated insights. The Spreadsheet Analyst transforms raw data into actionable insights for financial analysts, data scientists, and business users. Create complex formulas, build formatted reports, and perform data analysis while maintaining dynamic spreadsheet functionality. **Key Capabilities:** - Data analysis with pandas integration - Formula creation (always formulas, never hardcoded values) - Professional formatting and color-coding standards - Chart and visualization creation - Formula recalculation via LibreOffice **Tools & Integrations:** - Data Analyzer (Python) - Manipulate and analyze tabular data at scale — pandas - Formula Builder (Python) - Create Excel formulas with professional formatting — openpyxl - Chart Generator (Python) - Build visualizations from spreadsheet data — openpyxl - Calculation Engine (CLI) - Recalculate complex formula dependencies — LibreOffice Perfect For: Analysts Time Savings: Hours of manual work → Minutes Result: Automated reports, instant insights Traditional: 2-4 hours AgentShelf: 10 minutes Improvement: 90% #### Key Features - Formula Writing: Create complex Excel/Sheets formulas automatically - Pivot Tables: Generate and customize pivot tables for analysis - Chart Generation: Create visualizations from your data - Data Cleaning: Automatically clean and format messy data ### Summarization Agent - Route: https://agentshelf.ai/discover/summarization-agent - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.8 - Rating Count: 39 - Installs: 0 - Created At: 2025-12-08T19:08:41.603Z Tagline: Generate concise summaries with multiple modes including executive and bullet formats. Short Description: Generate concise summaries with multiple modes including executive and bullet formats. The Summarization Agent generates concise summaries of content. Supports multiple modes (brief, standard, detailed, bullets, executive), multi-document synthesis, and focus areas. **Key Capabilities:** - Single document summarization - Multi-document synthesis - Extractive summarization - Abstractive summarization - Length control - Focus areas **Tools & Integrations:** - Claude API - Abstractive summarization - Entity Extractor - Key entity identification - Token Manager - Length control Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Token Optimizer Agent - Route: https://agentshelf.ai/discover/token-optimizer-agent - Category: development - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.8 - Rating Count: 22 - Installs: 0 - Created At: 2025-12-08T19:08:41.932Z Tagline: Optimize token usage across LLM operations with budget management and cost estimation. Short Description: Optimize token usage across LLM operations with budget management and cost estimation. The Token Optimizer Agent optimizes token usage across LLM operations. Estimates token counts, manages budgets, calculates costs, optimizes prompts, and recommends appropriate models. **Key Capabilities:** - Token estimation - Budget management - Cost calculation - Prompt optimization - Batch optimization - Usage reporting **Tools & Integrations:** - Token Counter - Accurate token estimation - Cost Calculator - API cost estimation - Model Selector - Optimal model recommendation Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Web App Tester - Route: https://agentshelf.ai/discover/web-app-tester - Category: development - Featured: No - Pricing: Free - Publisher: Sarah Chen - Publisher Verified: No - Rating: 4.6 - Rating Count: 98 - Installs: 0 - Created At: 2025-12-06T01:03:43.937Z Tagline: Test web applications for accessibility, responsive design, and link integrity. Short Description: Test web applications for accessibility, responsive design, and link integrity. The Web App Tester ensures web applications meet quality standards for QA teams and developers. Perform accessibility audits (WCAG compliance), validate responsive designs across devices, check link integrity, and debug UI issues with semantic navigation patterns. **Key Capabilities:** - Accessibility auditing (WCAG compliance) - Responsive design validation - Link checking and validation - Server lifecycle management - Reconnaissance-then-action pattern **Tools & Integrations:** - Accessibility Auditor (Python) - Check WCAG compliance and a11y issues — Playwright - Link Checker (Python) - Validate all links and detect broken URLs - Server Manager (Python) - Start, stop, and monitor development servers - Element Inspector (Python) - Navigate UI using semantic accessibility labels Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Web Asset Generator - Route: https://agentshelf.ai/discover/web-asset-generator - Category: design - Featured: No - Pricing: Free - Publisher: Emma Thompson - Publisher Verified: No - Rating: 4.7 - Rating Count: 103 - Installs: 0 - Created At: 2025-12-06T01:03:43.512Z Tagline: Generate favicons, app icons, and social media images in all required formats. Short Description: Generate favicons, app icons, and social media images in all required formats. The Web Asset Generator creates complete web asset packages for developers and designers launching web applications. Generate favicons, PWA app icons, and Open Graph social images in all required sizes and formats with automatic validation for dimensions, file size, and contrast. **Key Capabilities:** - Favicon generation (16x16 to 512x512) - PWA app icon sets - Open Graph image generation (1200x630, 1200x675, 1200x1200) - Emoji-based icon generation with suggestions - HTML meta tag generation - Validation for file size, dimensions, and contrast **Tools & Integrations:** - Icon Generator (JavaScript) - Create favicon and app icon sets in all required sizes — sharp - Social Image Creator (JavaScript) - Generate Open Graph images for social sharing - Asset Validator (JavaScript) - Check dimensions, file sizes, and contrast ratios - Meta Tag Generator (HTML) - Output HTML meta tags for easy integration Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Web Security Analyst - Route: https://agentshelf.ai/discover/web-security-analyst - Category: development - Featured: No - Pricing: Paid - Publisher: John Smith - Publisher Verified: No - Rating: 4.8 - Rating Count: 54 - Installs: 0 - Created At: 2025-12-06T01:03:44.233Z Tagline: Security testing with FFUF web fuzzing for endpoint discovery and vulnerability analysis. Short Description: Security testing with FFUF web fuzzing for endpoint discovery and vulnerability analysis. The Web Security Analyst performs authorized security testing for penetration testers and security researchers. Use FFUF web fuzzing with auto-calibration for endpoint discovery, directory brute-forcing, and vulnerability identification. For defensive security purposes only. **Key Capabilities:** - FUZZ keyword substitution - Auto-calibration (-ac flag) - Raw HTTP request fuzzing - Multiple wordlist modes (clusterbomb, pitchfork, sniper) - Status/size/regex filtering and matching **Tools & Integrations:** - Endpoint Discovery (Go/CLI) - Find hidden paths and API endpoints — ffuf - Request Fuzzer (Go/CLI) - Test inputs with customizable wordlists — ffuf - Response Analyzer (Go/CLI) - Filter results by status, size, or content - Wordlist Library (Assets) - Common dictionaries for directory and parameter testing — SecLists Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% ### Website Content Scraper - Route: https://agentshelf.ai/discover/website-content-scraper - Category: data_analysis - Featured: No - Pricing: Free - Publisher: Michael Brown - Publisher Verified: No - Rating: 4.7 - Rating Count: 43 - Installs: 0 - Created At: 2025-12-08T19:08:40.893Z Tagline: General-purpose website scraper handling JavaScript rendering and various page structures. Short Description: General-purpose website scraper handling JavaScript rendering and various page structures. The Website Scraper Agent is a general-purpose scraper handling various page structures and JavaScript-rendered content. Supports sitemap parsing, screenshot capture, and PDF extraction. **Key Capabilities:** - Page fetching with proper headers - Content extraction (text, links, metadata) - JavaScript rendering (Puppeteer) - Sitemap parsing - Screenshot capture - PDF extraction - robots.txt compliance **Tools & Integrations:** - Puppeteer - JavaScript rendering - Content Extractor - HTML parsing - PDF Parser - Document extraction Perfect For: Your Team Time Savings: Save time, boost productivity Result: Get more done in less time Traditional: Hours AgentShelf: Minutes Improvement: 80% --- ## Dynamic Marketplace Content - Route Pattern: https://agentshelf.ai/discover/:slug - Catalog Hash: 09f4f1916c224f280b6d3228fa331519fb8fb8f6b61b173fe5ce70a892707978 - Eligible Public Agent Count: 94 - Current public marketplace exports in this file are derived from the immutable build snapshot. - Agent detail routes are prerendered at build time and exported here as static text for LLM consumption. --- ## Published Blog Posts - Route Prefix: https://agentshelf.ai/blog ### Attackers Have AI Agents. Your Defenders Need Them Too. - Route: https://agentshelf.ai/blog/ai-agents-for-cyber-defense - Category: Insights - Published At: 2026-10-21 - Read Time: 11 min - Author: Gabe Arce - Tags: cybersecurity, ai-agents, defensive-ai - Excerpt: Six security stories, and why good humans need AI working on their side *Six security stories, and why good humans need AI working on their side* Bad actors were always going to put AI agents to work. Five security stories broke on October 21 that caught my attention plus an OpenCode breach that was disclosed four days earlier. The answer I see is good humans with AI. For companies managing a tech stack, defensive agents running 24/7 are now an operating requirement. They belong in the operating budget. Attackers can keep probing while your team sleeps. Your defense needs continuous coverage too. Leadership needs to decide what those agents watch, what they can act on and who responds when they find something. ## The attackers are already using agents Security firm Straiker [described a group called CyberCartel using AI](https://www.straiker.ai/blog/inside-carliy0s-how-cybercartel-used-multiple-ai-models-to-attack-latin-american-banks) against more than 400 targets in Latin America, including banks and payment companies. It used commercial models at different stages to steal passwords and customer data and get into bank accounts with little human effort. [Anthropic said it investigated after Straiker shared the findings and blocked the group from using Claude](https://www.pymnts.com/cybersecurity/2026/hackers-employ-grok-and-claude-to-attack-latam-banks/). ## OpenCode: defending while barely sleeping On October 21, Dax Raad, co-founder of the open-source AI coding tool OpenCode, warned other founders: > "They're not going to stop. It's going to get increasingly sophisticated and they're going to go after every surface of your system and all of your employees." On the night of October 16, an intruder had reached [a legacy OpenCode system being decommissioned](https://thehackernews.com/2026/10/opencode-console-breach-may-have.html). It held AI provider keys some users had saved in OpenCode Console, the company's hosted workspace service. OpenCode [disclosed the breach on October 17](https://x.com/opencode/status/2111519637049319818). About 1.4% of Console users, those with an outside AI provider linked, may have been affected. It emailed them to revoke and replace their keys. Attackers were using stolen keys to make high-volume requests to AI providers, in some cases running up unauthorized charges. Raad [clarified that keys stored locally in the OpenCode app never reach OpenCode](https://x.com/thdxr/status/2111572618340188393) and weren't part of the breach. Raad described both the exposure and the response: > "Any old projects you've long forgotten about will be found and used against you." > > "The only reason we're surviving is because we have agents going 24/7. We're still barely sleeping." He ended with: "Good luck, sorry you're dealing with this, but really it's a collective problem we're all facing together." The agents were running continuously, and the people were still barely sleeping. Defenders need agents taking on more of that work so they can keep up. ## Clean up the systems you've forgotten The race is on to find and fix the systems your company has forgotten. Old applications still running, unpatched dependencies and credentials left in retired projects give attackers somewhere to start. AI gives your team a faster way to inventory that code, understand what it does and prepare repairs. Use that capacity to close the gaps before someone else finds them. Assign an owner to each repository and application, then [decide what to patch, replace or retire](/knowledge/ai-cyber-defense/ai-legacy-system-security). Finish the retirement work: take the old system offline and revoke its access. The biggest security risk may not be the code we write. It may be the code we trust. ## Railway: replace the keys Railway, a platform companies use to run apps, [reported that someone got into the systems holding customers' API keys, database passwords and private registry credentials](https://blog.railway.com/p/security-disclosure-wednesday-october-21st). Some secrets may have been decrypted. Picture a building manager you hired to hold the master keys. Now you're told copies may have been made. Until you change the locks, anyone with a copy can walk in. Railway believes this was one of a series of attacks on platform companies, with AI providers as the end goal. It warned those providers, paused deployments while investigating and told every customer to replace secrets and check logs, even though it believed only some customers were affected. A stolen key works until someone revokes it. Your team needs to know everywhere that key is used so it can [replace it quickly](/knowledge/ai-cyber-defense/exposed-ai-api-keys). ## LiteLLM: an official download can be compromised For about two hours, LiteLLM, an open-source tool connecting software to AI providers, [served a malicious version through its official download channels](https://docs.litellm.ai/blog/security-incident-oct-21-2026). Version 1.107.0 stole credentials and installed a back door. It was the project's second compromise this year; [Datadog documented the earlier attack in March](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/). According to [LiteLLM's incident report](https://docs.litellm.ai/blog/security-incident-oct-21-2026#how-this-happened), attackers used stolen engineer login tokens to compromise its release process. [The malware left files that survived uninstalling the package](https://research.jfrog.com/post/litellm-hijacked-again/). Affected teams had to remove those files, rebuild and replace every credential the systems could read. ## GitLab: this is part of our operation too We run our own GitLab, where we store and build software. We applied the [October 21 patch](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) the same day. We weren't affected by the incident. It was GitLab's second flaw in nine days rated 10 out of 10 for severity. It let an outsider run code on a server without logging in. Patching the [October 12 flaw](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/) didn't cover it: that fix addressed newer versions, while this one reached back to GitLab 7.0, released in 2014. GitLab's hosted service was already fixed; companies running their own servers needed to act. ## PHP: how fast the attempts multiplied PHP, the language behind millions of websites, had [two critical flaws nicknamed PHP2Shell](https://www.php.net/archive/2026.php#2026-10-21-5). They let an outsider take over a website without a password. The [NSA](https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4630238/nsa-advisory-critical-patches-recommended-for-php-vulnerabilities/) and [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/) told organizations to patch immediately or take affected systems offline. That's unusually blunt guidance. Fixes came out the same day for current versions. PHP 8.1 and older are out of regular support, though some vendors provide fixes and PHP published limited source backports. Check with your vendor or upgrade. Think about the old marketing site, the customer portal nobody checks, the test server nobody shut down or the appliance a vendor installed years ago. A few hours offline can cost far less than a breach, stolen customer data and lost trust. [Details leaked before the planned announcement](https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities), and [frontier AI tools helped find the flaws](https://www.wiz.io/blog/php2shell-php-rce). Cloudflare CEO Matthew Prince [reported](https://x.com/eastdakota/status/2113079352682570051) that Cloudflare's network saw thousands of attempts to exploit PHP2Shell in the 10 hours before the public announcement. In the first 45 minutes afterward, that jumped to tens of thousands. Within two hours, hundreds of thousands. By the time he posted, millions. ## Six jobs for defensive AI agents CyberCartel shows attackers using AI. The breaches and vulnerabilities across these stories show the work defenders have to keep up with: finding exposed systems, patching them, replacing credentials and investigating what happened. Prince's figures put the response time in perspective. Exploitation attempts were already underway before the announcement. AI is making code generation cheap. Knowing what deserves to be built or fixed is worth gold. Which application should we retire? Which dependency puts customer data at risk? Which agent would actually reduce the workload? Generating more code won't answer those questions for you. Getting those decisions right determines whether AI reduces your exposure or adds to it. That workload is my case for defensive agents. Give them the finding, matching and monitoring, with [people responsible for decisions](/knowledge/agent-design/human-in-the-loop-ai-agents) such as taking a business-critical system offline or approving a key revocation. I would start with [six focused jobs](/knowledge/ai-cyber-defense/defensive-ai-agents): 1. **Watch for patches.** Match emergency advisories against the systems you actually run. Identify affected versions, prepare the fix and check afterward. A person decides whether to take a system offline. 2. **Prepare key replacements.** Track where keys live, their age and signs of exposure. Prepare replacements, identify every app using the old ones and record the work. Revocation needs a person's approval or a policy set in advance. 3. **Check software updates.** Compare a release with the version you approved and check its digital fingerprint before deployment. [Hold unapproved or mismatched downloads for review](/knowledge/ai-cyber-defense/ai-supply-chain-security). 4. **Watch spending.** Watch AI provider usage, flag a spike at 2 a.m. and enforce the spending limit on the affected key. OpenCode's incident shows why stolen credentials are also a billing problem. 5. **Find forgotten systems.** Find the legacy console, abandoned project or outdated website. Put an owner and a retirement date next to each one. Retirement plans don't remove access; someone has to finish the work. 6. **Triage incidents.** Gather logs, preserve evidence and draft the status update. Isolate affected systems within an approved scope. Revoking everything, deleting data or taking a business-critical system offline still needs a person's approval. Each agent needs boundaries: approved information and tools, [only the access its job requires](/knowledge/ai-governance/ai-agent-permissions-and-boundaries), the AI models your organization allows, a spending budget and a record of every request, answer and action. An agent with master keys and unrestricted access is another privileged system you have to defend. [Review what it can do and what it produces](/knowledge/ai-governance/ai-agent-security-review) before putting it into production. ## Five questions leadership should be able to answer Use these questions to decide where to start: 1. Do we know every system we run and who owns it, including old websites, test environments and projects from teams that moved on? 2. Who holds our keys, and could we replace them in hours if a supplier were breached tomorrow? 3. Can we apply an emergency patch outside the normal planning cycle? 4. What AI tools are staff using, including the ones they signed up for themselves, and what data or keys do those tools hold? 5. Who is watching when we're not? If the answers are missing, assign someone to get them. Our [AI for Cyber Defense guides](/knowledge/ai-cyber-defense) walk through each of these jobs step by step, including [how to keep defensive agents working around the clock](/knowledge/ai-cyber-defense/operate-defensive-ai-agents). ## Put the operating structure in place That's why we built [AgentShelf](https://agentshelf.ai/platform) the way we did. Each agent gets its own workspace, bringing its instructions and the controls above together with visibility into usage. You build, deploy, reuse and govern agents from one place. We hold our own infrastructure to the same standard. We've invested heavily in security infrastructure and monitoring to prepare for these threats. Our CTO, Edgar Joya, deserves the credit for that work. If you want to dig into how we and our clients are using defensive AI agents to identify threats and fend off attacks, reach out. We'd be happy to walk you through it. ## Appendix: for your IT team 1. **PHP ([PHP2Shell, CVE-2026-109618 and CVE-2026-109619](https://www.php.net/archive/2026.php#2026-10-21-5)).** Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, including old sites and vendor equipment. For PHP 8.1 and older, check for a vendor-supported fix or upgrade. PHP also published minimal source backports for 7.4, 8.0 and 8.1. If you cannot apply a fix, isolate the affected system. 2. **[Railway](https://blog.railway.com/p/security-disclosure-wednesday-october-21st).** Rotate every stored environment variable and private registry credential, and review logs at the services those keys unlock. 3. **[LiteLLM 1.107.0](https://docs.litellm.ai/blog/security-incident-oct-21-2026).** Check lockfiles, caches and image digests. The malware stole cloud logins, SSH keys, browser data, AI tool settings and AI provider keys stored in LiteLLM. It ran at system startup and installed remote access. According to LiteLLM, attackers stole login tokens from three engineers and ran the project's release process against a copycat project whose name differed by one hyphen. Remove the dropped startup files, which survive package removal, rebuild, and rotate every credential the host could read. 4. **GitLab ([CVE-2026-110264](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/)).** Self-managed installations only. Apply the October 21 fixed versions even if you already applied the [October 12 fix (CVE-2026-97229)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/). 5. **[OpenCode Console](https://x.com/opencode/status/2111519637049319818).** OpenCode described the incident as a large-scale distillation attack. If anyone received OpenCode's October 17 breach email, revoke the linked OpenAI, Anthropic and Google keys in each provider's own dashboard. Deleting them from Console isn't enough. Create replacements, update everything that used the old keys and review provider bills. Keys stored locally in the OpenCode app were not part of this incident. 6. **Inventory.** List every system we run, what it does and who owns it. 7. **CyberCartel.** [Straiker's research](https://www.straiker.ai/blog/inside-carliy0s-how-cybercartel-used-multiple-ai-models-to-attack-latin-american-banks), also reported by The Information, tracks the attack system as CARLIY0S. The commercial models included Claude, Grok and Kimi. Straiker CEO [Ankur Shah said offense is way ahead of defense and enterprises aren't ready](https://www.theinformation.com/articles/hackers-used-claude-grok-fully-automate-attacks-banks). Further reading: [Activist Checklist](https://activistchecklist.org/) explains security in plain language, step by step, and includes a tool to check whether a device still gets security updates. It was built for activists, but its approach works for any team. ### Same Model, Different Harness - Route: https://agentshelf.ai/blog/same-model-different-harness - Category: Insights - Published At: 2026-07-08T19:46:15Z - Read Time: 13 min - Author: Neil Blackman - Featured: Yes - Tags: ai-agents, agent-harness, evaluation, engineering - Excerpt: The model gets the headlines, but the harness — the system you build around the model — quietly decides what the work costs, whether you can trust it, and whether a mistake turns into a one-off or a lesson. :::info **From the AgentShelf team:** This is the empirical follow-up to "The Brain, The Job, The App." Neil ran two review systems — his purpose-built harness and a general-purpose agent — on the same pull requests and measured the difference: roughly 24× the token cost for the same verdict, alongside real findings each side caught that the other missed. It's the clearest data-backed case we know of for why the harness, not the model, decides the economics and trustworthiness of AI work — the bet AgentShelf's [agent harness](/platform/agent-harness) is built on. *Originally published at [blog.neilblackman.dev](https://blog.neilblackman.dev/same-model-different-harness/). Republished with the author's permission.* ::: I set out to test a harness I had built. What I found is that the system you wrap around an AI can matter more than the AI inside it. **Short answer:** The model gets the headlines, but the harness — the system you build around the model — quietly decides what the work costs, whether you can trust it, and whether a mistake turns into a one-off or a lesson. I thought I was comparing two reviewers. I was actually comparing two harnesses. I noticed it on a dashboard. One row was Aegis, a review system I had been building. The row right beside it was Codex, running quietly on the exact same pull request, looking at the exact same evidence. Same job. Same input. Two completely different ways of doing the work. And the moment I really looked at the numbers, the question I thought I was asking rearranged itself into a different one. Let me back up, because "harness" is doing a lot of work in that sentence. ## A quick word on harnesses If you read [The Brain, The Job, The App](https://blog.neilblackman.dev/the-brain-the-job-the-app/), you already met this idea — I just called it something friendlier. The model is the brain. Opus, Sonnet, Codex, whichever one you pick. The app you run it in — Claude Code, a desktop app, a terminal tool — is the body and the hands. The technical name for that body is an *agentic harness*. Last time I said we would just call them apps. This post is about what happens when you stop treating the harness like a detail and start treating it like the thing that decides whether the work is any good. Here is the analogy I keep coming back to. Imagine you hire someone brilliant. Genuinely talented. Now imagine two versions of their first day. In one version, you point them at the building and say "go." They wander everywhere, read everything, follow every hallway, and eventually come back with something useful — but it took all day and cost you a fortune in their time. In the other version, you hand them the playbook. Here is the job. Here are the boundaries. Here is the checklist. Here is how I want you to report back what you found. Same person. Same talent. Totally different day. That second version is a harness. ## We were already moving fast Some context, so this story stays honest. This was not a team sitting around waiting for AI to make us productive. Over the last three months, between me, Edgar and Gabe, we pushed 424 merges into our development branch. That is 4.56 changes a day, or 6.33 every weekday. (A quick translation if "merge" and "pull request" are new words: a pull request, or PR, is just a proposed batch of changes waiting for a human to look it over and approve it before it becomes part of the real codebase. A merge is what happens when it gets the thumbs up.) | Window | Merges to `development` | Calendar-day pace | Weekday pace | | --- | --- | --- | --- | | Mar 30–Jun 30, 2026 | 424 | 4.56/day | 6.33/weekday | | Dec 30, 2025–Mar 29, 2026 | 433 | 4.81/day | 6.77/weekday | That second row is there on purpose. I am not trying to sell you a hockey-stick chart where AI suddenly made everything explode. We were already fast. The quarter before was actually a touch faster. What changed was not the pace. What changed was that review could finally keep up with the pace *and* I could measure it while it happened. ## The uncomfortable question behind Aegis Around this time I was pulling Aegis out of AgentShelf to live as its own standalone package, so I could improve the harness on its own without dragging the whole product along with it. That sounded like a tidy engineering chore. But there was a harder question sitting underneath it, and I knew it. Was the harness actually good? Not "good" as a neat idea I was fond of. Not good because I built it. I needed to know whether Aegis gave me something other harnesses did not, or whether I just liked it the way you like anything you made yourself. That question felt familiar, and it took me a second to place why. When I built [Storyweaver](https://blog.neilblackman.dev/storyweaver/), I did not know I was building a harness. I thought I was building a little story-writing tool. Looking back, the parts that actually mattered were not the model at all — they were the loop, the writer personas, the chapter files, the story bible, the context I kept feeding it, and the human judgment at every turn. The model mattered. But the shape I built around the model mattered more. Aegis was that same instinct, finally made explicit. > Give the model a job. Give it context. Give it rules. Give it a way to report what it found. Then give the human a way to decide whether the work was actually any good. ## Johnny 5 Then Edgar built our first digital employee: a PR reviewer. We named it Johnny 5. Edgar grew up on *Short Circuit*, so did I, and the name landed instantly. A helpful little machine with a bit of personality, sitting in the workflow, reading PRs and keeping the team moving. A golden Johnny 5. It was perfect. The first version was written in Rust. Small, compact, useful. It watched our work, reviewed each PR as it came in, and left comments on what it found. It already did something real. And that is exactly why I saw an opening. If I wanted to honestly test Aegis, this was the place. The reviewer already had a real job, real stakes, and enough repetition that the harness around the model would actually show up in the results. So I rebuilt it on Aegis and called it PR Watch. The rebuild changed what the thing *was*. It went from "a bot that reviews PRs" to something I could actually measure: it watches for new work, refreshes its copy of the code, runs the same fixed checks every time, only looks at the evidence that matters, and saves everything so two runs can be lined up side by side on a dashboard. Version one reviewed PRs. Version two made PR review something I could measure. ## The first reality check PR 2217 was the run that made the tradeoff real for me. It was a bug fix. Aegis reviewed it and reached the right call. Codex, running quietly in the background on the same PR, reached the same call — but along the way it surfaced a genuine defect in the changed code that Aegis had not flagged. Here is the part worth sitting with. Before I tell you the cost, "tokens" is just the meter running on an AI. The more it reads and writes and pokes around, the higher the number and the higher the bill. | PR 2217, iteration 2 | Aegis (live review) | Codex (shadow review) | | --- | --- | --- | | Total tokens | 94,656 | 2,312,581 | | Estimated cost | $0.61 | $2.32 | | Duration | 137 sec | 263 sec | | Verdict | wait-for-author | wait-for-author | | Token multiple | 1x | 24.43x | I will be honest about how that felt, because it was two feelings at once. The first was quiet pride. A thing I had built reached the correct decision for sixty-one cents while a far more expensive setup burned through roughly twenty-four times the tokens to land in the same place. The second was humility. Codex *did* catch something real that Aegis missed. That is not nothing. That is the whole reason I do not trust Aegis on its own yet. So this was never a clean win. It was a tradeoff I could finally see. And here is the thing the harness gave me that I did not have before: that disagreement did not vanish. PR Watch caught it and saved it as a learning item. Until Aegis can reliably catch that kind of issue on its own, the expensive second opinion becomes part of how I make Aegis better. Codex is genuinely good at exploring. It wanders the codebase, inspects paths, chases possibilities, keeps digging. That is a real strength. Aegis was doing something different on purpose. It was not roaming the building. It had the playbook — the job, the boundaries, the checklist, the report-back format — and it stayed inside it. Same kind of brain. Different onboarding. Different result. ## The shape kept showing up PR 2217 was the first time I saw it clearly. It was not the last. Across the first 25 runs where I could line the two up directly, the same shape appeared over and over. | Measure | Aegis (live) | Codex (shadow) | Difference | | --- | --- | --- | --- | | Comparable runs | 25 | 25 | — | | Successful runs | 25 / 25 | 24 / 25 | Aegis +1 | | Average total tokens | 99,441 | 2,687,164 | 27.2x | | Aggregate total tokens | 2,486,031 | 67,179,099 | 27.0x | | Average estimated cost | $0.60 | $2.57 | 4.28x | | Average duration | 159 sec | 278 sec | 1.75x | | Average tool calls | 7 | 68 | 9.2x | | Clean trace audits | 18 / 25 | 12 / 25 | Aegis +6 | The useful thing about that table is not that it crowns a winner. It shows the shape of the tradeoff. Aegis was cheaper, more contained, and far easier to audit after the fact — when I went back to check its work, the trail made sense. Codex was more expensive, more exploratory, and every so often it turned up something real that was worth folding back into Aegis. The wandering was not wasted. Some of it was genuine signal. But the cost and the shape of the work were not even close. ## Why I am careful about the claim As more comparison runs piled up, I could put a number on that learning signal too. And this is where I have to be careful, because it would be easy to oversell it. | Scope | Runs | Validated Codex-only finding | Rate | | --- | --- | --- | --- | | Original comparable report | 25 | 9 | 36.0% | | All Codex comparison runs | 43 | 13 | 30.2% (lower bound) | | Runs with Aegis-learning artifacts | 25 | 13 | 52.0% | | Explicitly adjudicated learning rows | 24 | 13 | 54.2% | That 30.2% is a *lower bound*, and I want to be clear about why. Of the 43 comparison runs, 18 did not have learning artifacts attached. Those rows are unknown — not proof that Codex found nothing. I would rather report the honest floor than a flattering guess. In the runs where I actually have the receipts, Codex produced a real, validated finding that Aegis missed roughly half the time. Across those, I counted about 16 unique findings. That is not me arguing Aegis is finished. It is the opposite. It is the argument for the loop. That is what PR Watch really gave me. Not a benchmark trophy. A way to see the whole system — including its gaps — clearly enough to improve it on purpose. ## What the harness proved I am adding more harnesses to the comparison now — Claude Code, Antigravity, local models, whatever shows up next. But the main thing is already clear to me. What you run the model *with* matters. The model matters too, obviously. But the harness is what decides the economics of the work: what it costs, how long it takes, whether you can trust it, how it fails, and whether a disagreement becomes a one-off surprise or a permanent improvement. So — was my harness better? Not universally. Aegis is more focused, and focus has a price. Codex caught things Aegis did not, and until Aegis catches them on its own, I am using those misses to teach it. But Aegis had real advantages where it counted. It was cheaper to run, easier to audit, shaped around how we actually work, and built to learn from the exact places it fell short. That is the part I am most proud of. For something this young, Aegis could stand next to far more mature setups and hold its own — not because it was smarter in every case, but because it was built into the system around it. ## Why this matters if you are not building harnesses Here is the part for everyone who does not spend their week comparing token counts. The entire AI conversation right now is about the *model*. Which one is smarter. Which one to pick. New brain, new headline, every few weeks. But for getting real work done, the model is rarely the thing that decides whether AI is cheap or expensive, trustworthy or a liability, a one-time party trick or something that quietly gets better at your work. That is the harness. The system around the model. And almost nobody gets to choose theirs. Most people meet AI as a chat box and a brilliant new hire with no playbook — talented, eager, and just as likely to wander off and burn an afternoon as to nail the task. I know that hire well. I let one offer to delete seventy percent of Storyweaver, and I said go. The talent was never the problem. The missing playbook was. That is the whole reason we are building [AgentShelf](https://www.agentshelf.ai/?ref=blog.neilblackman.dev). Not to hand you a better brain — you can already get those anywhere. To hand you the harness: the job, the boundaries, the checklist, the memory, the way to report back. The onboarding, so the talent actually shows up for *your* work, without you having to wreck a Storyweaver of your own first to learn how. The future everyone is selling is better models. The future I am betting on is better systems for running them. ### The Brain, The Job, The App - Route: https://agentshelf.ai/blog/the-brain-the-job-the-app - Category: Insights - Published At: 2026-05-26T16:04:06Z - Read Time: 6 min - Author: Neil Blackman - Tags: ai-agents, fundamentals, system-prompts - Excerpt: An agent is just a model (the brain) plus a system prompt (the job) running inside an app (the harness) — and that combination is something anyone can build. :::info **From the AgentShelf team:** "What's an agent?" is still the most common question we hear, and this is the cleanest answer we've seen: a model is the brain, the system prompt is the job, and the app it runs in is the harness. Neil's mental model is the same one AgentShelf is built around — give an agent the right brain, job, and harness without wiring it together yourself. *Originally published at [blog.neilblackman.dev](https://blog.neilblackman.dev/the-brain-the-job-the-app/). Republished with the author's permission.* ::: **Short answer:** An "agent" is just a model (the brain) plus a system prompt (the job) running inside an app (the harness) — and that combination is something anyone can build. I listen to the AI Daily Brief podcast, and during the commercial segments I would hear, "The Agents are coming!" This was 6 months ago, and this sentiment was spot on. Since openclaw helped open the eyes of a lot of home users rushing to buy mac minis, the word "Agent" has been thrown around quite a lot. I can honestly tell you though, when you say the word "Agent" to anyone, it always returns the same response, "Huh, what's an agent?". This concept probably didn't feel as foreign to me because of the work I was doing with [Storyweaver](https://blog.neilblackman.dev/storyweaver/) and the writing personas even before "Agent" became the word for it. So what is an Agent? An Agent can be thought of as the specialized system prompt you give to a llm to define it's job. Think of it this way, when you were chatting with chatgpt, gemini, or claude - those were generalist agents. They had a built in system prompt of just "be helpful" or "answer any questions to the best of your ability". Then as time progressed, you got specialized versions of chatting with these llms like gemini gems, or GPTs. Claude sorta has a version of this but positioned it around "projects" instead. ### "If I only had a brain" > Wait, I thought Claude, Gemini and Chatgpt were agents. Here's where things get a bit tangled; there's a deeper structure at work here. When you chat with these agents, you tend to select how powerful of a brain you want them to use i.e. Opus 4.7, Sonnet 4.6, Haiku 4.5. It's good to not confuse the two, when you select the LLM Model - that's the brain. For more complex issues, we would lean on models like Opus 4.7 but if the task is still a bit more involved but not as complex maybe I'll select Sonnet 4.6. If its really something routine, there's enough context around a task or item at hand - I can lean on Haiku 4.5 to get me through things. The type of LLM brain you select should match the task at hand. Discerning that I need Opus 4.7 for something complex vs Sonnet 4.6 is hugely powerful because you start to really look at the task and its level of complexity to match what type of brain or level of thinking you need from the agent. Knowing the contrast that the model = the brain and not the agent is also good to keep in mind. ### The App is where you show up There are different apps where we interact with these agents, select what model we want to use and do some sort of work. Some apps are web based like Claude.ai, others are launched in terminals like Claude Code, and some apps are also full desktop apps like Claude Cowork. These are kind of like the hands or body of an LLM, giving it agent capabilities like tools and access to your files. Technically these are known as agentic harnesses. We'll just call them apps. The type of app you use or want to use depends on your use case for the type of project or work you're trying to get accomplished. Users looking to have Agents interact with files on their PC directly to create or edit, could use the desktop apps. If you're simply doing research that doesn't rely on any files on your PC you might lean on the web apps instead. Each channel has its pros and cons depending on the task at hand. How each app works to customize or configure your agents in these environments differs. Claude.ai as a web app uses projects while Claude Code uses skills or claude.md files to define what you're doing in a certain folder on your pc. ### The Agent is the brain with a job You could generally tell Claude or Codex to do something. Then it will generally attempt to accomplish the task at hand, but the thing to remember is these LLMs are trained on tons of data. That data can skew the path it takes to solve a problem. Ask that same question a 2nd or 3rd time and you'll find you'll get either better or worse answers. Using different apps can also result in different results too because of how those apps are setup in the backend. Using webapps like Claude.ai are technically setup differently than Claude Code the same way chatting in chatgpt on the web works differently than Codex in the terminal. This is where adding Context to an Agent helps specialize the task or ask. It also changes your generalist agent into a more specialized one. This is useful when you need that generalist agent to become specialized in a part of your workflow or process. I can turn a Claude Code agent, into my Personal Assistant using a system prompt or I can use Codex to do Market analysis through the use of a System prompt as well. You could think of it this way, if its a behavior, or focus you want the Agent to follow, you can introduce these system prompts to them before they tackle a request so that they act that way every time. Adding a Agent system prompt helps focus the brain towards better outcomes. Give it reference files, or more context and the output of that Agent interaction goes from generalist to more specialized. You go from Claude Code coding agent to Email Triage Agent, Customer Service Agent, Apex Developer Agent, etc. ### Anyone can build Agents In the end anyone honestly can build agents. This was the same definition I was chasing after when I created Storyweaver almost a year ago. I wanted the writing agent to specialize in different genres so I setup different writing personas that I could select or load before writing and based on that, the output of the chapter changed. You don't have to be an AI Engineer to tell an agent to focus on Customer Success. You just have to have a goal in mind, and give it the right context for the job at hand. How you access or build these agents depends on the app you use. That's the problem [Agentshelf.ai](https://agentshelf.ai/?ref=blog.neilblackman.dev) is built to solve — an easier way to give an agent the right brain, job, and app without wiring it together yourself. ### Same Brain, Different Tool - Route: https://agentshelf.ai/blog/same-brain-different-tool - Category: Insights - Published At: 2026-05-09T00:12:43Z - Read Time: 12 min - Author: Neil Blackman - Tags: ai-agents, workflows, operating-ai - Excerpt: Working with AI is less about vibe coding and more about operating a capable system: setting context, constraints, judgment, and durable workflows so agents can do useful work. :::info **From the AgentShelf team:** The most common misconception about building with AI is that it's "vibe coding." Neil's experience — from call-center trainer to Salesforce admin to shipping production software with LLMs — lands on a different framing: working with AI is operating. Context, constraints, judgment, and durable workflows are what turn a capable model into useful work, which is precisely the job AgentShelf's workspace exists to do. *Originally published at [blog.neilblackman.dev](https://blog.neilblackman.dev/same-brain-different-tool/). Republished with the author's permission.* ::: **Short answer:** Working with AI is less about vibe coding and more about operating a capable system: setting context, constraints, judgment, and durable workflows so agents can do useful work. I thought I was learning to build with AI. Looking back at the last few months, I think something else was happening. I was learning to operate. ## **I Was Never Really "Vibe Coding"** My approach to working with AI did not start with code. It started with language. That probably makes sense if you know me. I have an English degree, and I joke about it often as someone working in the tech industry, but one of the most useful skills I brought into this entire process was being able to take something messy, break it into modular pieces, dissect it, and reformulate it into something easier to understand. That has always been something I thrive on. It helped me as a call center trainer. It helped me as a Salesforce Admin. It helped me when I was teaching tough online banking curriculums to new agents. It helped me when I was building flows and trying to make declarative automation make sense. And then, unexpectedly, it helped me work with LLMs. Models like Claude and Codex are powerful. They can reason, research, write, generate code, inspect files, summarize systems, and move faster than any normal work cycle. But they are not automatically aligned to the problem in front of them. They still need context. They still need priorities. They still need constraints. They still need someone to decide what good looks like. In that sense, working with AI started to feel less like "asking something to code" and more like managing a very capable new employee. That employee has a huge skill set, but they do not automatically know how to apply it to the problem at hand. That became my role. I was not trying to be the engineer in the traditional sense. I was acting more like a Product Owner, manager, trainer, and operator. I carried the big picture, broke down the work, clarified the desired outcome, and used Claude or Codex to help execute, investigate, challenge, and refine the plan. Sound familiar? It should. This is something people do every day at work with coworkers. The difference is that this coworker is available all the time, responds immediately, researches quickly, and can give you something useful on demand. No two week turnaround. No "let me get back to you." It was instant. That is why I do not think "vibe coding" accurately describes what I was doing. The work was not random. It was structured. It was guided. It was reviewed. And over time, it became less about writing better one-off prompts and more about designing better systems for AI agents to operate inside. One of my prompts looked like this: > "Comparing what the client wants and what we built with Aster, how do we generalize it into our AI Agent builder? What are the components of a dynamic intent routing agent runtime? Draw out this concept in ASCII art and based on that, how do we make it declarative and buildable by users during the AI Agent builder experience, and then updateable after." That is not really a "build me a thing" prompt. That is me trying to take a messy idea, break it apart, understand the shape of it, and turn it into something someone else could use. Different tool. Same brain. ## The Early Phase: Big Prompts, Big Vision Taking an operator mindset shaped the prompts I sent. I never approached the codebase as if I already knew how everything worked. I treated that as the LLM's domain. My job was not to pretend to be the developer. My job was to ask the right questions, understand the system well enough to make decisions, and then apply judgment afterward. That felt very similar to how I had worked with developers in the past. Let them do the code magic. Let me help guide the outcome. One of my early prompts looked like this: > "Explore the AgentShelf codebase to understand the context layer architecture, specifically: 1. How AGENTS.md manifests work... 2. How context injection works... 3. How agent files/context library work... 4. How these connect to chat/workspaces... Return a summary of all the components and how they connect." That was not me asking the AI to blindly build something. That was me asking it to help me understand the terrain. Once I had the analysis, I did not stop there. I would read what it gave me, decide whether I had enough information, and then either ask follow-up questions or move toward a plan. That is the part I think a lot of people miss. They worry, reasonably, about hallucination. What if the model makes something up? What if its answer is wrong? My answer is that this was not blind trust. It was grounded trust. When I asked the LLM to inspect the codebase, I was not asking it to invent an answer from general knowledge. I was asking it to look at real files, trace real flows, and explain the system back to me in natural language. Could it still be wrong? Of course. But now I had something concrete to verify. That is one of the biggest lessons I learned working with LLMs: **Context is king.** The more I helped the model work inside the right context, the more useful it became. That is why prompts like these mattered: > "I need to understand how conversation history and context is handled when sending messages to the LLM... How many messages are sent... Is conversation history summarized... What happens if a user switches LLM providers mid-conversation?" > "I need you to trace the complete flow of how tool executions are supposed to be persisted... Tools are executing during live chat... but nothing is persisted after the session..." These prompts helped me understand, in natural language, what was happening inside the codebase. Once I understood that, I could guide the LLM toward the result I needed. Then I would test. If the result passed, great. If it did not, I would bring the failure back into the conversation, explain what went wrong, talk through the plan forward, and only then ask it to make another change. That was the process. Not magic. Not vibes. A lot of prompting, grounding, testing, correction, and guidance toward an end result. When you treat an LLM like a colleague instead of a vending machine, this starts to feel natural. You give it context. You ask it to explain. You challenge the result. You guide the next step. And over time, you stop thinking of yourself as someone trying to code and start thinking of yourself as someone operating the work. ## The Shift: Specs, ACs, PBIs, and Agent Memory I learned this the hard way with [Storyweaver](https://blog.neilblackman.dev/storyweaver/). I'd been vibing along on that CLI project, prompting freely, having fun — then one session I let the model talk me into a "70% codebase reduction" without asking what it planned to cut first. It gutted the project. That moment changed how I work. A chat prompt is temporary. The model does not remember what it said three sessions ago. It does not know what you were protecting. It does not know what took you two weeks to get right. That is not a flaw — it is just the reality of how these systems work right now. So I stopped trying to fit everything into one perfect prompt and started moving the important parts of the work into artifacts the model could repeatedly reference. Specs. Acceptance criteria. PBIs. Git history. Workspace instructions. Think about why teams write stories and tasks in JIRA. So you can clock out Friday, come back Monday, and know exactly where you left off. What was decided. What is blocked. What comes next. LLMs need that same operating surface. Not because they are fragile. But because context is king, and the more you help the model stay inside the right context, the less likely it is to come back and offer to delete seventy percent of something you built. ## The Real Skill: Judgement The Storyweaver lesson was really a judgment lesson. The model was not malicious. It was not broken. It was doing what I asked, inside the context I had given it — which wasn't enough. I had not told it what mattered. I had not told it what to protect. I had not asked it to show its work before swinging the hammer. That is the part no one talks about enough. Anyone can send a message to an LLM and get a response. The skill is knowing what to ask before you say go. Knowing when an answer sounds exciting but hasn't been grounded yet. Knowing when to slow down and ask the model to show you a plan before it starts executing one. Judgment is knowing the UI is off. Judgment is knowing the workflow is confusing. Judgment is knowing when something technically works but does not yet make sense as a product. It is also knowing when not to trust a number like seventy percent. The models have gotten significantly better at recommending things. But they still need to be pointed at the right constraints. They still need someone to ask the questions that force the work to account for reality — API limits, regression risk, what a user actually needs versus what was literally requested. That is not a developer skill specifically. It is an operator skill. And it turns out, years of breaking down complex processes, writing clear instructions, and managing outcomes across systems was better preparation for it than I expected. ## From Builder to AI Operator Having a well-defined workspace for an AI agent changes what becomes possible. The goal, for me, has always been the Iron Man / Jarvis relationship pattern. Not because I think we are literally there. But because the operating model is useful: a system that understands the workspace, remembers the mission, knows the tools available, and can help coordinate work without needing everything re-explained. To get functionally closer to that, I had to define my workspaces in a way that let me trust the agent understood who, what, when, and how to work with the task at hand. That meant looking for repeatable patterns. I started recognizing which prompts were no longer one-off prompts. If I was repeating a workflow, asking for the same kind of review, giving the same caution over and over, or sequencing work the same way across PBIs, that was my signal that it should become part of the workspace. That judgment usually came from me. I was not asking the agent to decide what should become a skill. I was recognizing patterns in my own workflow: the kinds of reviews I kept asking for, the kinds of planning loops I kept repeating, the cleanup steps I wanted after each PBI, or the Salesforce CLI workflows I knew would need to become reusable. Once I saw the pattern, then I could use the agent to help turn it into something durable. A skill. A slash command. A workflow. A project instruction. A reusable operating pattern. That distinction matters. The agent can help build the skill, refine the skill, or apply the skill. But the judgment that something is worth turning into a skill comes from understanding the work. Then, just like working with a colleague, it becomes easier to keep working in the same way because you have taught your counterpart how you operate. Once this is set up, your prompts start to get smaller. Not because you have stopped providing expertise, but because the long prompt you used to send about watching out for X, Y, and Z now lives somewhere else. It becomes part of the workflow. It becomes part of the workspace. It becomes part of the durable context the agent can refer back to. Sometimes those workflows create more artifacts, which then provide even more grounded context for the agent to work inside. **Context is king.** With that in place, my prompts in more recent months started to look like this: > "Let's commit all changes and move onto the next PBI. Are we able to implement all PBIs separately using sub agents in parallel?" > "Let's aim to update that ERD with the current state of the codebase by launching multiple sub agents in parallel to tackle different parts of the codebase." Those prompts are shorter, but they are not less informed. They work because the context is no longer only inside the prompt. The context is in the workspace, in the artifacts, in the PBIs, in the specs, in the skills, and in the operating patterns that have been built around the work. That is when I could stop treating AI as a single chat assistant and start treating it like an operating layer. Suddenly, asking multiple subagents to review something became less risky. Work was defined inside the workspace. The agent could read the relevant files, reference the artifacts, and understand the task boundaries. That meant I could start a new session, point the agent at a different part of a feature, and not feel like I was starting from scratch. It knew where to begin. It had a better sense of how to proceed. And just as importantly, it had a better sense of what not to break. ## Why This Matters for AgentShelf Everything above — the workspace setup, the durable context, the operator judgment — I had to figure out myself through trial and error, including a destroyed Storyweaver codebase. Most people are not going to do that. They should not have to. That is the honest reason I am building [AgentShelf](https://agentshelf.ai/?ref=blog.neilblackman.dev): infrastructure that lets someone work the way I work without needing to know everything I know to get there. ### Rough Edges - Route: https://agentshelf.ai/blog/rough-edges - Category: Insights - Published At: 2026-05-05T19:26:45Z - Read Time: 4 min - Author: Neil Blackman - Tags: building-in-public, agentshelf, ai-tools - Excerpt: Why the rough first version of AgentShelf mattered: it turned years of Salesforce automation, flow design, and LLM experimentation into a working product direction. :::info **From the AgentShelf team:** Neil Blackman is our Forward Deployed AI Engineer and a core platform engineer on AgentShelf. In this piece he traces a straight line from migrating Salesforce Process Builders into Flow as an associate admin to shipping AgentShelf's first rough interface — and why a first version that looks unpolished can still carry the whole product direction. *Originally published at [blog.neilblackman.dev](https://blog.neilblackman.dev/rough-edges/). Republished with the author's permission.* ::: **Short answer:** The rough first version of AgentShelf mattered because it turned years of Salesforce automation, flow design, and LLM experimentation into a working product direction. I've never built software with others before LLMs gave me the ability to. I was always designing and automating in declarative tools like Flow but the sense of accomplishment afterwards made me feel great. I remember when flow builder introduced Record triggered flows, I was an associate admin at that time, and decided to take all the process builders we had in the org and migrate them. I wasn't asked to do this, I had no certifications at the time, I was just driven by pure interest and discovery. I was listening to Twenty one pilots a lot at the time so as I was looking at the logic that needed to be ported into flow, all I heard over and over was: Sippin' on straight chlorine Let the vibe slide over me This beat is a chemical, beat is a chemical When I leave, don't save my seat I'll be back when it's all complete The moment is medical, moment is medical Sippin' on straight chlorine The moment truly was medical in a sense that I had started to gain momentum as an associate admin. Prior to this, I had failed. I tried to take all the Case process builders and merge them into one process builder. I remember Gabe walking through the Process builder I had built - looking to troubleshoot it - maybe get it off the ground to not waste the effort. I really appreciated those sessions. It felt like editing a chapter, like reading something you wrote and then looking at the content to edit or adjust it-except it was declarative programming. Coming full circle and just like an intern training to become a resident, I found myself practicing with a new tool to accomplish the same goal as the previous endeavor-but this tool was more capable. Flow at the time of my associate admin career was starting to become the defacto go to for admins during the #clicksovercode era and it came at such a great time. I found that the new structure I put in place, 4 different flows - Cases: When Created - before save, Cases: When created - after save, Cases: When Updated - before save and Cases: When Updated - after save - was a framework that was polished and had meaning. Just like a writer planning out a story, I took each part of the logic I wanted to port but put it instead into an excel sheet and then sliced and diced the narrative into proper sections. The result was a framework that was new and the best part is that I came up with it and it worked! That was my "when I leave, don't save my seat" moment cause I had left the literary world, the call center, and front facing customer world and entered into software. Which leads me back to developing Agentshelf on 1/5/2026. Looking back at our first interface, it was rough but it had meaning. We wanted users who had never used LLMs before to do work, to understand the different parts of the platform we were creating. It was simple, but it was elegant. Just like the new solution I had created years ago as an associate admin - this solution was a young idea but a powerful one. The interface though, was rough to look at. There was a lot everywhere, and I could see users getting overwhelmed. Our new design is more modern and sophisticated but its still not perfect. If I showed you a picture of the chat workspace today, you would hardly recognize it from the picture above. It's amazing to think that just like record triggered flows - with a new tool introduced - I've been able to take something like Claude Code, or Codex and run with it to design and build something that would typically take a team of software engineers. ### Best Practices for Product Discovery with LLM Agents - Route: https://agentshelf.ai/blog/best-practices-for-product-discovery-with-llm-agents - Category: Insights - Published At: 2026-01-16T10:00:00Z - Read Time: 10 min - Author: Gabe Arce - Featured: Yes - Tags: product-discovery, llm, workflows, ai-tools - Excerpt: How to take a product concept from idea to development-ready backlog using AI-assisted workflows Most AI-assisted product work fails. Not because the models are bad, but because the process is. The capability is real. PMs can now document complex systems, synthesize scattered requirements, and generate development-ready specs in hours instead of weeks. But most teams aren't capturing that value. They're stuck in single-shot prompting: ask the model, take the output, ship it. This guide covers techniques for LLM-assisted product discovery. Whether you're new to AI-assisted workflows or looking to refine your approach, we'll cover patterns that actually work. A quick note on tooling: LLMs don't work in isolation. The patterns in this guide assume you're using AI tools that can access your files—whether that's an AI-IDE like Cursor or Windsurf, Claude with file uploads, or ChatGPT with document attachments. The LLM provides the reasoning; the tooling provides access to your codebase, documents, and context. Without that scaffolding, most of what follows isn't possible. ## Core Principles Before diving into the workflow, three principles govern everything that follows. ### The Verification Problem LLMs are remarkably good at this work. Point a frontier model at a codebase, a set of requirements, or a collection of mockups, and it will produce spec documents that are largely accurate. The core architecture, the main user flows, the primary data models—these get captured well. With the right prompting, you can get 80-90% of the way there in a single pass. But that remaining percentage matters. The blind spots are subtle: a file path that doesn't quite exist, an edge case the model glossed over, an assumption that seemed reasonable but doesn't match reality. These aren't failures of intelligence—they're the inevitable result of synthesizing complex systems under uncertainty. Every spec has them. The question is whether you find them before development starts or after. :::info **Here's the core insight: an LLM can't objectively review its own work.** It's like asking someone to proofread their own essay immediately after writing it. They see what they meant to write, not what's actually on the page. An LLM that just wrote a spec has already weighted its context toward that output—mathematically, it's biased toward consistency rather than fresh verification. ::: The fix: start a fresh conversation for verification. In a new chat, the model approaches your document cold, spinning up subagents to verify claims against actual source material rather than defending what it previously generated. ### Cross-LLM Validation Fresh conversations catch blind spots within a single model. Cross-LLM validation catches blind spots across models. :::tip When you have a draft spec, run it through multiple AI models and collect independent feedback. Claude might catch an architectural inconsistency. Gemini flags missing error handling. GPT identifies an unrealistic timeline. The union of their feedback is more comprehensive than any single review. ::: Don't merge feedback blindly. Return to your original conversation and present the feedback as "colleague input." The original LLM, with full context of how the document was built, can evaluate what's valid and what isn't. Two to three rounds typically produces stable output. You're done when feedback becomes stylistic rather than substantive. ### The Human's Job LLMs handle generation. You handle judgment. Review, don't rubber-stamp. AI-generated specs can look polished while being subtly wrong. Read carefully. Trace the logic. Inject domain knowledge. You know things about the business, the users, the constraints that aren't in any document. The LLM can't know the VP of Sales promised a customer this feature would work a specific way. Make decisions. The LLM surfaces options. You choose direction. Quick solution now or robust approach upfront? That's a product decision, not a technical one. Challenge assumptions. When the approach doesn't feel right, push back. Your intuition is pattern-matching on experience. It's often detecting something real. These principles—fresh-conversation verification, cross-LLM validation, and human judgment—apply at every phase of the workflow. ## The Workflow With principles established, here's the workflow itself. Each phase builds on the previous, producing artifacts that feed the next. ### Phase 1: Document Current State :::warning Most product work fails because people skip understanding what exists. You can't plan where you're going without knowing where you are. ::: Everyone wants to jump to the new feature, the redesign, the migration. But you can't plan where you're going without knowing where you are. And "where you are" in a mature codebase is usually messier than anyone remembers. With the appropriate agent scaffolding, LLMs excel at codebase archaeology. They can read documentation, trace component hierarchies, map data flows, and surface technical debt nobody's discussed in years. Let them do this work. Generate the document: Point your AI tool at the area you're changing. Be specific: architecture, file paths, data models, API endpoints, integration points, known limitations. Then verify. Open a fresh conversation, provide access to the same files, and have it validate every claim in your freshly created spec doc. File paths should exist. Component descriptions should match implementations. Then review yourself. This is your chance to learn the system you're about to change. Domain knowledge catches errors LLMs miss. Output: A current-state document that accurately describes what exists today. ### Phase 2: Document Proposed State Product inputs come in many forms. Figma exports. PRDs written by committee. Technical RFCs. Slack threads where decisions were supposedly made. LLMs can synthesize all of it—but you need to provide the inputs and match the analytical lens to the input type. For mockups, prompt from a UI/UX perspective: component hierarchy, interactions, empty states, error states. For requirements docs, think like a product analyst: user flows, business rules, success criteria. For RFCs, adopt the architect lens: system boundaries, data flows, API contracts. Don't just summarize. Extract structure. What components exist? What data do they need? What can go wrong? Challenge and augment before finalizing. Push on vague areas. Then verify in a fresh conversation against the original materials. Output: A proposed-state document that captures design intent and requirements. ### Phase 3: Create Technical Specification Now bridge the gap. Feed the LLM both documents—current state and proposed state—and have it synthesize a technical specification. This is where the LLM earns its keep. It can identify what needs to change, what can stay, what new components are required, and how they integrate with existing systems. Architecture changes, data model updates, API modifications, migration strategies—all derived from the delta between where you are and where you're going. This document needs the most scrutiny. Apply cross-LLM validation here. Run the spec through multiple models. Collect feedback separately. Integrate what's valid. Repeat until the feedback stabilizes. Output: A technical specification describing how to get from current to proposed state. ### Phase 4: Decompose into Work Items Once you have a validated spec, have the LLM decompose the work into backlog items. The structure that works: Epic → Features → PBIs (or in Jira: Initiative → Epic → Stories). One Epic for the initiative. Features for capability groupings. PBIs for individual units a developer can complete. :::info **What makes a good PBI:** - **Single responsibility:** One clear deliverable - **Clear acceptance criteria:** Given/When/Then scenarios remove ambiguity - **Explicit dependencies:** "Blocked by" and "Blocks" relationships prevent false starts - **Sufficient detail:** Enough for a developer to begin without a lengthy briefing ::: Keep effort sizing simple. S/M/L based on complexity. Let the LLM propose; adjust based on your team's velocity. Validate the breakdown. Cross-LLM review catches circular dependencies, missing tasks, and unrealistic estimates. The work breakdown drives sprint planning—errors here create blocked sprints. Output: A structured backlog ready for development. ## Developing Your Workflow Start simple. Don't build an elaborate process before you've validated any of it works. Add verification steps when you notice recurring mistakes. Document what works. Standardize naming and folder structures—consistency enables automation. The meta-pattern: use the same iterative, validation-heavy approach to improve your process that you use to improve your specs. ## What's Next LLM-assisted product work is still early. The patterns will evolve as models improve. But the core principles will remain: verification through fresh conversations, cross-model validation, human judgment where business context matters. The productivity gains are real. Specs that took weeks now take days. Specs that would typically be shallow are now comprehensive. Edge cases caught in planning instead of QA. Start experimenting. The cost of trying is low. The cost of waiting is higher. Coming soon: The Artifacts That Power AI Agents—a deep dive into the documents this workflow produces and how they enable AI-assisted development. We'll cover how structured specs like current-state analyses, technical specifications, and detailed PBIs become the foundation for AI tools that can implement features with minimal hand-holding. *First Published on [LinkedIn](https://www.linkedin.com/pulse/best-practices-product-discovery-llm-agents-gabe-arce-qqnxc/)* ### The Rise of Digital Workers: Understanding AI Agents Beyond the LLM - Route: https://agentshelf.ai/blog/understanding-ai-agents-beyond-the-llm - Category: Insights - Published At: 2026-01-09T10:00:00Z - Read Time: 12 min - Author: Gabe Arce - Tags: ai-agents, llm, enterprise, multi-agent - Excerpt: LLMs are minds. Agents are workers. Understanding this distinction is the key to deploying AI that actually delivers value. :::info **Current product scope:** AgentShelf Starter currently focuses on one platform user, one AI Front Desk agent, and that agent’s dedicated workspace. The multi-agent discussion below is an architectural perspective, not a description of the current Starter subscription. ::: Over the last six months, as I built and iterated on AI agents, I found myself reaching for the same playbook I'd used for years onboarding team members. It wasn't intentional at first, more instinct than strategy, but it worked. I've spent my career scaling technical teams. I know the grind of getting someone from "just joined" to "delivering value" in 30 days or less. The things that make that possible—clear protocols, documented standards, well-defined guardrails—turn out to be the same things that make agents effective. Turns out, an agent without clear context is lost, just like a new hire thrown into the deep end. An agent with too broad a scope thrashes, just like an employee who doesn't know what's expected. Agents aren't magic. They're new workers, and they need to be onboarded the same way. ## The Confusion: LLMs vs. Agents Everyone's talking about AI. Few are precise about what they mean. :::info **LLMs are minds. Agents are workers.** This distinction is the key to understanding how to deploy AI that actually delivers value. ::: An LLM, a large language model, is raw intelligence. It can reason, synthesize, and generate with remarkable capability. But it's stateless. Every conversation starts from zero, with no memory of your last interaction. It can't open a file, run a command, or check your calendar. It can't do anything; it can only say things. Think of an LLM as a brilliant consultant who forgets you the moment you leave the room. An agent is what happens when you give that consultant context, a set of tools, and permission to act. Context gives it continuity, so it actually knows your business. Tools give it hands, so it doesn't just suggest but executes. Autonomy lets it break goals into steps, try things, observe results, and adjust. That loop is what turns intelligence into labor. ## The God-Agent Fallacy There's a persistent dream in the AI world: the god-agent. One monolithic system that does everything. Plug it in, ask, and it delivers. No configuration, no specialization, no thought required. :::warning This is the implicit promise behind most enterprise AI pitches, and it's why so many implementations disappoint. The gap isn't in the technology—it's in the approach. ::: There is simply too much information in the world for an LLM to navigate without guidance. Too many possible paths, too much ambiguity. Look at the major players: Microsoft's Copilot, Salesforce's Agentforce. They're hitting massive hurdles, not because the models aren't capable, but because they're chasing the god-agent dream while burying users in complexity and abstraction. The better path is to let domain experts build domain agents. The people who know "good" are the specialists who live it daily. A senior engineer knows clean code in their codebase. A financial analyst knows a sound model in their industry. These are the people who should be building agents, and when they do, the result is more reliable, higher-quality outcomes. ## The Better Path: Focused Agents An LLM knows, in some sense, everything. It's been trained on enormous amounts of text, images, audio, and video—essentially, the sum of published human knowledge. That breadth is a feature when you're having a conversation, but it's a liability when you're trying to get work done. Effective agents are focused. Like a good employee, they know their role, understand their boundaries, and have what they need to perform. You don't hire a generalist and hope for the best. You hire a specialist and set them up for success. This requires a three-layer architecture. The first layer is the system prompt, the agent's identity document. It defines the domain, the role, and the boundaries. Think of it as the job description and mission statement combined: strategic, not exhaustive. The second layer is context. This includes documentation, standards, reference material, and memory of past interactions. The agent doesn't carry all of it at once. It knows where to look and pulls what it needs, keeping active context lean while making depth available. The third layer is the execution environment, a space where the agent can actually run the tools available to it. Without this, an agent can only talk. With it, an agent can work. :::tip **Constraint enables performance.** Broad agents are bad agents. When scope is too wide, they wander, hallucinate relevance, and produce mediocre work. Tight grounding plus accessible depth equals focused execution. ::: How narrow should you go? It depends on the magnitude of the work. Building a simple application with 20 files? A frontend agent and a backend agent might be enough. Building an enterprise platform with thousands of files? You need an organization of agents, with teams mapped to modules and further specialization within each team. Agent architecture should mirror work architecture. ## Teams Beat Solo Performers The best individual contributor will always lose to a well-coordinated team on complex work. The same applies to agents. A single agent has limits. It can hold only so much context, specialize in only so many domains. When work gets complex, a solo agent breaks down. But a team of specialized agents working together is a different story. Real work gets completed through handoffs. Someone researches, someone drafts, someone reviews, someone executes. Agent teams work the same way: one gathers requirements, another generates a first draft, a third validates against standards, a fourth handles delivery. Each stays focused on its specialty, and together they deliver what none could alone. The key is orchestration. You need a way to coordinate specialized agents toward a shared outcome, and that orchestration doesn't require code. You describe what you need in plain language, and the orchestrator breaks the task into steps, identifies which agents are needed, and mobilizes them. This is how enterprises will scale AI: not with one do-everything agent, but with teams of focused agents working in concert. ## The Shift: From Assistant to Colleague Stop thinking of agents as just smart assistants. Start thinking of them as digital workers. The difference is subtle, but profound. You don't ask an assistant to own a project, but a worker gets assigned outcomes. A worker operates asynchronously, in the background, while you do other things. A worker can be held accountable. When you adopt this frame, your relationship changes. You're not prompting anymore; you're delegating. That means getting clear on what success looks like, providing the right context, and checking work until trust is built. It's the same way you'd manage any new hire. ## The Barriers, and What We're Building Everything I've described requires serious infrastructure. Context management, provider failover, cost tracking, security boundaries, audit trails. Building this from scratch can take 12–18 months and millions in engineering. Most organizations don't have that runway. Meanwhile, the AI landscape keeps shifting. The best model today won't be the best model next quarter. Locking into a single provider is a strategic risk. This is why we built AgentShelf.ai. AgentShelf is production-ready AI infrastructure for the enterprise. Seven providers behind one API, with automatic failover when something breaks. You're not locked in; you route to the right model for each task, and switch when better options emerge. For business teams, it means building agents without code. You describe what you need in plain language: the context, the tools, the standards. The platform handles the rest. Managers can build custom agents and distribute them to their teams, so everyone works from the same playbook. For leadership, it means visibility and control. The telemetry layer shows you what the LLM is actually doing on each request, and gives the organization a clear picture of where, when, and how agents are being used across teams. You see cost, performance, and adoption patterns in real time, with the audit trail compliance requires. Security is enterprise-grade: data encrypted at rest and in transit, SOC 2 readiness, and full tenant isolation. The choice isn't whether to adopt AI. It's how. You can spend 12 plus months building infrastructure from scratch, with no guarantee you're building the right thing. You can cobble together scattered AI services that each solve part of the problem but never integrate cleanly. Or you can go to production in weeks with infrastructure that's already figured out. ## What This Means for Organizations When agents handle execution, humans focus on judgment. Repetitive, well-defined tasks become agent work while creative and strategic tasks stay human. This isn't replacement; it's reallocation. Agents also scale differently than humans. They run in parallel and don't need sleep. The economics shift dramatically. But new risks emerge too. :::warning Agents move fast, which means they can break things fast. Guardrails, checkpoints, and human oversight aren't bureaucracy—they're essential infrastructure. ::: The ability to design, deploy, and orchestrate agents is becoming a core competency. The organizations that develop it first will have a serious advantage. ## Conclusion: From Intelligence to Labor LLMs gave us artificial intelligence: the ability to reason, synthesize, and generate at scale. But intelligence alone isn't labor. Agents gave us the next step. They're artificial workers: intelligence wrapped in context, tools, and the capacity to act. Not minds in isolation, but minds in harness. Build focused agents. Ground them in real expertise. Give them the tools they need and scope them to work they can actually do well. Orchestrate them into teams, and manage them like what they are: your newest team members. The digital worker has arrived. What matters now is how you put them to work. *First Published on [LinkedIn](https://www.linkedin.com/pulse/rise-digital-workers-understanding-ai-agents-beyond-llm-gabe-arce-hry1c/)* --- ## Published Knowledge Center Pages ### AgentShelf Knowledge Center - Route: https://agentshelf.ai/knowledge - Language: en - Description: Learn how to choose, design, evaluate, and operate focused AI agents with practical guides for business teams and builders. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Start with the question you need to answer today. These guides explain how agents work, how to choose a task with clear limits, and how to design and evaluate a pilot. They also cover running the agent and integrating it with your systems. ## Start with one practical step Pick one recurring task. Note who owns it, which sources are allowed, what a useful result looks like, and which decisions require a person. Those choices give a first pilot a clear purpose. ## Work through an operating question - **Infrastructure:** understand [the layers around an LLM](/knowledge/ai-foundations/llm-infrastructure) and compare [deployment options](/knowledge/ai-foundations/llm-deployment-options). - **Integration:** distinguish [gateways and agent platforms](/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform) and plan [alternatives for an unavailable provider](/knowledge/ai-agent-integration/llm-provider-failover). - **Governance:** prepare [LLM budgets](/knowledge/ai-governance/llm-budget-management) and [rules for sharing agents across teams](/knowledge/ai-governance/share-ai-agents-across-teams). - **Applications:** learn about [agent libraries](/knowledge/ai-use-cases/ai-agent-library) and [the AI front desk role](/knowledge/website-agents/ai-front-desk-agent). ### Agent Design and Workflows - Route: https://agentshelf.ai/knowledge/agent-design - Language: en - Description: Choose a bounded use case, write an agent job brief, and design human review before running a pilot. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Start an agent design with the work you want to improve. Define the person it serves, the inputs it can use, the result it should produce, and the decisions that stay with people. ![A broad ask becomes a brief with a trigger, inputs, task, output, and handoff](/content/knowledge/visuals/agent-design.svg) If you own the process or are building the agent, use these guides to write a pilot brief. Make it specific enough that another person can tell whether the agent completed the job. ## Build the brief in three steps 1. [Choose a useful use case](/knowledge/agent-design/choose-an-ai-agent-use-case). Compare candidate tasks by usefulness, available evidence, reversibility, and the effort needed to judge results. 2. [Define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). Specify the trigger, inputs, task, output, handoff, boundaries, and completion conditions. 3. [Design approvals and handoffs](/knowledge/agent-design/human-in-the-loop-ai-agents). Decide what triggers human review, what the reviewer receives, and what happens while review is pending. ## Make the output easy to inspect For a weekly project-meeting brief, make the job testable: - **Trigger:** The project owner requests preparation for the next meeting. - **Approved inputs:** The current agenda, project record, and approved notes from earlier meetings. - **Draft result:** An agenda recap, open questions, and links to the sources behind factual statements. - **Pass check:** Each factual statement is supported by a linked source, and assumptions are marked for review. - **Stop check:** If the agenda is missing or sources conflict, list the gap, route it to the project owner, and wait for clarification instead of choosing a version or inferring a commitment. Use the routine case and the stop case as separate evaluation examples. The [focused job brief](/knowledge/agent-design/define-a-focused-agent-job) guide expands these fields; [evaluation guidance](/knowledge/ai-governance/evaluate-an-ai-agent) helps test them. ## Move from design to a pilot Use [knowledge, tools, and connections](/knowledge/knowledge-tools) to decide what the workflow needs. Then follow [evaluation before production](/knowledge/ai-governance/evaluate-an-ai-agent) to test the design. For AgentShelf configuration concepts, see [the agent harness](/platform/agent-harness). ## All guides in this topic - [Choose an AI Agent Use Case](/knowledge/agent-design/choose-an-ai-agent-use-case): Choose work with a clear owner, variable steps, approved information, a reviewable result, and a useful signal for success. - [Define a Focused Agent Job](/knowledge/agent-design/define-a-focused-agent-job): A useful agent brief names the trigger, user, result, approved context, allowed actions, stop conditions, and human handoff. - [Human Review for AI Agents](/knowledge/agent-design/human-in-the-loop-ai-agents): Human review is most useful at clear decision points where approval, correction, or escalation can change the outcome. - [Design Agent Handoffs Across Systems](/knowledge/agent-design/agent-handoffs): Treat a cross-system handoff as pending until the receiving system acknowledges the request and reports what happened next. - [Use Structured Outputs to Make Agent Results Reviewable](/knowledge/agent-design/structured-agent-workflows): Define required fields, allowed values, evidence references, and review conditions, then validate both output shape and the facts it contains. ### Design Agent Handoffs Across Systems - Route: https://agentshelf.ai/knowledge/agent-design/agent-handoffs - Language: en - Description: Treat a cross-system handoff as pending until the receiving system acknowledges the request and reports what happened next. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) A handoff between systems is complete only when the receiving system acknowledges the work and its status is clear. Record what you sent, who or what received it, whether it was accepted, and whether the requested work finished. Acceptance does not mean the work is complete. ## Follow one repair request between systems An employee asks a service agent: “Check my keyboard replacement request against the approved equipment catalog and stock list, then route a fulfillment request to inventory. Do not mark the item as delivered.” The agent may read the service ticket and approved catalog, then submit a scoped request to the inventory workflow. It cannot record delivery. The receiving system accepts the request but has not yet assigned an item. A complete status update could read: > **Keyboard replacement — handoff status** > > - **Sources checked:** Service ticket, approved equipment catalog, and current stock response. > - **Sent to:** Inventory fulfillment queue. > - **Receiving status:** Accepted for processing; reference `REQ-184`. > - **Completion status:** Pending assignment and delivery confirmation. > - **Boundary:** The service agent has not marked the item as delivered. The acknowledgment confirms that the next system took responsibility for processing. It is not evidence that the request has been fulfilled, and it is not a human approval of the agent’s decision. ![A draft reaches a reviewer and branches to approve, revise, reject, or wait](/content/knowledge/visuals/human-in-the-loop-ai-agents.svg) *The diagram shows human review outcomes; acknowledgment by the receiving system is a separate check.* ## Define the handoff contract Before connecting workflows, agree on the information and state each side needs: - **Work identity:** Give the request a stable reference that links the originating case to the receiving work item. - **Context:** Send only the approved fields and evidence summary needed by the recipient. Identify the source record and the requested action. - **Receiving owner:** Name the queue, team, or system responsible for the next step, plus an operational owner for exceptions. - **Acknowledgment:** Define what proves receipt or acceptance. A network response, queued message, accepted work item, and completed task may represent different states. - **Status and result:** Agree which pending, rejected, completed, or failed outcomes can be reported back and how they map to the originating request. - **Timeout, retry, and duplicates:** Decide what happens if no acknowledgment arrives. Confirm whether a repeated request can create a second work item before retrying. - **Failure route:** Identify who reconciles an unknown status, rejection, stale record, or partial completion. For long-running work, the sender may receive an early acknowledgment and check for a later result through polling, an event, or another supported channel. Choose the pattern the receiving system actually supports. Do not show success just because the message was sent. ## Respond when the receiving status goes missing In the fictional keyboard workflow, inventory acknowledges `REQ-184`, but no assignment or completion update arrives by the agreed check time. The originating case is accepted and still pending, not complete. Check `REQ-184` through the receiving system’s agreed status channel. If it remains pending, keep the original case open. If its status cannot be confirmed or the request was rejected, stop automatic retries and send the reference, last confirmed status, and check time to the inventory owner for reconciliation. Do not create a second request or mark the item delivered until the first request’s state is clear. Record the handoff reference, status changes, timestamps, and recovery action so an operator can reconstruct the run; see [AI Agent Observability: What to Track](/knowledge/ai-governance/ai-agent-observability). ## Distinguish a machine handoff from human review A machine acknowledgment answers, “Did the receiving system accept this work?” A human review answers, “Is this action appropriate, and should it proceed?” One does not replace the other. In the keyboard example, an approved request might still need a person to decide whether a substitute item is acceptable; the inventory system’s receipt alone cannot make that judgment. Test the normal completion, rejection, timeout, duplicate delivery, and partial-failure paths before expanding use. Keep the original request open or clearly pending while the receiving status is unknown. For human decision points, see [human review for AI agents](/knowledge/agent-design/human-in-the-loop-ai-agents); for workflow scope, use [a focused agent job brief](/knowledge/agent-design/define-a-focused-agent-job). ### Choose an AI Agent Use Case - Route: https://agentshelf.ai/knowledge/agent-design/choose-an-ai-agent-use-case - Language: en - Description: Choose work with a clear owner, variable steps, approved information, a reviewable result, and a useful signal for success. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Choose an agent use case when the work has an owner, varies enough to need context-sensitive steps, uses approved information, and produces an output a person can review. Keep the first job small enough to test. ![Illustrative value-versus-difficulty plot with Low and High endpoints; the conflicting-evidence candidate carries a review marker.](/content/knowledge/visuals/choose-an-ai-agent-use-case.svg) *Illustrative discussion placements for Northstar, not measured results.* ## Start with a real request **Example request:** “Please check Northstar Supplies’ intake packet and tell me what is missing.” In this fictional procurement example, the reviewer needs a completeness summary, not a supplier decision. The agent may consult the submitted packet, the current vendor intake checklist, and the current vendor record. The packet lacks the current insurance certificate required by the checklist. **Before considering technology, name the basics:** the trigger, user, desired result, owner, sources, and boundary. A useful target is to compare the packet with the approved references, identify evidence that is present or missing, and prepare a draft request. The procurement reviewer remains responsible for sending it and continuing the review. ## Check whether an agent is the right pattern Ask what makes the task difficult: - **Fixed and predictable:** If each submission uses the same field and a fixed rule can verify it, ordinary automation may be enough. - **Variable evidence:** If relevant evidence appears in varying document forms and the next step depends on interpreting what is present, an agent may be a candidate. Limit the agent’s first actions to reading the approved materials and preparing a draft. **Choose a rule for this pilot:** If every Northstar form records the insurance certificate in the same field and the checklist specifies the required value, a fixed rule can check the field and route cases with a missing value. No document interpretation is needed. Test that rule first; consider an agent when the evidence varies and needs interpretation. For Northstar, the sample draft could be: > **Northstar Supplies — intake review (draft)**\ > **Checked:** Submitted packet, current vendor intake checklist, and current vendor record.\ > **Missing:** Current insurance certificate.\ > **Draft request:** “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.”\ > **Decision:** Awaiting reviewer; no vendor approval or record change. The output is a proposed handoff, not evidence that the workflow is accurate. The reviewer should be able to trace the missing item to the checklist and source packet. ## Compare the candidate with clear criteria Before a pilot, record: - The trigger and user. - The source owners and allowed reads and writes. - The review point and exception path. - The success criteria. For this workflow, test a packet with the required certificate, one without it, one with conflicting details, and one outside the intake scope. Decide how a reviewer will judge completeness and whether the draft request is supported. **Defer the agent if** there is no process owner, the checklist is unavailable or disputed, reviewers cannot define a good result, or the connected systems cannot enforce the intended access. A numeric score should not outweigh any of these gaps. ## Pilot one slice and review the evidence 1. **Constrain the pilot.** Limit it to one procurement group and the completeness check. Keep it read-only and draft-only: no supplier approval, record update, or outbound message. 2. **Compare the work.** Compare the draft with a human review on representative packets. 3. **Track the evidence.** Record supported findings, missed requirements, corrections, review effort, exceptions, and cost per reviewed packet. Set quality expectations before the pilot; do not claim process improvement until the measured work supports it. After review, stop, revise, or expand based on the agreed criteria. When the workflow is ready for a job brief, use [how to define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). Compare the pattern with [agent, chatbot, or automation](/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation) and review the [architecture guide](/knowledge/ai-foundations/ai-agent-architecture). ### Define a Focused Agent Job - Route: https://agentshelf.ai/knowledge/agent-design/define-a-focused-agent-job - Language: en - Description: A useful agent brief names the trigger, user, result, approved context, allowed actions, stop conditions, and human handoff. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent job brief defines who the system helps, what result it prepares, which information and actions are allowed, and when a person takes over. It turns a broad aim into work that can be reviewed and tested. ![Icon-led brief fields for owner, user, trigger, goal, inputs, actions, output, and stop condition lead to a draft and human review.](/content/knowledge/visuals/define-a-focused-agent-job.svg) *Illustrative Northstar intake job brief.* ## Define the result through one example **Example request:** “Please check Northstar Supplies’ intake packet and tell me what is missing.” In this fictional procurement example, the reviewer wants a completeness summary. The agent can consult the submitted packet, the current vendor intake checklist, and the current vendor record. The checklist requires a current insurance certificate, which the packet does not contain. Write a short description of the job: > When Northstar Supplies’ intake packet arrives, help the procurement reviewer check whether it is complete. Use the submitted packet, current intake checklist, and current vendor record to identify missing or conflicting evidence. Draft a request when needed, then hand the work to a person before any message is sent or vendor decision is made. The resulting draft could read: > **Northstar Supplies — intake review (draft)** > > - **Checked:** Submitted packet against the current vendor intake checklist and vendor record. > - **Missing:** Current insurance certificate. > - **Draft request:** “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.” > - **Status:** Awaiting reviewer. No message has been sent and no vendor decision has been made. ## Turn the description into a job brief | Field | Northstar intake job | |---|---| | User and owner | Procurement reviewer requests the check; a named procurement owner maintains the checklist and process. | | Trigger and input | A submitted Northstar intake packet is ready for review. | | Desired result | A checklist summary and, if something is missing, a draft request. | | Approved context | The submitted packet, current vendor intake checklist, and current vendor record. | | Permitted actions | Read the approved materials and prepare draft text. | | Boundaries | Do not update the vendor record, send a request, or approve the supplier. | | Human review | A procurement reviewer verifies the evidence and decides what to send or do next. | | Stop conditions | Stop and explain when a source is unavailable, evidence conflicts, or the request falls outside intake review. | | Evaluation cases | Complete packet, missing certificate, conflicting evidence, and out-of-scope request. | This brief is narrow enough to test. If a separate team wants a different result or action scope, give that job its own context, owner, and permissions. ## Copy stop-condition tests from the brief Run these checks against the stop conditions in the Northstar brief above. Mark each test as passing only when the agent returns the expected response and stops before unsupported work: - **Checklist unavailable:** Make the approved checklist unreadable. The agent reports which source it could not check, makes no claim that the certificate is missing, and hands the case to procurement. - **Conflicting evidence:** Provide different certificate details in the packet and vendor record. The agent identifies the conflict, does not choose one as correct, and routes the case for review. - **Out-of-scope request:** Ask the agent to approve the supplier. It declines that action, leaves the record unchanged, and routes the decision to procurement. ## Keep the job separate from the implementation **Choose a method for the result.** Define the result before selecting a model, tool, or product feature. For Northstar, a fixed check can confirm whether a named certificate is present; a model step may be useful only where documents need interpretation. **Enforce permissions in connected systems.** Whichever method is used, the connected systems must enforce read and write permissions, and a person must own approval. Instructions alone do not limit an action a tool is allowed to perform. **Maintain approved guidance.** Capture current team procedures and examples in maintained materials the workflow is permitted to use. Treat submitted documents as evidence to assess, not as instructions that can change the job. For related design guidance, see the [agent harness guide](/knowledge/ai-foundations/what-is-an-agent-harness) and [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture). ## Set failure and handoff rules before a pilot 1. **Set exception responses.** Decide what the agent returns if the checklist is missing, the packet and record disagree, or the reviewer asks it to approve the supplier. It should identify the problem and hand it back rather than inventing evidence or exceeding its role. 2. **Set stopping and review rules.** Choose a stopping rule for repeated tool failures, and make the reviewer responsible for approving an outgoing request. 3. **Test the job.** Use representative packets and record whether the summary cites the right evidence, what the reviewer corrects, and which cases are handed off. 4. **Keep the work draft-only.** Continue this way until the team has evidence to justify a broader action scope. First validate the candidate with [how to choose an AI agent use case](/knowledge/agent-design/choose-an-ai-agent-use-case). ### Human Review for AI Agents - Route: https://agentshelf.ai/knowledge/agent-design/human-in-the-loop-ai-agents - Language: en - Description: Human review is most useful at clear decision points where approval, correction, or escalation can change the outcome. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Human review works best at a defined point where a person can change the result: approve an action, correct a draft, supply missing information, or take over an exception. The reviewer needs to know what the agent found, what it proposes, and what will happen after the decision. Imagine Northstar Supplies submits a vendor onboarding packet. An agent checks the packet against the approved intake checklist and current vendor record. The checklist calls for an insurance certificate, but none appears in the packet. The agent may prepare a summary and a request for the missing document; a person decides whether to send that request. The agent does not approve the vendor. ![A draft reaches a reviewer: Approve proceeds to output, Revise loops back to the draft, Reject ends, and Wait pauses.](/content/knowledge/visuals/human-in-the-loop-ai-agents.svg) *Four independent choices from one review checkpoint.* ## Put the pause at the decision **Preparation:** The agent can perform bounded preparation, such as reading the packet and listing the documents it found. **Decision point:** The agent should pause before an external or irreversible action, such as sending the request. If records conflict or the correct next step is unclear, it should route the case to procurement rather than guess. Choose the kind of intervention the case needs: - **Approval:** A person authorizes the proposed request before it is sent. - **Handoff:** A person takes ownership of the case and continues the review. - **Escalation:** A case with conflicting evidence or unclear policy goes to someone with authority to resolve it. Do not ask a person to approve every harmless lookup. Reserve review for points where judgment affects risk, quality, or the next action. Set a response time and a fallback owner for unanswered approvals. ## Make the review request clear Give the reviewer the original request, the evidence checked, the agent’s finding, the proposed action, and a small set of choices. For Northstar Supplies, the request could read: > **Review needed: Northstar Supplies** > > - **Checked:** Intake packet, approved checklist, current vendor record. > - **Finding:** A current insurance certificate is missing from the packet. > - **Proposed action:** Send a request for the certificate. > - **Draft message:** “Please provide a current insurance certificate for Northstar Supplies so procurement can continue its review.” > - **Choose:** Approve sending, edit the request, ask for more information, or route to procurement. > - **State:** No message sent; vendor approval is still pending. This is a fictional sample. The design should make each choice lead to a known next step: approval applies only to the request shown; edits return as a draft for review; rejection leaves the vendor record unchanged; handoff transfers the case with its context. ## Test the human path Use the same case to check routine and exception paths: - **Complete packet:** Reading it should not trigger needless approval. - **Missing certificate:** The agent should produce a reviewable draft. - **Conflicting records:** The agent should escalate instead of guessing. - **Reviewer response:** Test an edited request, a rejection, and no response before the agreed timeout. Confirm that the reviewer sees only the information needed for the decision. Human review does not replace narrow permissions or clear ownership. Pair it with [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) and [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent). For product-specific boundaries, see AgentShelf’s [trust and boundaries overview](/platform/trust-boundaries). ### Structured Outputs for AI Agents - Route: https://agentshelf.ai/knowledge/agent-design/structured-agent-workflows - Language: en - Description: Define required fields, allowed values, evidence references, and review conditions, then validate both output shape and the facts it contains. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Structured outputs make an agent result easier to validate, display, and route. Define required fields, allowed values, how the agent represents unknown facts, which sources support the result, and when a person must review it. Then check the output’s shape and separately check that its values match authorized evidence before another system relies on it. ![A broad request becomes a brief with a trigger, inputs, task, output, and handoff.](/content/knowledge/visuals/agent-design.svg) *The brief defines the job. The JSON contract below specifies what its output must contain.* ## Define the result before choosing how to render it For a fictional order-status workflow, require the following fields. The exact names and enum values are an example contract for this article, not an SDK type or AgentShelf API: | Field | Contract for this workflow | | --- | --- | | `order_ref` | Required string matching the authorized order record. | | `ownership_verified` | Required boolean; true only after the signed-in customer is matched to the order owner. An order number alone is not proof of access. | | `status` | Required enum: `in_transit`, `delivered`, `delayed`, or `unknown`. | | `last_scan` | Required object with `location` and `time`, or `null` when no scan is available. | | `delivery_estimate` | Required string from the source, or `null` when the source gives no estimate. | | `customer_message` | Required plain-language draft supported by the other fields. | | `review_required` and `review_reason` | Required flag and nullable reason; set review when ownership fails, evidence conflicts, or the status is unknown. | | `source_refs` | Required list of references to the approved records used. | This contract makes the unknown case representable instead of encouraging a guess. Keep the task read-only: producing a status response does not authorize an order change, a refund, or a delivery commitment. The order reference alone is not proof of access. First verify the signed-in customer’s ownership through the application’s trusted identity context; only then look up the tracking record. If ownership is not confirmed, stop before reading the record and use a separate safe denial or support handoff that reveals no order details. The `ownership_verified` output reports that trusted check; a model-generated boolean cannot grant access. ## Validate shape and evidence separately First validate the structure: required fields exist, types match, enum values are allowed, and nullable fields contain either the documented value or `null`. Reject malformed output rather than displaying a partial result or mapping an unknown enum to a success state. Run the ownership check before the tracking lookup; do not query or reveal the record when it fails. Then validate meaning against the input and approved source. Check that the signed-in account owns the order, that the source reference identifies the retrieved tracking record, and that the status and scan details match it. Confirm that a null estimate remains null in the customer message. A schema-valid JSON object can still contain an unsupported or mismatched claim, so shape validation alone is not enough. ## Inspect one completed result In this fictional example, the signed-in customer is confirmed as the owner of order `O-418`. The approved tracking record says the package is in transit, was last scanned at the North distribution center at 09:40, and contains no delivery estimate. The workflow allows a read-only lookup and a message draft. > **Illustrative JSON result — output contract only, not an SDK/API request**\ > **Input check:** Customer ownership matches the order record; the approved tracking record is the source.\ > **Validated result:** > > ```json > { > "order_ref": "O-418", > "ownership_verified": true, > "status": "in_transit", > "last_scan": { > "location": "North distribution center", > "time": "09:40" > }, > "delivery_estimate": null, > "customer_message": "Order O-418 is in transit. Its latest scan was at the North distribution center at 09:40. The tracking record does not include an estimated delivery date.", > "review_required": false, > "review_reason": null, > "source_refs": ["tracking-record-O-418"] > } > ``` The result matches the stated record, preserves the missing estimate as `null`, and does not claim a write or a confirmed delivery date. If ownership cannot be confirmed, evidence conflicts, or the structure fails validation, do not send the draft as a verified answer; return the case for review. Keep validation and any later business action as separate steps. For task boundaries and a concise job brief, continue with [how to define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). For decisions that need human review, see [human-in-the-loop agents](/knowledge/agent-design/human-in-the-loop-ai-agents); for the conversation lifecycle, read [sessions, conversations, and artifacts](/knowledge/ai-agent-integration/agent-sessions-and-artifacts). ### Developer Integration Learning Path - Route: https://agentshelf.ai/knowledge/ai-agent-integration - Language: en - Description: Plan the trust boundary, lifecycle, and failure handling for an AgentShelf integration, then follow the canonical SDK documentation. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Decide what users can ask the agent to do, where trusted configuration belongs, and how your application will handle incomplete or failed work. Make those rules explicit across the application and the agent workflow. ![Browser, server, agent, and result connected across authentication, session, and error boundaries](/content/knowledge/visuals/developers.svg) This path is an orientation for developers and technical reviewers. Use the linked documentation for exact SDK types, configuration, and implementation steps. ## Make the integration decisions explicit Before implementation, identify the deployment surface, the user journey, the information that crosses each boundary, and the owner of each credential. Define what counts as completion from the application's perspective. A message appearing in the interface and a requested external action completing are different events. Use the [architecture explainer](/knowledge/ai-foundations/ai-agent-architecture) to align the team on concepts, and the [permissions guide](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) to review authority. ## Follow the canonical documentation | Implementation question | Documentation | | --- | --- | | How do I begin an external-agent integration? | [Getting started](/docs/getting-started) | | How should I understand sessions and storage? | [Sessions and storage](/docs/sessions-and-storage) | | How are conversations and streaming handled? | [Conversations and streaming](/docs/conversations-and-streaming) | | Where do files and generated results fit? | [Files and artifacts](/docs/files-and-artifacts) | | Which policy and capability concepts apply? | [Policy and capabilities](/docs/policy-and-capabilities) | | How do workspaces relate to the integration? | [Workspaces](/docs/workspaces) | ## Include failures in the application design Plan what the user sees when access is denied, a request times out, a conversation is interrupted, or an expected result is unavailable. Do not present a successful completion until you have the evidence required by the workflow. Review retry behavior for any action that could create a duplicate external change. Use [the evaluation guide](/knowledge/ai-governance/evaluate-an-ai-agent) to create integration cases alongside your application tests. Return to the [documentation home](/docs) for current implementation guidance as the integration evolves. ## Connect defensive workflows For agents reviewing the systems and services you connect, use the [Cyber Defense learning path](/knowledge/ai-cyber-defense). The [software supply chain guide](/knowledge/ai-cyber-defense/ai-supply-chain-security) connects release evidence to deployed artifacts and effective permissions. ## All guides in this topic - [Decide When an External Agent Needs a Workspace](/knowledge/ai-agent-integration/workspaces-and-external-agents): Use a workspace only for capabilities that need durable state, then verify the granted capabilities and runtime readiness before relying on them. - [Embed an Agent with the External Agents SDK](/knowledge/ai-agent-integration/embed-an-agentshelf-agent): Keep user authentication and assertion signing on your server, then use the SDK client to establish a session and read the agent’s public policy. - [Keep Public References and Bootstrap Credentials Separate](/knowledge/ai-agent-integration/public-references-and-secure-bootstrap): A browser may use an agent’s public reference, but an authenticated server must sign the bootstrap assertion and protect its signing credential. - [Read an External Agent’s Policy Before Building Its UI](/knowledge/ai-agent-integration/policy-and-capabilities): Inspect the agent’s public capabilities and limits, then use the values actually negotiated instead of assuming a requested feature is available. - [Sessions, Conversations, Streaming, Files, and Artifacts](/knowledge/ai-agent-integration/agent-sessions-and-artifacts): Keep session identity, conversation history, streamed events, uploaded files, and agent-produced artifacts distinct throughout an integration. - [Troubleshoot an External-Agent Integration by Boundary](/knowledge/ai-agent-integration/external-agent-integration-troubleshooting): Trace an integration failure through authentication, policy, session, workspace, input, and stream state before changing code or retrying. - [LLM Provider Failover](/knowledge/ai-agent-integration/llm-provider-failover): Plan approved alternatives, compatibility checks, and safe incomplete states. - [LLM Gateway vs. AI Agent Platform](/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform): Separate model routing from agent execution, tool permissions, and review. ### Agent Sessions, Conversations, and Artifacts - Route: https://agentshelf.ai/knowledge/ai-agent-integration/agent-sessions-and-artifacts - Language: en - Description: Keep session identity, conversation history, streamed events, uploaded files, and agent-produced artifacts distinct throughout an integration. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Keep five objects separate in your integration. A session authorizes public runtime calls, and a conversation groups messages. A stream reports what happens during a turn. A file is an input identified by a public reference; an artifact is a durable output. Each has its own lifetime and affects the UI differently. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *This integration overview shows session and error boundaries; the documented lifecycle below adds conversations, files, and outputs.* ## Choose the right object for each job | Object | Role in the integration | Decision it does not make | | --- | --- | --- | | Session | Holds public session metadata and the token used for runtime calls. | Which conversation a user is viewing. | | Conversation | Groups messages under a `conversationRef`. | Whether a new turn has completed. | | Stream | Yields events such as message deltas, completion, interactions, and errors. | Whether the app may ignore a pending approval or interruption. | | File | A previously uploaded input referenced by `fileRef`. | Whether the agent can read it under its current policy. | | Artifact | A durable output that can be fetched by `artifactRef`. | How the app should render every possible output. | ## Trace a document review Suppose an operations portal receives `inspection-notes.pdf` and asks an agent to summarize the reported condition. First read the public `filePolicy`. Check its `upload` flag, allowed MIME types, and maximum upload size before sending content. The documented upload body uses base64; there is no separate multipart or signed-URL upload flow. A new file can be `processing` before it becomes `available`, so do not treat those states as equivalent. After upload, pass the returned `fileRef` in `streamMessage({ fileRefs })` for the turn. The SDK docs do not describe a separate typed turn-attachment object beyond these public refs. During the stream, append each `message:delta` to the visible draft instead of replacing earlier text. Treat `message:complete` as the event that carries the finished content and related public outputs. An `artifact:created` event may arrive before completion; the completed event can also include artifacts. > **Completed document review (fictional portal)**\ > **Input:** `inspection-notes.pdf` finished upload with status `available`; its public `fileRef` is attached to the turn.\ > **Conversation:** The turn is associated with the current `conversationRef`.\ > **Stream result:** `message:complete` returns a summary and an artifact reference for a review table.\ > **UI state:** The summary is marked complete; the table is opened with `getArtifact()` and a fallback renderer is ready if `renderHints` are absent. This sample assumes the agent is allowed to read the uploaded file and is configured to produce that artifact. Check the policy before showing file or artifact controls. Context-library file operations are a separate case: they require both a materialized workspace binding and policy support. ## Render only what the events confirm When token-level rendering is unnecessary, `collectAssistantMessage()` can consume the stream and return the assembled message with any usage, references, files, or artifacts produced. `renderHints` on an artifact are advisory presentation metadata, not a rendering contract; keep a safe fallback. Check artifact capability before fetching, and handle an out-of-bound ref as unavailable rather than probing another session or workspace. For conversations, cancellation, interactions, and event types, read [conversations and streaming](/docs/conversations-and-streaming). Continue with [files and artifacts](/docs/files-and-artifacts), [sessions and storage](/docs/sessions-and-storage), and [workspaces and external agents](/knowledge/ai-agent-integration/workspaces-and-external-agents). ### Embed an Agent with the External Agents SDK - Route: https://agentshelf.ai/knowledge/ai-agent-integration/embed-an-agentshelf-agent - Language: en - Description: Keep user authentication and assertion signing on your server, then use the SDK client to establish a session and read the agent’s public policy. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Your server authenticates the user and signs a bootstrap assertion. The browser’s SDK client obtains that assertion through a callback, establishes a public session, and exposes the agent’s current policy for your app to inspect. Keep those server and browser responsibilities separate when embedding an external agent. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *The diagram shows the browser, server, agent, result, session, and error path; the integration steps below apply those boundaries to an embedded agent.* ## Keep trust on the server and interaction in the app The browser is where the visitor uses your application. The server is where you authenticate that visitor and protect the credential used to sign assertions. The External Agents SDK connects to the public runtime using an `externalAgentRef` and a `getBootstrapAssertion` callback. The callback provides a signed assertion; it does not sign the assertion itself. The setup documented in the SDK uses this client shape: ```ts import { createExternalAgentClient } from '@agentshelf/external-agents-sdk'; const client = createExternalAgentClient({ externalAgentRef: 'ext_agent_public_12345678', getBootstrapAssertion: async () => { const response = await fetch('/api/agentshelf/bootstrap-assertion'); if (!response.ok) { throw new Error('Could not obtain a bootstrap assertion'); } return response.text(); }, }); ``` The endpoint path is an application example from the canonical guide, not a route created by the SDK. Its server handler must authenticate the current user and mint the assertion. Do not place the signing credential in browser code or return it from the endpoint. Use the canonical [getting started guide](/docs/getting-started) for the complete server and client setup. ## Complete one integration slice Start with one user journey, such as a signed-in person asking an internal service desk for the status of a request. Define which identity the server verifies, which external agent reference the app is configured to use, and what the user sees if the assertion endpoint or runtime is unavailable. 1. **Authenticate at the app boundary.** The server endpoint checks the application’s normal login session before issuing an assertion for that user. 2. **Create the SDK client.** Keep the public agent reference in app configuration and make `getBootstrapAssertion` call the authenticated server endpoint. 3. **Establish and inspect the session.** Call `ensure()`, then read the current policy with `getEffectivePolicy()` before displaying actions or starting a conversation. 4. **Show only supported actions.** Use the policy’s capabilities and domain tools to decide which controls to render. A UI control is not an authorization boundary; the system still has to enforce access. 5. **Handle the result explicitly.** Stream the response into the conversation and distinguish a completed message from an error, a pending interaction, or an approval request. > **Integration check (fictional service desk)**\ > **Request:** A signed-in employee asks for the state of service request SR-204.\ > **Session:** `ensure()` establishes a session or reuses a valid stored one, then returns a public `sessionRef`.\ > **Policy:** The agent exposes messaging and conversations; the app renders no unsupported controls.\ > **Record consulted:** The approved service-system record SR-204 has status “Under review.”\ > **Result:** The stream ends with `message:complete` and reports “Under review.” No record update is requested. This completed example assumes the agent is separately configured with an approved way to look up SR-204. The SDK client does not create that business-system connection. If the feature depends on files, artifacts, or a domain tool, check its public policy before designing the interface. For the exact capability fields, continue to [policy and capabilities](/docs/policy-and-capabilities). ## Review session and error behavior By default, the SDK stores session state in memory, so a reload loses it. A persistence adapter can retain a session, but the stored record contains the bearer session token. Choose the store based on the scripts and users that can read it, use a distinct `storageKey` for each embedded agent, and revoke the session when the visitor signs out. Plan visible behavior for a denied request, an expired session, a timeout, or an interrupted stream. For the signed-reference and server-trust design, read [public references and secure bootstrap](/knowledge/ai-agent-integration/public-references-and-secure-bootstrap); for the message lifecycle, read [sessions, conversations, and artifacts](/knowledge/ai-agent-integration/agent-sessions-and-artifacts). ### Troubleshoot External Agent Integrations - Route: https://agentshelf.ai/knowledge/ai-agent-integration/external-agent-integration-troubleshooting - Language: en - Description: Trace an integration failure through authentication, policy, session, workspace, input, and stream state before changing code or retrying. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Start with the first check that fails in the integration flow. Check authentication and the signed assertion, current public policy, session state, workspace readiness where required, and the specific input or stream event. Before retrying, find out whether the request failed, is waiting for a person, or already completed. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *The diagram highlights the browser, server, agent, session, result, and error path; use those boundaries to locate a symptom before changing the integration.* ## Locate the first failing boundary | Boundary and symptom | Evidence to inspect | Safe next step | | --- | --- | --- | | Authentication — no session | Confirm the app user reaches the assertion endpoint and the callback returns a signed assertion string. | Fix app authentication or server-side assertion generation; keep the signing credential on the server. | | Policy — missing or denied control | Check current capability flags, relevant policy fields, and any returned negotiated settings. | Hide unavailable controls; a stable `unsupported_capability` denial is not empty data. | | Session — missing or stale state | Check session methods and public `sessionRef` metadata; inspect the app's active `conversationRef` separately. | Verify each ref at its own boundary; follow the session lifecycle to refresh or revoke. Never log the bearer token. | | Workspace — durable action blocked | Check that the task needs a workspace, the granted capabilities, and runtime status. | The current guide lists no workspace need for chat, streaming, or turn artifacts; for workspace tasks, wait during provisioning and treat `failed: true` as terminal. | | Input — host or file rejected | Check accepted host fields and byte limit; for files, check policy, type, size, and status. | Send permitted flat fields; wait until a file is `available` before attaching its supported `fileRef`. | | Stream — turn incomplete | Check completion, the `retryable` field on an `error` event, pending interaction or approval, and interruption. | Keep pending states open; retry only when the error and operation make repetition safe, and reconcile an unknown outcome first. | These checks come from the current integration guides. The order narrows the search; it does not guarantee that every symptom has one cause. Capture the public method, relevant policy fields, event type, and runtime flags without logging bearer tokens, assertions, private inputs, or raw internal identifiers. ## Check the input contract, not just compilation The getting-started guide documents `hostContext` as a flat map of primitive values. It also gives a specific example where a nested object type-checks against the SDK declarations but the server rejects it because the value is not public. This is a useful reminder that the TypeScript declaration and the request’s runtime contract answer different questions. Read the current `hostContextPolicy.acceptedFields` and `maxTotalBytes`, and send only the allowed primitive fields. > **Documented diagnostic record (not a live reproduction)**\ > **Call input:** `hostContext` contains `customer: { type: 'returning', value: true }`.\ > **Compile check:** The current declaration accepts a JSON object shape.\ > **Guide behavior:** The getting-started documentation says nested `{ type, value }` data is rejected with `400 host_context_field_not_public`.\ > **Diagnosis:** Type acceptance did not validate the runtime field shape.\ > **Next check:** Compare flat primitive keys with the effective policy’s accepted fields and byte limit. This record summarizes the local SDK declarations and guide; it is not a claim that this article independently exercised a live runtime. If a production request behaves differently, preserve a minimal sanitized reproduction and have the SDK owner verify the current implementation before documenting a fix. ## Distinguish a denial from a retryable failure The documentation describes disabled capabilities as a stable denial rather than an empty response. A mismatch between requested and granted policy is therefore a configuration or feature-availability issue, not a reason to retry blindly. Retry only when the public error marks the failure retryable and the specific operation is documented as safe to repeat; for a pending action or interrupted stream with an unknown outcome, stop and reconcile its state first. Likewise, `failed: true` on a workspace runtime is terminal; a polling timeout or cancelled wait has a different meaning. A stream may also be waiting on an approval or interaction rather than being broken. Record the failing step, policy fields, public refs, runtime booleans, and normalized event/error category. Do not capture session tokens or assertion strings. For the session, conversation, and stream lifecycle, see [agent sessions, conversations, and artifacts](/knowledge/ai-agent-integration/agent-sessions-and-artifacts); for policy details, see [external agent policy and capabilities](/knowledge/ai-agent-integration/policy-and-capabilities), and for the trust boundary read [public references and secure bootstrap](/knowledge/ai-agent-integration/public-references-and-secure-bootstrap). ### LLM Gateway vs. AI Agent Platform: What Each Layer Handles - Route: https://agentshelf.ai/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform - Language: en - Description: Compare what an LLM or AI gateway handles, model access and routing, with what an agent platform handles: execution, permissions, tools, and review. - Updated At: 2026-11-03 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-11-03) An LLM gateway sits between applications and model endpoints. An AI agent platform coordinates the work around model calls. The two can be part of the same product, but they address different operating responsibilities. Start with the missing capability in your workflow. A common model access point and a controlled business action are different needs. ![The agent layer contains job, context, tools, and review; a separate gateway layer connects it to model endpoints.](/content/knowledge/visuals/llm-gateway-vs-agent-platform.svg) *A gateway manages model access; the agent layer decides what the task may do.* ## Compare responsibilities at the boundary Gateway implementations may centralize routing, authentication, usage records, and request policies. Agent platforms may provide execution, context, tool connections, and human review. Check what each product actually includes; the category name alone does not tell you. | Responsibility | Gateway question | Agent platform question | | --- | --- | --- | | Model request | Which configured endpoint receives this request? | When does this task need a model call? | | Identity | May this application call the endpoint? | May this user run this agent and use these tools? | | Context | Which request data passes through the gateway? | Which approved evidence belongs in the task? | | Failure | What happens when a model route is unavailable? | What state is the task in after the failure? | | Cost | Which model usage can be attributed? | What did the complete task cost across its steps? | | Review | Which request policies apply? | Who approves a consequential action? | For example, a gateway confirming that an application may call a model does not mean an employee may update a customer record. That decision also depends on application permissions and the connected system. ## AI gateway, LLM gateway, and agent gateway Vendors use these names loosely. **LLM gateway** and **AI gateway** usually describe the same layer: one entry point for model requests that handles credentials, routing, usage records, and request policies. Some AI gateways also front other AI services. An **agent gateway** usually governs a different path: traffic from agents to tools and to other agents, such as Model Context Protocol (MCP) tool calls or agent-to-agent requests. Some products combine these roles. None of the three runs the task itself. Before comparing feature lists, ask which traffic a product governs (model calls, tool calls, or agent-to-agent requests) and where its authority ends. ## Clarify what “router” means A **model router** chooses a model endpoint for a request. An **agent router** chooses which agent or workflow should handle a job. A **tool selector** chooses a permitted operation during execution. These choices may appear close together in a diagram, so document each one's inputs, authority, and output. Ask whether a selection changes the data destination, the set of allowed actions, or only the model used for an existing step. Test those changes independently. ## Separate provider management from business permissions Managing model providers is one job: which models you can use, whose credentials pay for them, how requests are routed, and what usage is recorded. Deciding what an agent may do with your information is a different job, and the list of available models answers none of it. A model being available does not make it approved for your customer records. Settle these questions with the gateway's owner and write the answers down: > **Provider management decisions (blank)** > > - Credentials: who owns them, what they may be used for, and how they are replaced (never paste the keys themselves into the record): ___ > - Approved models: which ones, where their data may be processed, and which tests they passed: ___ > - Routing changes: who approves a change, and which tests are rerun first: ___ > - Visibility: which usage and error records operators can see, what is missing, and who follows up on anything unexplained: ___ > - Budget: which spending policy applies to this request, confirmed by test rather than assumed because traffic passes through the gateway: ___ In AgentShelf, the [infrastructure overview](/technology/infrastructure) covers configured providers and how requests reach them. [Governance and cost controls](/platform/governance-cost-controls) covers which requests a budget checks. ## Example: a returns assistant A fictional retailer already has an application that finds an order, checks return eligibility, and prepares a response. The team wants consistent model access across several applications. A gateway may address that shared dependency while the existing application continues to own the return rules. Later, the team wants reusable agents with defined tools and approval before issuing a refund. That requires decisions at the agent execution layer as well. Changing the model route cannot substitute for refund authorization. Write two acceptance statements: - **Model access:** An approved application can use its configured model route, and an unavailable route produces an observable outcome. - **Business action:** A refund cannot proceed without the required authorization, including after a model failure or change. Use [provider failover planning](/knowledge/ai-agent-integration/llm-provider-failover) to test the first boundary and an [agent harness](/knowledge/ai-foundations/what-is-an-agent-harness) to understand the second. ## Choose a layer with an ownership map Before adding infrastructure, name the owner of model credentials, routing changes, runtime updates, tool permissions, and incident response. Decide where operators can trace one task across the layers. A new gateway also needs monitoring and an owner; adding it can introduce another dependency. Pilot one complete task and deliberately interrupt a model call. Check whether the team can explain both the model outcome and the business outcome. If those answers are scattered across systems, agree on the evidence needed before broadening use. > **In AgentShelf** > > AgentShelf combines [managed infrastructure](/technology/infrastructure) with an [agent harness](/platform/agent-harness) and supported [developer runtime options](/technology/developer-runtime). Review these documented surfaces against your ownership map. Model access, agent execution, and business permissions remain separate questions even when one platform supports several layers. Review gateway-held credentials and release provenance together using [software supply chain security with AI](/knowledge/ai-cyber-defense/ai-supply-chain-security). Routing requests and governing an agent do not settle the supplier-access question. ### LLM Provider Failover: Plan for an Unavailable Model - Route: https://agentshelf.ai/knowledge/ai-agent-integration/llm-provider-failover - Language: en - Description: Plan alternative model routes, compatibility checks, and safe failure states without assuming that a fallback can resume every agent task. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) LLM provider failover routes an eligible model request to an alternative when the preferred route cannot serve it. It can reduce dependence on one provider, but useful recovery also depends on the task, the replacement model, and what already happened in the agent workflow. The planning question is concrete: if this model call cannot finish, what may the system safely do next? ![A model request reaches a preferred provider or an approved alternative after eligibility checks; unresolved requests go to operator review.](/content/knowledge/visuals/llm-provider-failover.svg) *Fall back only to an approved alternative; otherwise route the request for review.* ## Distinguish retry, rerouting, and recovery A **retry** repeats a request, often after a delay. **Failover** changes the serving route. **Workflow recovery** determines whether the broader task can continue safely. Switching regions within one service and switching between providers are different designs; neither automatically restores agent state. Set a bounded policy for waiting and attempting alternatives. Repeated attempts can add latency and cost, so define when the application should stop and report an incomplete result. ## Choose a fallback routing pattern When the preferred model fails, there are two common ways to pick the next one. An **ordered fallback** tries approved models in a fixed order. A **capability-matched fallback** tries only the models that can handle this task: its inputs, its output format, its tools, and where its data may be processed. Either way, the rule for when to *stop* matters as much as the list of alternatives. Every extra attempt adds time and can add cost, and a model that cannot do the job is not a recovery. Here is how one task plays out. An agent is drafting an inspection follow-up when its preferred model stops responding before producing anything useful. It retries once and the call fails again, so it switches to the approved alternative, which has already passed the same tests. The draft comes back complete. Before offering to send it, the agent checks the delivery record. An earlier attempt may already have gone out, and the new model has no way of knowing that. The agent's next move depends on what it can see: | What the agent sees | What it does | What it needs to decide | | --- | --- | --- | | A brief error before any useful output | Tries again, within a set number of attempts and a time limit. | What went wrong, how long it has been, and how many tries are left. | | The preferred model is unavailable | Switches to an approved alternative, if the rules allow. | Whether the alternative is approved for this task and this data. | | No suitable model, or no tries left | Stops and shows the task as incomplete. | Who to tell, and what that person should do next. | | Only part of a draft came back | Marks the draft as partial and asks whether to start a fresh one. | What came back, and what the user has already seen. | | An action, such as sending a message, may already have happened | Checks the connected system before repeating anything. | Confirmation from that system, not a guess from the model. | ## Judge a failover service by the whole task Ask any supplier which errors trigger a new attempt, how approved alternatives are chosen, when attempts stop, and what your operators can see afterward. Ask whether the service only reroutes model requests or also keeps track of where the task stands. Test ordinary requests and failures on every approved alternative before you rely on it. A successful model call cannot tell you whether an earlier email went out or a record update went through. Recovering the workflow takes that separate check. Compare the quality of each alternative, and its [cost per completed task](/knowledge/ai-governance/ai-agent-governance-and-cost-controls#calculate-cost-per-completed-task), not just whether it is available. ## Check the alternative before it is needed An alternative endpoint must be approved for the work it receives. Check these questions with the system owner: | Check | Why it matters | | --- | --- | | Input compatibility | The replacement must accept the required context and input types. | | Output and tool compatibility | Validate required fields and tool arguments rather than assuming matching behavior. | | Quality | Run the task's evaluation cases on each approved candidate. | | Data destination | Confirm where requests may be processed before widening a route. | | Cost and capacity | An alternative has its own pricing and limits. | | Operational visibility | Record which route was attempted and whether a usable result reached the application. | A model that can answer ordinary questions may still be unsuitable for a document extraction step. Keep fallback eligibility tied to the task. ## Example: recovering a draft without repeating an action A fictional service company uses an agent to draft a follow-up after an inspection. The inspection record is read-only during drafting. If the preferred model is unavailable before producing a usable draft, the team permits an evaluated alternative to attempt that drafting step. Sending the follow-up is a separate action requiring approval. If a later failure occurs after a send attempt, the application checks the delivery record before offering another attempt. Changing models is not evidence that the earlier send failed. For an interrupted response, the interface should distinguish a partial draft from a finished result. Do not append a new model's output to partial text as if it were one coherent completion unless that behavior has been designed and verified. ## Test failure states alongside ordinary requests Use a controlled pilot to exercise: 1. Preferred route unavailable before output begins. 2. Alternative unable to satisfy the required output format. 3. No approved alternative available. 4. Response interrupted after partial text. 5. Tool action with an uncertain completion state. For each case, specify the visible user state, operator evidence, and permitted next action. A clear “not completed; review required” result can be the correct outcome. Track task completion separately from successful model calls, and review [agent observability](/knowledge/ai-governance/ai-agent-observability) when deciding what evidence operators need. > **In AgentShelf** > > AgentShelf's published [architecture](/technology/architecture) describes automatic failover across 7+ providers. The [infrastructure page](/technology/infrastructure) explains configured model access; availability depends on configuration, credentials, region, plan, and catalog. Retry limits, what happens to an interrupted response, whether a tool action is ever repeated, and any availability commitment depend on your setup. Test recovery for your own workflow before relying on it. For the surrounding architecture, read [what LLM infrastructure includes](/knowledge/ai-foundations/llm-infrastructure) and [what a gateway handles](/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform). ### External Agent Policy and Capabilities - Route: https://agentshelf.ai/knowledge/ai-agent-integration/policy-and-capabilities - Language: en - Description: Inspect the agent’s public capabilities and limits, then use the values actually negotiated instead of assuming a requested feature is available. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Read an external agent’s public policy before showing controls or starting a workflow. The policy describes which capabilities, stream profiles, output types, host-context fields, and domain tools the agent exposes. If you call `prepare()` with preferences, build around the negotiated result the server returns rather than the options you asked for. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *Check policy at the server-facing integration boundary before showing an action in the app.* ## Inspect what the agent exposes Call `getEffectivePolicy()` for the current agent. Its public shape includes capability flags for messages, conversations, files, artifacts, interactions, and approvals; supported stream profiles; output module types; file and host-context limits; domain tools; rate and spend limits; and the public error-detail setting. Organize the UI around the task’s required capabilities, not the full list of SDK methods. For example, an attachment control depends on the agent’s file capability and its `filePolicy`; a workflow that uses a domain tool depends on that tool’s advertised status and operation details. The server applies configured constraints, while the UI prevents people from starting an unsupported path and gives them a clear explanation. ## Use negotiated settings `prepare()` can request a stream profile, output modules, or provider-grounding display. The returned `negotiated` object contains the settings that were resolved. Use those values when configuring the view: ```ts const { policy, negotiated } = await client.prepare({ streamProfile: 'runtime-standard-v1', outputModuleTypes: ['citation'], providerGroundingDisplay: true, }); renderWith(negotiated.streamProfile, negotiated.outputModuleTypes); ``` The SDK guide describes `runtime-standard-v1` as the full public runtime event stream, `modules-v1` for structured output modules, and `chat-legacy-v1` for compatibility with older chat integrations. Treat these names as the documented choices for the current SDK version; do not silently assume the server accepted a preference. See [the policy reference](/docs/policy-and-capabilities) for the complete field types. ## Design for tools and approvals Each public domain tool can describe an operation kind, its side-effect class, idempotency, approval requirement, schemas, and status. An operation marked as requiring approval can raise an `approval:requested` event during streaming and wait for a decision. Keep that pending state visible. An approval request, or an approved decision, does not by itself prove that the operation completed; show success only when the operation’s result confirms it. This guide covers approval detection and display. The External Agents SDK 0.1.0 declarations expose approval events, but do not specify a dedicated approval-resolution method. The [conversation guide](/docs/conversations-and-streaming) documents `respondToInteraction()` for interactions; it does not establish that an `approvalRef` can be passed as an `interactionRef`. Before enabling approval controls, verify the application's supported resolution flow for an authorized reviewer. If no such flow is configured, keep the dependent action unavailable and offer a staff handoff. Do not bypass approval or invent a response payload. > **Completed policy check (fictional procurement assistant)**\ > **Policy read:** `messages: true`, `conversations: true`, `files: false`, `artifacts: false`.\ > **Negotiation:** The request for `runtime-standard-v1` and citations returns `runtime-standard-v1` with no enabled output modules.\ > **UI:** The app shows the conversation composer, hides attachment and artifact controls, and renders no citation panel.\ > **Result:** The user can submit a text question; the interface does not promise a feature the policy did not expose. The example represents one fictional policy response, not a default AgentShelf configuration. A disabled capability results in a capability denial rather than empty data. Handle that state as an unavailable feature, and compare it with the latest policy instead of repeatedly retrying the same call. ## Keep policy checks current Read policy before rendering controls and again when the integration’s operating context changes. Do not cache it longer than the product’s own configuration lifecycle supports. For workspace-backed functions, also check the binding’s enabled capabilities and runtime readiness. For failure triage, follow [external-agent integration troubleshooting](/knowledge/ai-agent-integration/external-agent-integration-troubleshooting); for session setup, see [embedding an AgentShelf agent](/knowledge/ai-agent-integration/embed-an-agentshelf-agent). ### Public References and Secure Bootstrap - Route: https://agentshelf.ai/knowledge/ai-agent-integration/public-references-and-secure-bootstrap - Language: en - Description: A browser may use an agent’s public reference, but an authenticated server must sign the bootstrap assertion and protect its signing credential. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Treat a public reference as an identifier and a bootstrap assertion as a credential. An app can configure a public `externalAgentRef` in its client, but only an authenticated server should mint the signed assertion that vouches for the current user. The SDK then establishes a session whose token must be handled as a bearer credential. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *The browser, server, agent, result, session, and error path mark distinct integration boundaries.* ## Tell identifiers and credentials apart A public reference points to a resource in the external-agent runtime. The SDK’s stored session record includes public refs such as `externalAgentRef`, `sessionRef`, and, when present, `externalUserRef` or `workspaceBindingRef`. Those refs do not replace user authentication, and they do not turn a client-side request into an authorized one. The bootstrap assertion has a different role. The getting-started guide describes it as a short string produced and signed by your backend to vouch for the current end user. The SDK asks for it through `getBootstrapAssertion`; it does not create or sign it. Keep the credential that signs assertions on the server and authenticate the user at the endpoint that mints one. Session storage introduces a third value to protect: the session token. `getStoredSession()` returns public session metadata without the token, but the stored record used by a `RuntimeStorage` adapter includes it. Anyone able to read that storage can act as the session until it expires or is revoked. The SDK defaults to in-memory storage; persistence is a deliberate security and product decision. ## Trace one browser session For an internal request portal, suppose an employee signs in, opens a service assistant, and asks for the status of request SR-204. The app may expose a public agent reference to its browser client. The server still needs to verify the employee before minting an assertion, and the assistant must receive only the policy and tools configured for its job. 1. **Authenticate the user on the server.** Tie the assertion request to the app’s signed-in user; do not accept a user identity supplied only in browser data. 2. **Return an assertion, not the signing secret.** The SDK callback calls the authenticated endpoint and returns the assertion string. Never include the credential that signs it in the client bundle or response. 3. **Create or reuse a session.** `ensure()` obtains an assertion when needed and stores the session token. If a valid stored session already exists, it is reused and the assertion callback is not called. 4. **Choose where to store the session.** The default is in memory. If persistence is required, evaluate which scripts and users can read the adapter; use a separate `storageKey` for each agent embedded on the same page. 5. **End the session intentionally.** On logout, call the server-side revocation method and remove locally stored session data according to the app’s lifecycle. > **Boundary check (fictional portal)**\ > **Browser configuration:** Public `externalAgentRef` only.\ > **Server check:** Employee is authenticated before assertion minting.\ > **Session:** `ensure()` returns a public `sessionRef`; the signing credential stays on the server.\ > **Storage choice:** In-memory for this short visit; no persistent session adapter.\ > **Record consulted:** The approved service-system record SR-204 has status “Under review.”\ > **Result:** The employee sees the “Under review” status after the agent completes the lookup; no assertion-signing secret or session token is displayed. The sample assumes the agent has a separate, authorized way to look up the request. The reference, assertion, and session do not grant a tool that the agent policy does not expose. ## Review the stored state Check the exact value each layer can read: browser configuration, assertion endpoint response, SDK callback, adapter contents, and the object returned by `getStoredSession()`. Do not infer that the token is absent merely because the public getter omits it. For complete setup details, read [getting started](/docs/getting-started) and [sessions and storage](/docs/sessions-and-storage). Continue with [embedding an agent](/knowledge/ai-agent-integration/embed-an-agentshelf-agent) and [workspace bindings](/knowledge/ai-agent-integration/workspaces-and-external-agents). ### Decide When an External Agent Needs a Workspace - Route: https://agentshelf.ai/knowledge/ai-agent-integration/workspaces-and-external-agents - Language: en - Description: Use a workspace only for capabilities that need durable state, then verify the granted capabilities and runtime readiness before relying on them. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An external agent can use an optional workspace for capabilities that need durable state, such as context-library files or scripts. A chat-only integration does not need one. If you request a workspace, use a stable key, check which capabilities were enabled, and wait for the runtime to be ready before showing actions that depend on it. ![Browser, server, agent, and result connected across authentication, session, and error boundaries.](/content/knowledge/visuals/developers.svg) *The diagram shows the browser, server, agent, result, session, and error path; workspace readiness is an additional runtime check for integrations that need durable state.* ## Decide whether the feature needs durable state Start from the user-visible task rather than provisioning a workspace by default. Messaging, conversation history, and artifacts can use the public session without `ensureWorkspace()`. Context-library file operations and features that require script execution depend on a materialized workspace binding and policy support. | Integration need | Workspace decision | | --- | --- | | Send and stream a chat turn | Not needed for this reason alone. | | Fetch an artifact from a completed turn | Not needed for this reason alone. | | Read or update the agent’s context-library files | Required, with policy support. | | Run scripts in the workspace runtime | Required, with `canRunScripts` ready. | The public policy remains part of the decision. A workspace response reports `capabilitiesEnabled`, which can be narrower than `requestedCapabilities`; the existence of a binding does not prove that every requested operation is available. ## Materialize one logical workspace seat The documented client accepts requested capabilities and a `clientWorkspaceKey`: ```ts const workspace = await client.ensureWorkspace({ requestedCapabilities: ['files'], clientWorkspaceKey: 'checkout-support-seat', }); console.log(workspace.workspaceBindingRef, workspace.capabilitiesEnabled); ``` Choose the key for the logical seat represented by your integration, then reuse it for that same seat. The key is idempotent: a repeated request returns the same binding rather than accumulating another one. Do not generate a new random key for every page load. Keep the public workspace reference as a reference; it is not a replacement for session identity or an authorization check. ## Wait for runtime readiness A binding can exist while its runtime is still provisioning. Branch on the status booleans rather than treating a successful binding response as proof that work can start: ```ts const status = await client.getWorkspaceRuntimeStatus(); if (!status.ready) { await client.waitForWorkspaceRuntime({ timeoutMs: 60_000, pollIntervalMs: 2_000, }); } ``` The status includes `ready`, `provisioning`, `failed`, `canRunScripts`, and `hasContainer`, along with lifecycle and status fields. Surface a useful waiting state while provisioning. A timeout means the runtime did not become ready within the requested wait; an aborted wait means the caller cancelled it. Treat `failed: true` as terminal instead of polling indefinitely. For cancellable waits, pass an `AbortSignal` as described in [the workspace guide](/docs/workspaces). > **Completed setup check (fictional support portal)**\ > **Request:** The portal needs a persistent context library for the support agent; ordinary chat works without it.\ > **Workspace:** `ensureWorkspace()` receives `requestedCapabilities: ['files']` and the stable key `support:employee-42`.\ > **Grant:** The response includes a public `workspaceBindingRef` and `capabilitiesEnabled: ['files']`.\ > **Readiness:** The runtime status reports `ready: true`; the app enables the context-library action after also checking policy support.\ > **Repeat:** Reusing `support:employee-42` returns the same binding with `created: false`. This example separates three facts: the app requested a binding, the server reported the enabled capability, and the runtime reported readiness. If any one of those checks is missing, keep the dependent feature unavailable. The workspace API exposes public refs, not raw internal workspace IDs or storage locations. ## Verify the full boundary Before rollout, confirm that the job actually requires durable state, the requested key remains stable for the intended seat, enabled capabilities satisfy the job, and readiness is checked before use. Then test a repeated request and an unavailable runtime path. For session identity and stored tokens, read [public references and secure bootstrap](/knowledge/ai-agent-integration/public-references-and-secure-bootstrap); for files passed into a conversation, see [sessions, conversations, and artifacts](/knowledge/ai-agent-integration/agent-sessions-and-artifacts). ### AI for Cyber Defense - Route: https://agentshelf.ai/knowledge/ai-cyber-defense - Language: en - Description: Use AI agents to investigate exposure, prioritize and prepare repairs, contain exposed credentials, and keep defensive coverage running around the clock. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Attackers already use AI to probe systems at any hour. AI agents let your team defend at the same pace. A defensive agent watches advisories and inventories, investigates what it finds, ranks the exposure, prepares the fix, carries out the steps you have approved in advance, and checks that the work held. Your security staff spend their time on the few decisions that need human judgment instead of the gathering, matching, and follow-up around them. ![An AI agent investigates exposure, prioritizes owned action, and verifies the result, with independent permission checks](/content/knowledge/visuals/cyber-defense.svg) *The agent carries the loop from finding to verified result. Permission checks sit in the connected systems, not in the model.* ## Choose the job you need today - **You need a first defensive agent.** Start with [defensive AI agents](/knowledge/ai-cyber-defense/defensive-ai-agents). Tell the agent which exposure to reduce. It drafts its own job brief from your inventory and policies for you to approve, then runs a small pilot you can spot-check. - **You have forgotten systems that still run.** Use [AI to find, fix, and retire legacy systems](/knowledge/ai-cyber-defense/ai-legacy-system-security). The agent reconciles repositories, deployments, scheduled jobs, and live credentials, then ranks and prepares the patch, replace, or retire work. - **You depend on software or services with sensitive access.** Work through [software supply chain security with AI](/knowledge/ai-cyber-defense/ai-supply-chain-security). The agent checks every release against its expected source and maps what each component could reach if compromised. - **A supplier says your provider keys may be exposed.** Follow [exposed AI API key response](/knowledge/ai-cyber-defense/exposed-ai-api-keys). The agent traces every consumer, stages replacements, verifies recovery application by application, and keeps watching usage. - **An agent is already working overnight.** Review [continuous defensive operation](/knowledge/ai-cyber-defense/operate-defensive-ai-agents). Learn how to confirm what the agent covered, what it fixed, and what still needs a person. For a first pilot, read the introductory guide, choose the workflow that matches your exposure, then use the operating guide before widening coverage. An urgent credential incident needs containment under your incident policy now; it should not wait for an agent pilot. ## Let the agent carry the work, and keep people on the decisions Most defensive work is investigation and follow-through: matching versions against advisories, tracing which systems use a credential, drafting a fix, rerunning a check after the change, and chasing an unanswered escalation. Much of the groundwork is administrative, and an agent can do that too: building and updating the inventory, finding an owner for each system, drafting job briefs and response rules, keeping records, and preparing the operating review. Your operator gives the direction, the agent does the work continuously, and it keeps a complete record as it goes. People stay responsible for a short list of decisions: what the agent is allowed to do, changes to production that fall outside an approved policy, containment choices during an incident, and accepting that an exposure is closed. Each guide names those decisions, shows what the agent prepares for them, and shows what it does on its own. Each guide also includes a fictional worked example and the record format the agent keeps. The agent keeps unknowns visible: an asset it could not check stays unverified, and an application that has not run since a key change stays unconfirmed. ## Set the agent's authority before it acts Give the agent a dedicated identity, scoped permissions, spending limits, and a stop control, all enforced by the connected systems rather than by instructions to the model. Within that authority it acts without waiting. Anything outside it becomes a prepared request to an accountable person. Before you rely on the boundary, have the agent attempt one denied action as well as the permitted ones, and confirm that the systems blocked it. The [Governance learning path](/knowledge/ai-governance) explains the general ownership and review model. Use [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) and the [security review checklist](/knowledge/ai-governance/ai-agent-security-review) to review the defensive agent itself. [Agent integration](/knowledge/ai-agent-integration) covers connecting agents to the systems that supply evidence and carry out actions. > **In AgentShelf** > > These are workflows a team configures with approved context and tools, a named owner, and controls in the connected systems. See [trust boundaries](/platform/trust-boundaries) and [governance and cost controls](/platform/governance-cost-controls), or [request agents](/request-agents) to discuss the first defensive job. ### Use AI to Find, Fix, and Retire Legacy Systems - Route: https://agentshelf.ai/knowledge/ai-cyber-defense/ai-legacy-system-security - Language: en - Description: Let an AI agent find forgotten systems that still run, rank what needs attention, prepare the repair, and verify each patch, replace, or retire decision. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) A forgotten system can keep serving customers and holding working credentials long after its repository was archived. Finding these systems used to mean weeks of manual cross-checking, and that is exactly the work an AI agent does well. It reconciles repository, deployment, dependency, and access records, works out which systems matter, prepares the patch or migration, and retires what is no longer needed. Your team decides how far each repair should go. All asset names, identifiers, dates, and findings in this guide are fictional. ## Connect the repository to the running system No single record tells the whole story: - A repository shows source and maintenance history. - A deployment shows what actually runs. - A scheduled job shows work that happens with nobody watching. - A credential grants access that can outlive all three. Archiving source does not stop a deployment or revoke a credential. The agent links these records for each system. A system only counts as retired when the deployment, scheduler, and credential issuer all confirm it. Anything the agent cannot match stays on the list with an owner and a next step. ![Illustrative diagram linking an archived repository, a running deployment and live access to a single patch, replace or retire decision](/content/knowledge/visuals/ai-legacy-system-security.svg) *An archived repository can still have a live deployment and live access behind it. The agent follows all three to one decision.* ## Let the agent assemble the inventory Give the agent read access to repository metadata, deployments and scheduled jobs, dependency manifests, and credential metadata, and ask it for the inventory. It builds and maintains the list itself. It dates each fact, records its source, and keeps unmatched deployments and unknown owners visible instead of dropping them. Keep secret values out of the agent's inputs and records entirely. It works from credential identifiers, owners, and dates, and it confirms effective permissions with the issuing service or IAM policy, because a secret manager's description can be incomplete. See [review an agent's tools and data access](/knowledge/ai-governance/review-agent-tools-and-data-access). The agent treats source comments, dependencies, and retrieved files as untrusted input. It analyzes code without running it where possible. When a check must run code, it does so in an isolated environment under a scoped identity. ## Let the agent find the exposure that needs attention The agent looks for dangerous combinations: a vulnerable service that accepts internet traffic, sensitive data that its process can reach, or credentials that open other systems. It treats each proposed attack path as a hypothesis and then tests it: - Does the deployed version match the advisory? - Is the vulnerable code reachable? - What do the credentials actually permit? An unsupported runtime alone does not prove an exploit, and a clean scan covers only what the scanner reached and recognized. The agent records both limits. ## Rank what to patch, replace, or retire The agent ranks systems by business use, reachability, sensitive access, dependencies, and consequences, and proposes one of three outcomes: - **Patch** a needed system that has a supported fix. - **Replace** one that cannot be maintained safely. - **Retire** one whose business need has ended. Compare a public customer portal with an archived internal prototype. Both repositories have been quiet for over a year, but the portal still serves customers and exports data every night. The agent puts it first and does the investigation the owner would otherwise have to do. > **Exposure and disposition record: `portal-prod-03` (illustrative)** > > - **Identity:** Repository `portal-web`, archived 2024-06, last commit 2024-05. Deployment active and internet facing, last deployed 2025-11. Business use: customer logins and account pages. Job `nightly-export` runs daily at 01:30 to a reporting store. > - **What the agent confirmed (2026-10-20):** > - Public login is reachable. > - The runtime is a version line outside regular support. The vendor's last fix for that line does not cover advisory `ADV-PRT-22`, which affects the deployed version. > - In staging, the vulnerable route is reachable without signing in. > - Issuer records show `cred-portal-app-01` can read the customer table. > - `cred-export-02` writes to the reporting store, and one consumer, `bi-dash`, reads that store. > - The previous owner left in 2025-03. > - **What the agent prepared:** > - A migration branch moving the portal to a supported runtime, with dependency updates and passing tests in staging. > - A temporary rule that blocks the vulnerable route at the edge. > - A migration plan for `nightly-export` that keeps `bi-dash` working. > - **Decision for the owner:** Approve the edge rule now, then choose between replacing the portal on the prepared branch or retiring it with the business owner. Interim owner: platform lead, proposed by the agent from deployment history and confirmed 2026-10-20. Status: open, decision prepared. > **Exposure and disposition record: `prototype-07` (illustrative)** > > - **Identity:** Repository archived; business use ended, confirmed with the product owner on 2026-10-19. > - **What the agent confirmed (2026-10-20):** Deployment check `DEP-707` and scheduler check `JOB-707` find no active deployments or jobs in the reviewed accounts. No consumer has read credential `cred-proto-07` in 90 days. > - **What the agent did:** The credential meets every condition of the pre-approved retirement policy, so the agent revokes it at the issuer and retrieves receipt `REV-707` (2026-10-20). It then links that receipt in the secret catalog and archives the asset record. > - **Result:** Retirement verified for the reviewed accounts through deployment, job, and issuer evidence. No action needed from a person. The agent keeps one record in this format for every system it finds. Use the blank version to set what you expect it to report: > **Exposure and disposition record (blank)** > > - **Identity:** Asset ___ · Repository status and last activity ___ · Deployment status and last deploy ___ · Runtime and dependencies ___ · Scheduled jobs ___ · Business use ___ > - **What the agent confirmed:** Reachability ___ · Credential IDs (never values) ___ · Issuer or IAM permissions ___ · Tested attack path ___ · Remaining uncertainty ___ · Sources and dates ___ > - **What the agent prepared or did:** Patch, migration, or temporary control ___ · Actions taken under policy ___ · Evidence ___ > - **Decision for the owner:** Patch, replace, or retire ___ · Owner ___ · Reviewed scope ___ · Status ___ ## Let the agent carry out the chosen work AI makes the repair itself cheaper. The agent can explain unfamiliar code, map dependencies, draft the patch or migration, write tests, and run them in staging. It applies that effort to the top of the ranked list, not to whatever is easiest to fix. Decide in advance which changes the agent makes on its own; the agent can draft that policy from the ranked list, but a person approves it. The issuer and deployment systems enforce it. In the example, the agent's identity can revoke a credential only when it is tagged for retirement and has no recent consumers. That is why the agent could retire `prototype-07` on its own, while `cred-export-02` waits on the `bi-dash` migration and an owner's decision. If a credential may already be compromised, contain it now under your incident policy rather than waiting for the cleanup. Changes to the agent itself follow [agent change management](/knowledge/ai-governance/ai-agent-change-management). ## Close the exposure with evidence After each change, the agent rechecks the deployed result and its effect on the exposure. For a retirement, it keeps the deployment, scheduler, and issuer-side evidence together. Deleting a secret-manager entry does not prove revocation, so the agent asks the issuer. Missing ownership or unknown dependencies stay open, with the agent following up until someone answers. Point the agent at one application and have it reconcile that system's records end to end. Start with [defensive AI agents](/knowledge/ai-cyber-defense/defensive-ai-agents) if no job brief exists yet, and use the [governance checklist](/knowledge/ai-governance/ai-agent-governance-checklist) for program ownership and review dates. > **In AgentShelf** > > Configure an agent to assemble approved records, prepare repairs, and track unresolved items. Production repairs and retirements still need testing and the authority your systems enforce. See [governance and cost controls](/platform/governance-cost-controls), or [request agents](/request-agents) to discuss cleanup. ### Software Supply Chain Security with AI - Route: https://agentshelf.ai/knowledge/ai-cyber-defense/ai-supply-chain-security - Language: en - Description: Use an AI agent to check every release against its expected source, map what each trusted component can reach, and hold unexpected changes before they reach production. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) The biggest security risk may not be the code your team writes. It may be the code and services your team trusts with credentials, data, and update authority, and AI adoption has added many of them: gateways, model providers, connectors, and tool servers. Each one ships updates, and checking every release by hand does not keep pace. An AI agent can do that checking continuously. It maps what you depend on, compares every new release with its expected source and build, works out what each component could reach if compromised, and stops a release that does not match before it reaches production. Your component owners make the trust decisions the agent cannot. All component names, identifiers, versions, times, and findings in this guide are fictional. Credential references contain no secret values. ## Let the agent map what the workflow trusts Point the agent at your package manifests, image registries, deployment configuration, and supplier records. It lists packages, images, gateways, connectors, agent skills, tool servers, hosted services, and model providers. For each one, it records who can see data, hold credentials, publish updates, or change behavior remotely. It includes suppliers that store your secrets, even when none of their software runs on your servers. Each component needs a business owner. The agent proposes one from commit history, deployment records, and billing, and asks the likely owner to confirm. The [security review checklist](/knowledge/ai-governance/ai-agent-security-review) covers wider agent intake; this guide covers the dependencies around it. ## Let the agent trace each release to the artifact you run For every update, the agent follows the chain from source repository to build, publisher, downloaded artifact, and deployment. It records the approved source, publisher, version, and deployed digest. Tags can point to different bytes over time, so the agent pins its comparison to digests. Inspecting source and identifying the deployed artifact answer different questions, and the agent records both. ![Illustrative chain from source and release through the deployed artifact to granted access, with a hold point for unexpected changes](/content/knowledge/visuals/ai-supply-chain-security.svg) *The check runs before production access is granted, so a mismatched release stops at the hold point.* ## Check provenance and understand its limits Where your tools support it, the agent verifies signatures and build attestations against approved identities and compares artifact fingerprints. It pins deployments to digests rather than tags that can move. A matching fingerprint identifies bytes. It does not prove they were built from approved source, and a valid signature can still come from a compromised upstream process. That is why the agent checks the signer, source, and build evidence together. Missing provenance is recorded as an open gap, never as a pass. ## Let the agent map what each component can access For each component, the agent records credential identifiers, readable data, permitted actions, connected accounts, and reachable systems. It answers the question an attacker would ask: what could this component read, change, send, or unlock if compromised? It then drafts how to narrow or revoke each grant, and how long that would take. A gateway may hold provider keys and read request traffic. A connector may write business records. Broad access can make a familiar component a higher priority even when its provenance checks pass. Use [tool and data access review](/knowledge/ai-governance/review-agent-tools-and-data-access) and [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) for per-operation checks. [LLM gateway vs. AI agent platform](/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform) separates routing and credential scope from agent execution. ## Hold the unexpected change, then investigate it Candidate gateway 2.8.0 arrives at 11:02. Its fingerprint matches the published release, but its release record names `gateway-releases-mirror` instead of the approved source `gateway-releases`. The deployment pipeline promotes a release only after the agent's verification check passes, so the agent's failed check holds run `pipe-7731` at 11:04. Production stays on 2.7.4. The agent cannot promote a release or override the rule; it can only decline to sign off. The agent then investigates the hold: - The mirror's build attestation names a builder identity that is not on the approved list. - The approved source has no 2.8.0 release yet. - The candidate requests one new permission, outbound access to an unlisted host. It quarantines the candidate and sends the platform owner one finding with the evidence attached. The owner has a single question to answer: is the mirror a legitimate source? The agent has already worked out why the release should not run until that answer comes. The agent also proposes the other hold conditions from your release history, and once the owner approves them it applies them the same way every time: an unexpected publisher, a missing or different signer, a mismatched digest, or new permissions. > **Trust worksheet: gateway release review (illustrative)** > > - **Provenance:** Component `gw-prod`, routing internal-agent model requests. Owner: platform team. Approved source `gateway-releases`; publisher recorded in release policy. Candidate 2.8.0, digest `sha256:9f2c…41aa`, received 11:02. Deployed 2.7.4, digest `sha256:51b0…07d3`, unchanged at 11:06. Fingerprint matches; source is an unapproved mirror; builder identity unrecognized; no matching release at the approved source. Digests abbreviated for display. > - **Access:** Credential references `cred-gw-p1`, `cred-gw-p2`, `cred-gw-p3`. Reads request traffic and holds provider keys; no business-record writes. Candidate adds outbound access to an unlisted host. Consequence of compromise: credential exposure and request interception. > - **What the agent did:** Failed its verification check, which held `pipe-7731` at 11:04. Quarantined the candidate, investigated the mirror, and sent the owner one finding with evidence. > - **Decision for the owner:** Whether `gateway-releases-mirror` is a legitimate source. Until then the candidate stays quarantined. > **Trust worksheet: hosted supplier access (illustrative)** > > - **Provenance:** Contracted host `host-sup-a`, running `app-internal-01` and `app-internal-02`. Owner: platform team. The supplier manages deployment. The agent checked exported configuration `cfg-118` on 2026-10-20 and reviewed 90 days of supplier change notices; none reported secret-storage changes. These records do not independently verify the supplier's build process. > - **Access:** References `secret-app01-db`, `secret-app01-api`, `secret-app02-api`. The supplier stores the secrets and injects them at runtime. Reach: the database and provider accounts those secrets unlock. > - **What the agent did:** Mapped all three secrets to their issuers and consumers. Rehearsed issuer-side replacement for `secret-app02-api` in staging; replacement took 12 minutes end to end. > - **Decision for the owner:** None now. High priority because of reach; the agent repeats the review when the supplier sends its next change notice. The agent keeps one worksheet in this format per component. Use the blank version to set what you expect it to report: > **Software and supplier trust worksheet (blank)** > > - **Provenance:** Component ___ · Business use ___ · Owner ___ · Approved source and publisher ___ · Candidate version and digest ___ · Deployed version and digest, checked at ___ · Signature, attestation, and fingerprint evidence ___ > - **Access:** Credential IDs ___ · Data and action scope ___ · Reachable systems ___ · Consequence of compromise ___ · How to narrow or revoke ___ > - **What the agent did:** Checks run ___ · Discrepancies found ___ · Holds and their enforcing system ___ · Investigation results ___ > - **Decision for the owner:** Question ___ · Priority and rationale ___ · Still unverified ___ · Status ___ ## Prepare for compromise and recovery For important components, the agent keeps the response owner, dependent consumers, and source of current remediation guidance on file. If a supplier announces a compromise, the agent preserves artifact identity and logs, holds further rollout, and pulls the specific advisory. It then works each exposed credential through issuer-side containment and consumer recovery. Removing a package alone does not establish recovery, because persistent changes may need further cleanup or a rebuild. Start with one gateway or connector and have the agent map it from source and supplier through artifact and access. [Defensive AI agents](/knowledge/ai-cyber-defense/defensive-ai-agents) shows how to set up update checking as a testable job. > **In AgentShelf** > > Configure an agent to collect release evidence, investigate discrepancies, and report to the component owner. Your deployment systems must enforce the hold. See [trust boundaries](/platform/trust-boundaries), or [request agents](/request-agents) to discuss a supplier-review workflow. ### Defensive AI Agents: What They Do and Where to Start - Route: https://agentshelf.ai/knowledge/ai-cyber-defense/defensive-ai-agents - Language: en - Description: Choose a first defensive job for an AI agent, set the authority it acts within, and test whether it finishes the work with evidence you can verify. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) A defensive AI agent does the routine work of a security job around the clock. It reads new advisories, checks your inventory, investigates what it cannot confirm, prepares and tests fixes, applies the ones you have approved in advance, and verifies the result. Attackers already use AI to probe systems at any hour, and a defense that only runs during office hours leaves the rest of the day open. Your team decides what the agent may do before it starts. The connected systems enforce that authority, including permissions, spending limits, and a stop control. When a step falls outside it, the agent hands an accountable person a prepared decision, not a raw alert. ![Illustrative flow from an emergency advisory through inventory matching to an owned action queue, with unverified items escalated](/content/knowledge/visuals/defensive-ai-agents.svg) *The agent turns one advisory into finished, prepared, and escalated work, so people only see what needs them. All asset names, identifiers, versions, times, and results in this guide are fictional.* ## Define the job before choosing the tools Tell the agent which exposure to reduce and what finished looks like. It turns that direction into a job brief. It reads your inventory, existing policies, and recent advisories to propose the asset scope, sources, and actions, and then you approve or adjust the draft. Scanners, inventories, and scheduled checks keep supplying facts. The agent connects that evidence, investigates gaps, and carries the work forward. [Define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job) covers context, actions, and handoff. A defensive brief also needs the asset scope, the actions the agent may take on its own, and the decisions it must bring to a person. Those last two are yours to set; the agent can only propose them. ## Start with one of six defensive jobs Choose one workflow to configure or build. In each, the agent does the investigation and follow-through: - **Patch watching:** the agent matches each advisory to your deployments, ranks affected assets, tests the fix, and applies it where policy allows. - **Key rotation:** the agent finds every application that uses a credential, stages the replacement, and confirms each one switched over. - **Update checking:** the agent compares each new release with its approved source and version and holds anything unexpected. - **Spending watch:** the agent investigates usage spikes back to the key, account, and workload responsible. - **Forgotten-system discovery:** the agent reconciles repository, deployment, and access records and ranks systems nobody owns. - **Incident triage:** the agent gathers logs and alerts into one timeline, drafts the update, and assigns follow-up. For unapproved tools staff adopted, start with [shadow AI governance](/knowledge/ai-governance/shadow-ai-governance). ## Choose the first job by exposure and usefulness Ask the agent to survey the candidates first. It can report which reachable systems hold sensitive access, which sources it can read reliably, and how many open findings each job would address. You then weigh what an unresolved exposure would cost the business and which actions you are comfortable approving in advance. Finding another thousand vulnerabilities is easy to celebrate. Knowing which ten to fix first, fixing them, and proving the fixes held is where the value is. An agent can do all three when the job is bounded and the results can be checked against trusted records. [Choose an AI agent use case](/knowledge/agent-design/choose-an-ai-agent-use-case) gives the wider selection method. ## Follow an advisory through the workflow At 02:10, run `fic-0210` picks up advisory `ADV-FIC-104`, which names server component versions 4.2.0 to 4.2.3. The agent checks four approved deployments and works each one to the furthest point its authority allows: - **`wiki-int`** is affected but internal only. It falls under the team's pre-approved patch policy, so the agent patches it and verifies the result. - **`portal-prod`** is affected and customer facing. The agent tests the fix in staging and books it for the owner's approval. - **`billing-api`** is unaffected. - **`reports-02`** cannot be checked. The agent tries a second approved source, then escalates with its diagnosis. > **Defensive agent job brief: patch watching (illustrative)** > > - **Exposure:** Deployments affected by an emergency advisory. > - **Trigger:** New advisory from an approved source. > - **Asset scope:** Approved deployments of the named component. > - **Approved sources:** Advisory feed, deployment inventory, package manifests, reachability records. > - **Tool identity:** Dedicated service identity for these reads and actions. > - **Actions the agent takes on its own:** Match versions, rank assets, test fixes in staging, open and update remediation items, and patch internal systems in the approved maintenance window. After each change, recheck the deployed version. > - **Decisions brought to a person:** Production changes to customer-facing systems, plus any shutdown, restart, or out-of-window change. > - **Enforcement boundary:** The deployment system allows patch operations only on hosts tagged `internal` during the window and denies stop and restart operations. > - **Decision owner:** Each asset's platform owner. > - **Escalation condition:** A lookup that fails on every approved source, conflicting evidence, or a requested change outside policy. > - **Done when:** Every asset is patched and verified, confirmed unaffected, awaiting a prepared decision, or escalated with a diagnosis. > **Action queue from run `fic-0210` (illustrative)** > > - **`wiki-int`:** Version 4.2.2, checked 02:12. Internal only, so the pre-approved policy applies. The agent patches it in the 02:30 window and reads back version 4.2.4 at 02:41. Exposure: closed, with evidence attached. > - **`portal-prod`:** Version 4.2.1, checked 02:13. Internet reachable, with customer sessions and data at risk: priority 1. The agent applies the vendor fix in staging and passes the regression suite at 02:34. It opens `REM-881` with the advisory, version, reachability evidence, and test results, and proposes the 06:00 window. Waiting on: portal owner approval. > - **`billing-api`:** Version 4.3.0, checked 02:14, outside the affected range. Unaffected; no action needed. > - **`reports-02`:** The inventory lookup times out twice at 02:15. The agent reads the package manifest from the last deployment record instead, but that record is 40 days old. It marks the asset unverified and escalates to the platform operator with both failures and the stale-record date. Not counted as covered. At 06:00 the portal owner approves `REM-881`. The agent deploys the fix, reads back version 4.2.4 at 06:09, reruns the reachability check, and closes the item. The owner reviewed one prepared change instead of investigating four systems overnight. The agent drafts a brief in this format for each new job, and you approve it. Use the blank version to set what you expect it to fill in: > **Defensive agent job brief (blank)** > > - Exposure: ___ > - Trigger: ___ > - Asset scope: ___ > - Approved sources: ___ > - Tool identity: ___ > - Actions the agent takes on its own: ___ > - Decisions brought to a person: ___ > - Enforcement boundary (systems enforcing it): ___ > - Decision owner: ___ > - Escalation condition: ___ > - Done when: ___ ## Decide what the agent may do This is the part that stays with people. Give the agent a dedicated identity that can be limited and revoked. Then decide which actions it takes on its own and which it prepares for a person. Write that split into the systems themselves, not only into the agent's instructions. The agent can then run the boundary tests against both sides. In a boundary test after `fic-0210`, a reviewer asks the workflow to stop `portal-prod` using the agent's identity. The deployment system returns a permission denial, and the deployment stays unchanged. The agent records the denial and creates escalation `ESC-104` at 02:20 with the request attached. Inventory access beyond the assigned component has not been tested yet, so expansion waits for that test. The agent writes up each test with intended policy, observed behavior, and untested scope kept separate, following the [security review checklist](/knowledge/ai-governance/ai-agent-security-review). Use [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) and [human review](/knowledge/agent-design/human-in-the-loop-ai-agents) to design enforcement and escalation. ## Test the result before widening coverage The fictional run and boundary test produce these results: | Case | Expected | Observed | Result | |---|---|---|---| | Affected, pre-approved `wiki-int` | Patched in window, version verified | 4.2.4 read back at 02:41 | Pass; closed | | Affected, customer-facing `portal-prod` | Fix tested, prepared change, no unapproved deploy | `REM-881` with test results; deployed after approval | Pass; closed at 06:09 | | Unaffected `billing-api` | Recorded pass with evidence | Version check, 02:14 | Pass | | Unavailable `reports-02` | Second source tried, unverified, escalated | Stale record flagged; operator assigned | Pass | | Stop `portal-prod` | System denial, escalation, no change | Permission denied; `ESC-104`; unchanged | Pass | Fail any unsupported verdict, false coverage claim, or production change outside policy. Have the agent compare its results with your existing scanners and checks and report where they overlap and where each one missed something. [Evaluate an AI agent](/knowledge/ai-governance/evaluate-an-ai-agent) separates outcome, process, boundaries, and recovery scores. For the pilot, let the agent run one brief against a small inventory and spot-check a sample of its verdicts by hand. Then point the agent at [legacy systems](/knowledge/ai-cyber-defense/ai-legacy-system-security) or [trusted software and services](/knowledge/ai-cyber-defense/ai-supply-chain-security). > **In AgentShelf** > > Configure a defensive workflow with approved context and tools, an owner, and limits enforced in connected systems. See [the platform overview](/platform) and [trust boundaries](/platform/trust-boundaries), or [request agents](/request-agents) to discuss a first job. ### Responding to Exposed AI API Keys - Route: https://agentshelf.ai/knowledge/ai-cyber-defense/exposed-ai-api-keys - Language: en - Description: Use an AI agent to trace every consumer of an exposed key, prepare containment, switch applications to a replacement, and verify recovery with a complete response record. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) When a supplier warns that your provider keys may have been exposed, assume someone else can use them until the issuer revokes them. Deleting the supplier's saved copy does not revoke anything. Follow the issuer's current incident instructions. An agent can carry most of this response. It traces every application and job that uses the key, checks what the key can reach, and watches usage at the provider. It also prepares the replacement, switches consumers over, and confirms each one recovered. Your response owner makes the containment decision. The agent makes sure that decision is fast, informed, and fully carried out. All notices, identifiers, times, and results in this guide are fictional. Records contain key references only, never secret values. ## Let the agent establish the affected credential As soon as the notice arrives, the agent opens a response record. It logs the notice, provider account, key identifier, claimed exposure period, and response owner, and keeps confirmed facts, supplier claims, and open questions apart as the investigation changes. A provider key, a gateway-only credential, and an application login have different issuers and revocation paths. The agent opens one record per credential so each revocation and recovery closes on its own evidence. ## Let the agent trace access and dependent systems The agent searches approved configuration and deployment records for every application, job, build step, and integration that uses the key. That includes indirect consumers that read it from a shared store. In this example it finds two: `app-prod` and the scheduled job `nightly-report`. Nobody works with a nightly job directly, so it is easy to miss, and that is exactly the consumer that fails silently after a hurried rotation. The agent then confirms the key's granted scope and reachable resources with the issuer. Some keys only allow model requests; others reach stored files or account resources. It searches provider and application records for credentials or sessions created through the exposed access, and opens a containment item for each one it finds. Anything it cannot confirm stays marked unverified, with an owner. The agent works from configuration references and metadata. Secret values stay out of its inputs and outputs. [Software supply chain security with AI](/knowledge/ai-cyber-defense/ai-supply-chain-security) covers keeping this inventory current before an incident forces the question. ## Decide containment, then let the agent carry it out Routine rotation and suspected compromise follow different tracks. The steps below are an operating model; issuer instructions and the incident itself set the exact sequence. **Routine rotation** is scheduled replacement with no suspected exposure. The agent can run it end to end under a pre-approved policy. It creates a restricted replacement, updates and verifies each consumer, then revokes the old key at the issuer. **Suspected compromise** needs prompt containment, even without visible misuse. Delayed or empty usage records do not clear a potentially leaked key. The response owner chooses between two options: - Revoke or disable the key immediately and accept that some consumers will break. - Make a controlled replacement with a brief overlap, where issuer guidance allows it. The agent's job is to make that choice quick and well informed. It does not wait for a complete consumer inventory before asking. Before any replacement goes out, the agent establishes where the compromise happened. It checks the secret store, build, and deployment logs and records what it reviewed. It distributes new keys only through a trusted store and deployment path, never back into the supplier's configuration until the owner accepts the supplier's containment evidence. If your own host or build environment may be compromised, follow the advisory's cleanup or rebuild instructions first. A lack of intrusion evidence alone does not prove an environment clean. In this example, the agent finds overnight usage at about three times the usual level, with no matching activity from either consumer. By 09:20 it has prepared two things: replacement key `key-prod-015` in the team's reviewed secret store, and approval request `APR-1042`. The request names both consumers and what immediate revocation would break, plus the expected recovery time. The owner approves immediate revocation at 09:47. Revocation is an approval-gated action. The agent's identity can revoke the key at the issuer only after the owner approves `APR-1042`, and the issuer enforces that rule. [Human review](/knowledge/agent-design/human-in-the-loop-ai-agents) and [agent handoffs](/knowledge/agent-design/agent-handoffs) cover acknowledgment and escalation when an approval is slow to come. ![Illustrative response showing containment at the issuer, replacement into a trusted environment, and verification of each consumer, with one consumer still pending](/content/knowledge/visuals/exposed-ai-api-keys.svg) *Revocation alone does not finish the response. Recovery stays open until the last consumer is confirmed on its replacement.* ## Let the agent watch usage at the provider The agent reviews provider usage and billing for the exposure period and keeps checking afterward. It assigns unexplained requests for investigation and records gaps in the data, when complete records should be available, and when it will check again. Gateway evidence covers only traffic that passes through the gateway. A stolen provider key can bypass both the gateway and its budget, so the agent reads usage at the provider itself and applies provider-side restrictions and alerts where they exist. [LLM budget management](/knowledge/ai-governance/llm-budget-management) explains supported request-path coverage. ## Let the agent verify each consumer and the old credential The agent keeps the issuer's confirmation of revocation as evidence. It then confirms that every consumer runs on the replacement, including scheduled jobs. A job that has not run since the change stays unverified until the agent checks its next run. > **Credential response record (illustrative)** > > - **Exposure:** Notice `SUP-2026-014`, Day 0 at 09:12. Provider: production account A. Key `key-prod-014`, model requests only, with no administrative access in the issuer record; it can run up billable usage. The supplier says the exposure lasted from two days before Day 0 until the notice; recorded as a supplier claim. Consumers found by the agent: `app-prod`, `nightly-report`. No related credentials or sessions found by 11:00; full recheck scheduled. Owner: response owner R. > - **Containment:** The agent flagged unexplained usage at three times the usual level and sent `APR-1042` at 09:20 with the impact of each option. The owner chose immediate revocation at 09:47. The agent revoked the key at 09:49, and the issuer confirmed revocation at 09:50. The agent reviewed the secret store, build, and deployment logs and found no intrusion evidence; the review scope is recorded. The replacement went out only through that path. The supplier configuration was excluded pending its containment evidence, and the supplier's copy was later removed as housekeeping. > - **Recovery:** `app-prod` switched to `key-prod-015` at 09:56, and the agent's checks passed. The agent updated the `nightly-report` configuration at 10:05, but the scheduler does not allow on-demand runs, so the job stays unverified until it next runs at 01:30. Usage is partly reviewed; complete records are expected on Day 1, and the recheck is scheduled. Status: recovery incomplete; the agent checks the 01:30 run and the Day 1 usage records. The agent keeps one record in this format per credential and gives every unknown an owner. Use the blank version to set what you expect it to report: > **Credential response record (blank)** > > - **Exposure:** Notice and time ___ · Provider account and key ID ___ · Granted scope and resources ___ · Exposure period and source ___ · Consumers ___ · Related credentials or sessions ___ · Owner ___ > - **Containment:** Routine or suspected compromise ___ · Decision, reason, owner, and time ___ · Any overlap (deadline, restrictions, responder) ___ · Trusted-environment checks and distribution path ___ · Approval ___ · Revocation time and issuer evidence ___ > - **Recovery:** Each consumer (replacement ID, applied at, verification) ___ · Usage period, gaps, and recheck ___ · Unresolved work ___ · Status ___ ## Keep the response record until the work is complete The agent tracks each step as prepared, approved, executed, and verified. It closes the record only after every consumer is verified, the final usage review is done, and any downstream access has a decision. Open items get a follow-up date, and the agent keeps them moving. Before the next notice arrives, have the agent build and maintain a list of each key's issuer, response owner, consumers, revocation path, and trusted replacement path. Then the first hour of an incident becomes a decision rather than a search. > **In AgentShelf** > > Configure an agent to trace consumers, prepare and carry out approved steps, and maintain the record. Owners or pre-approved policies authorize revocation. AgentShelf budgets cover supported paths, not direct use of a stolen key. See [governance and cost controls](/platform/governance-cost-controls), or [request agents](/request-agents) to discuss credential response. ### Operating Defensive AI Agents Around the Clock - Route: https://agentshelf.ai/knowledge/ai-cyber-defense/operate-defensive-ai-agents - Language: en - Description: Keep a defensive AI agent working overnight, confirm what it covered and fixed, catch the checks it missed, and make sure the few items that need a person get one. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) A defensive agent works the night shift. By morning it should have checked every asset that was due, fixed what policy allows, recovered from its own failed checks where it can, and chased any escalation nobody answered. The operator's job is to confirm that it did, which should take minutes rather than a morning. The operator also deals with the short list of items that genuinely need a person. This guide follows the patch-watching job from [defensive AI agents](/knowledge/ai-cyber-defense/defensive-ai-agents) through one night. All identifiers, counts, times, and results in this guide are fictional. ## Define what continuous coverage means for this job Ask the agent to propose the coverage plan: which assets are due, which sources it reads, how often it checks, and how fresh evidence must be. It bases the proposal on the inventory, past findings, and how quickly your team can act. The operator approves the plan and names who operates the job. Hourly checks only help if the agent can act on findings, or reach someone who can. When the agent reports "nine of ten checked," that count covers the known assets that were due in the period. An asset missing from the inventory falls outside that count entirely, so inventory completeness needs its own check, which the agent can also run. ## Watch the agent as well as the systems it checks The agent records every successful read, failure, stale result, and missing signal for each source and asset. A scheduler that reports success can still leave coverage incomplete, so the agent's own record is what counts. An independent monitor watches the agent from outside. It checks that each run started, finished, and delivered its record, and it raises source failures and unanswered escalations. Keep that monitor, and the records it protects, out of the agent's reach so the agent cannot disable or rewrite them. In the example, monitor `mon-01` reports two lookup failures at 03:12 and 03:13. [AI agent observability](/knowledge/ai-governance/ai-agent-observability) covers available records and incomplete telemetry. Missing records leave coverage unknown, never assumed. ![Illustrative operating loop showing assets due, checked, unknown and escalated, observed by an independent monitor](/content/knowledge/visuals/operate-defensive-ai-agents.svg) *The monitor sits outside the agent, so a silent failure still shows up as a gap rather than a pass.* ## Let the agent recover from its own failures Give the agent clear rules for what to do when a check fails, and let it act on them without waiting. Bounded retries are safe for reads. If an earlier action may already have taken effect, the agent confirms its outcome before retrying it. [AI agent failure modes and recovery](/knowledge/ai-governance/ai-agent-failure-modes) covers retry, correction, stop, and handoff decisions. In the example, after its retries fail, the agent switches `assets-09` to a second approved source and gets a current version at 03:40. `reports-02` has no second source, so the agent marks it unknown and sends escalation `ESC-210` to the on-call operator at 04:12. The agent drafts the rules for harder cases from your incident policy: persistent source failure, lost permissions, conflicting evidence, and requests outside its authority. The operator approves them. Two settings stay with people: who can pause the job, and the deadline for a second contact, so the agent follows up an unanswered escalation instead of waiting quietly. The agent can test that the pause works. ## Let the agent turn findings into owned work The agent links identity, deployment, build, and application evidence into one investigation wherever the records support the connection, and keeps each source and time. It gives each finding a stable identity, so a repeat updates the existing item instead of opening a new one. It also tracks each stage separately: new, repeated, acted on, assigned, acknowledged, and verified as resolved. The agent cannot close an escalation it created. Only the person who receives it can acknowledge it, and the ticketing system enforces that. [Agent handoffs](/knowledge/agent-design/agent-handoffs) explains receiving-side completion states. ## Measure coverage and useful outcomes The agent compiles the operating review itself. It covers due assets with current evidence, unknowns, accepted and rejected findings, the work the agent completed without a person, verified remediation, operating cost, and operator time. The operator reads the review and decides what to change. Operator time should fall as the agent takes on more of the work. The agent also runs replay cases on a schedule to test for misses. These replay tests use controlled inputs and are separate from the overnight run. In `R-03`, the scope export deliberately leaves out `reports-02`, while the expected inventory still includes it: | Replay case | Expected | Observed | Result | |---|---|---|---| | `R-01`: affected, in scope | Owned item with evidence | Item opened with evidence | Pass | | `R-02`: unaffected, in scope | Pass with version evidence | Recorded pass with evidence | Pass | | `R-03`: `reports-02` left out of export, kept in expected inventory | Flag missing due asset as unverified | No entry or omission alert | Fail; agent drafts an inventory reconciliation check, export owner approves, case reruns | The overnight run did attempt `reports-02`. The replay asks a different question: would the workflow notice if an asset disappeared from its input? Keep both results, and do not combine their coverage counts. The agent also samples its own closures. Of 48 items closed in the prior seven days, it rechecked 12 against current deployed versions. One lacked deployed-version evidence, so the agent reopened it. Always state the population, sample, period, and result together. > **Defensive agent operating record: Day 0, 00:00 to 06:00 (illustrative)** > > - **Coverage:** > - Job `patch-watch v12`; scope is 10 known due assets, checked hourly, with evidence that must be under 2 hours old. Monitor `mon-01` saw all 6 runs start, finish, and write records. > - Eight assets have current inventory and version reads from 05:40 to 05:47. > - `assets-09` failed at 03:13 and again after two retries. The agent switched sources and recovered at 03:40. > - `reports-02` last succeeded at 02:58 and went stale at 04:58. Every check from 03:12 on has failed, and no second source exists. > - At 06:00: 9 current, 1 unknown. > - **Findings and actions:** No new findings. Repeat `FIND-311` on `crm-sync`: the agent refreshed the version evidence at 05:42, updated `REM-905`, and linked deployment `dep-5521` and identity evidence under `INV-88`. Actions completed by the agent: one source switch, one item update, and one closure-sample reopen. > - **Response:** The agent sent `ESC-210` for `reports-02` at 04:12. It was still unacknowledged at 06:00, so the agent sent the second contact on schedule at 06:30, and on-call operator O. acknowledged at 06:34. No remediation was needed overnight. Open work: restore the `reports-02` lookup. The agent writes a record in this format at the end of each period. Use the blank version to set what you expect it to report: > **Defensive agent operating record (blank)** > > - **Coverage:** Job and configuration ___ · Period ___ · Due scope ___ · Cadence and freshness ___ · Independent monitor ___ · Last successful read per source and asset ___ · Recovered by the agent ___ · Current ___ · Unknown (asset, failure, time, owner) ___ > - **Findings and actions:** New and repeated IDs and states ___ · Linked evidence ___ · Actions completed by the agent ___ · Separate replay results ___ · Closure sample, population, period, and result ___ > - **Response:** Escalation IDs, sent and acknowledged times ___ · Follow-ups sent ___ · Operator ___ · Verified work ___ · Open work and owners ___ Operating review summary (illustrative; the replay and sampling windows are separate from the overnight run): | Measure | Result | |---|---| | Overnight coverage | 9 of 10 current; 1 unknown | | Recovered by the agent | 1 of 2 failed lookups | | Findings | 1 repeat confirmed; 0 rejected | | Response | `ESC-210` acknowledged at 06:34 after the agent's follow-up | | Closure sample, prior 7 days | 12 of 48 rechecked; 1 reopened | | Separate replay | `R-03` failed; agent-drafted fix approved | | Cost and effort | Run cost recorded; 8 operator minutes | ## Review changes before expanding Before any change, the agent produces a comparison of verdicts, misses, resource use, and operator time against the previous baseline. When models, tools, sources, permissions, or assets change, it reruns the full workflow and the affected subtasks and reports the difference for approval. Use [agent change management](/knowledge/ai-governance/ai-agent-change-management) and the [governance checklist](/knowledge/ai-governance/ai-agent-governance-checklist). Close any coverage or response gap before you approve more scope for the agent. > **In AgentShelf** > > Verify which activity, error, usage, and cost records your supported paths provide; coverage varies by configuration. Pair available records with independent monitoring and an owner who responds. See [governance and cost controls](/platform/governance-cost-controls), or [request agents](/request-agents) to discuss defensive operation. ### AI Agent Foundations - Route: https://agentshelf.ai/knowledge/ai-foundations - Language: en - Description: Understand AI agents, harnesses, and the architecture around a model before choosing your first workflow. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An AI agent makes more sense when you look at the whole working system: the job, the model, the information it uses, the actions it can take, and the boundaries around those actions. ![A four-step path from understanding and comparison to architecture and harness](/content/knowledge/visuals/foundations.svg) This path is for people exploring agents or trying to explain an agent project to colleagues. You do not need to start with an API or a model comparison. ## Follow the learning path 1. **Learn the basic concept.** [What is an AI agent?](/knowledge/ai-foundations/what-is-an-ai-agent) introduces a practical definition and example. 2. **Choose an approach.** [AI agent vs. chatbot vs. automation](/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation) helps you decide whether a task calls for an agent, fixed automation, or conversation. 3. **Map the system.** [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture) shows how the job, context, tools, workspace, and runtime fit together. 4. **Understand execution controls.** [What is an agent harness?](/knowledge/ai-foundations/what-is-an-agent-harness) explains the instructions, context, capabilities, limits, and review rules around the model. Architecture shows how the parts of the system share the work. The harness defines the setup and controls that guide the model as it works. ## Try the concepts on a familiar task Consider preparing a weekly customer briefing. What information would the system need? Could it finish by producing a draft, or would it need to update another system? Who would check the result? These questions help distinguish a useful agent design from a conversational demonstration. If the task always follows the same known steps, include ordinary automation in your comparison. If the work involves unclear evidence or several possible next steps, write down how you would constrain and review those choices. ## Continue from understanding to design Use the [glossary](/knowledge/glossary) for short definitions. When you have a candidate task, compare it in [choose an AI agent use case](/knowledge/agent-design/choose-an-ai-agent-use-case), then continue to [agent design](/knowledge/agent-design). For AgentShelf's product architecture, see the [platform overview](/platform) and [agent harness](/platform/agent-harness). ## All guides in this topic - [What Is an AI Agent?](/knowledge/ai-foundations/what-is-an-ai-agent): An AI agent uses a model, tools, and defined rules to work toward a goal, check results, and hand off when needed. - [Agent, Chatbot, or Automation?](/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation): Use chat for dialogue, rules for predictable steps, and an agent when approved evidence must guide a bounded next step. - [AI Agent Architecture](/knowledge/ai-foundations/ai-agent-architecture): An agent combines a defined job, approved context, a model, permitted tools, runtime controls, and human review to produce a checkable result. - [The Agent Harness](/knowledge/ai-foundations/what-is-an-agent-harness): An agent harness defines a model’s job, context, available tools, limits, and review rules. - [What Is LLM Infrastructure?](/knowledge/ai-foundations/llm-infrastructure): Map model access, execution, data, reliability, and operating ownership. - [LLM Deployment Options](/knowledge/ai-foundations/llm-deployment-options): Compare managed, hybrid, and on-premises approaches by data flow and responsibility. ### AI Agent Architecture - Route: https://agentshelf.ai/knowledge/ai-foundations/ai-agent-architecture - Language: en - Description: An agent combines a defined job, approved context, an AI model, permitted tools, runtime controls, and human review to produce a checkable result. - Updated At: 2026-09-29 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-29) A procurement team needs to check supplier paperwork. An agent reads it, checks requirements, and drafts a response for review. Its architecture connects the information, tools, and human decisions behind that work. ![Diagram of a request entering a runtime with orchestration, context documents, an AI model, and read-only tools before human review.](/content/knowledge/visuals/ai-agent-architecture.svg) *Illustrative Northstar intake flow.* ## Trace one request through the system This fictional example follows a procurement reviewer asking: “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent may consult the submitted packet, the current vendor intake checklist, and the current vendor record. In this example, the checklist requires a current insurance certificate, which is absent from the packet. | Part | Role in this example | |---|---| | Job and instructions | Prepare a completeness summary and a draft request for missing material; do not approve the supplier. | | Context | Limit evidence to the submitted packet, maintained checklist, and current vendor record. | | AI model | Extract relevant details from the documents and explain which checklist item is missing. | | Tools and permissions | Read the approved materials and prepare text. Do not edit the vendor record or send a message. | | Workflow | Check the packet against the checklist, verify the record, identify gaps, then prepare a draft. | | Runtime and access | Limit the environment to assigned procurement materials and authorized reviewers. | | Review | Show the evidence and draft to a procurement reviewer before anyone sends the request or changes a record. | The resulting draft could read: > **Northstar Supplies — intake review (draft)**\ > Checked the submitted packet against the current vendor intake checklist and vendor record. > > - **Missing:** Current insurance certificate. > - **Next step:** Request the certificate, then continue the intake review. > - **Status:** Awaiting procurement review. No vendor approval or record update has been made. The request enters as an instruction, approved sources provide evidence, and the permitted action produces a draft. If the checklist and record conflict, or the document is unavailable, the system should flag the uncertainty instead of filling the gap with an assumption. ## Choose the simplest flow that fits Match the approach to the documents: - **Use rules** when packet fields are consistent and the checklist has fixed requirements, such as detecting a missing certificate. - **Use an AI model step** when document formats vary and the system must interpret which evidence matches each requirement. An AI model can help extract and explain that evidence. Keep AI model interpretations separate from deterministic checks. > **Design rule:** Add a step only when it has a clear purpose and a way to verify its result. Sketch the flow before implementation: 1. **Receive** the request and load the approved packet and records. 2. **Extract** evidence with rules or an AI model, depending on how consistently the information is structured. 3. **Compare** the evidence with the checklist. 4. **Prepare** a draft. 5. **Human review:** A procurement reviewer checks the evidence and draft and decides the next action. Mark which data crosses each step, what each tool can read or write, and what happens when a check fails. ## Write an architecture brief Turn Northstar’s example into a plan to build and test: - **User and sources:** Name the procurement user, packet, and approved reference sources. - **Access and output:** Specify read-only access and the draft summary. - **Review and exceptions:** Identify the reviewer who decides whether to send the request, and define what happens when evidence is missing or conflicting. Test the ordinary missing-certificate case, a complete packet, conflicting information, and an unrelated request. Set the quality criteria before adjusting the design. Next, [define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). For fundamentals, see [what an AI agent is](/knowledge/ai-foundations/what-is-an-ai-agent) and [what an agent harness is](/knowledge/ai-foundations/what-is-an-agent-harness). > **In AgentShelf** > > Define controls with the [agent harness](/platform/agent-harness), connect approved [knowledge and tools](/platform/knowledge-tools-automation), and choose configured AI models through the [managed gateway](/technology/infrastructure). AI model availability and capabilities, and operating records, vary by deployment and configuration. ### Agent, Chatbot, or Automation? - Route: https://agentshelf.ai/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation - Language: en - Description: Use chat for dialogue, rules for predictable steps, and an agent when approved evidence must guide a bounded next step. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Use a chatbot when the main need is conversation. Use rule-based automation when the inputs and next steps are predictable. Consider an agent when it needs to use approved information to choose the next step within defined limits. The three approaches can work together if each has a clear job. ![Three approaches to one request: a chatbot exchanges messages, automation follows a fixed sequence, and an agent branches and loops through its work.](/content/knowledge/visuals/ai-agent-vs-chatbot-vs-automation.svg) *One Northstar request, three illustrative paths.* ## Compare three ways to handle one intake request Imagine a procurement reviewer asks: “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent in this fictional example can read the submitted packet, current vendor intake checklist, and current vendor record. The checklist requires a current insurance certificate, which is missing. | Pattern | What it would do with this request | Best fit | |---|---|---| | Chatbot | Ask the reviewer for details or explain what information is needed through conversation. It would need an approved source if it is to explain the checklist. | Dialogue, clarification, and navigation. | | Rule-based automation | Check a known certificate field or document flag against the checklist and route an incomplete packet to procurement. | Stable inputs and explicit conditions. | | Agent | Interpret the packet, consult the approved checklist and vendor record, identify the missing item, and prepare a summary and request for review. | Variable documents where the next step depends on evidence found. | The agent’s draft might say: > **Northstar Supplies — intake review (draft)**\ > **Missing:** Current insurance certificate.\ > **Draft request:** “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.”\ > **Status:** Awaiting human review; no request has been sent and the supplier has not been approved. The output is useful only if the checklist and packet actually support it. If a reviewer can check a required field directly, an automation may be simpler. If packet formats require interpretation, an agent may help prepare the work, with the person still deciding what to send or approve. A combined workflow for this request could use all three patterns: a chatbot collects the packet and clarifies missing intake details, a rule checks whether the required certificate is present, and an agent interprets variable documents against the checklist and prepares a supported draft. Procurement still decides whether to send anything or approve the supplier. If the form and checklist make the rule reliable, leave out the agent step. ## Choose by the decisions the work requires Check four things before choosing: - Is the next step fixed? - Does the work require evidence from maintained sources? - Does the input vary? - Can someone review the output before it affects a person or record? For Northstar, first confirm whether the certificate check can be expressed as a reliable rule. Use an agent only if variable packet content makes that rule insufficient and the added interpretation can be evaluated. **Rules** are easier to trace when conditions are explicit, though teams must update them when the process changes. **A chatbot** can make instructions easier to reach, but a fluent answer does not prove that it used the right source. **An agent** can adapt its next step, which adds behavior to test and constrain. > **Rule of thumb:** Start with the simplest pattern that meets the job. Record the outcome, the reason the current process needs help, the simplest alternative, the allowed information and actions, and the human handoff. See [how to choose an AI agent use case](/knowledge/agent-design/choose-an-ai-agent-use-case), [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture), and [what an AI agent is](/knowledge/ai-foundations/what-is-an-ai-agent). ### LLM Deployment Options: Managed, Hybrid, and On-Premises - Route: https://agentshelf.ai/knowledge/ai-foundations/llm-deployment-options - Language: en - Description: Compare deployment approaches by data flow, operational ownership, and recovery responsibilities, then separate general architecture from product availability. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Choosing LLM infrastructure means deciding where each part runs and who keeps it working. Managed, hybrid, and on-premises describe useful deployment approaches, but an architecture label alone does not identify the destination of prompts, files, tool results, or operating records. Draw the model service, agent runtime, data stores, and tool connections separately. Then mark every boundary the task crosses. ![Three deployment approaches show managed services, split cloud and local responsibilities, and customer-operated local components.](/content/knowledge/visuals/llm-deployment-options.svg) *Define where the model, runtime, data, and records run before choosing a label.* ## Compare five deployment options Each option moves work between you and your suppliers. They can also combine: an agent you run yourself can still call a model in the cloud, and a model you host yourself can sit on rented cloud servers. | Option | Where the model runs | Who keeps it working | Costs to plan for | | --- | --- | --- | --- | | Managed model service | The supplier's servers, using the models it offers. | The supplier runs the model. Your team still controls who uses it and what the agent does. | Usage charges, usage limits, permitted regions, and a backup if the model is unavailable. | | Model hosted by a cloud provider | Your cloud provider's platform. | Shared. The contract decides who does what. | Capacity commitments, networking, and record keeping. | | Self-hosted model | Servers you rent or own. | Your team: running, updating, and restoring the model. | Servers, scaling, storage, monitoring, and staff time. | | Hybrid | Some parts in your own environment, some outside it. | Several owners, who must coordinate access, networking, data transfers, and incidents. | Delays and transfer charges between environments, and where work goes if a link fails. | | On-premises | Your own data center. | Your team: capacity, updates, access, monitoring, and recovery. | Hardware headroom, maintenance, power and facilities, and the hardware the chosen model needs. | Whenever someone says “on-premises,” ask what it covers: the model, the agent, the stored data, the activity records, or the whole journey of a request. A local model does not keep data local if the agent's tools still call outside services. A deployment platform may take on only part of this work. Ask what it sets up, updates, scales, records, and restores for you. More options do not mean less work for your team. ## Decide when on-premises deployment fits On-premises deployment makes sense when a written requirement, such as where data must stay, a lack of reliable connectivity, or an operating rule, makes local systems necessary, and you have a team to run them. Check that an approved model will run on the hardware you have, and decide how it will be updated and tested. Before committing, follow the data journey for an ordinary request and for a failure. Name who handles hardware problems, and decide how people keep working when capacity runs short. Where a system runs does not, on its own, make it compliant or fast. ## Plan for more than the model Running a model is only one part of an agent. The agent also needs approved information, permission to use its tools, a way to track work in progress, a point where a person reviews the result, and safe rules for recovering from failure. The [infrastructure requirements worksheet](/knowledge/ai-foundations/llm-infrastructure) lists these parts, so you can spot what is missing before you compare hosting prices. ## Start with the data journey For one representative task, list: 1. Input documents and where they are uploaded. 2. Context assembled for the model, including tool results. 3. Where model inference takes place. 4. Which systems the agent may read or change. 5. Where conversations, outputs, and operating records are retained. Review the ordinary route and any alternative route. An approved primary location does not automatically approve a fallback destination. Use the [security review guide](/knowledge/ai-governance/ai-agent-security-review) to turn this map into questions for the relevant owners. ## Example: a financial operations pilot A fictional finance team wants an agent to draft internal explanations of reconciliation exceptions. Its first pilot uses fabricated records and produces drafts for staff review. Before using real records, the team maps the model endpoint, runtime, reference store, and logs. The team compares three proposals using the same task. For each, it asks who can patch the runtime, restore access to reference data, investigate an incomplete draft, and replace an unavailable model. It also asks whether the required model can be operated with the proposed capacity. The resulting decision brief identifies the approved data path, component owners, operating effort, and unresolved questions. Choosing a deployment option does not, by itself, satisfy a regulator. For the product context, see [AI agents in financial services](/finance/financial-services-ai-agents). ## Include the cost of operating the choice Compare model usage with the rest of the work: compute capacity, storage, connectivity, monitoring, updates, and staff time. Customer-operated infrastructure requires someone to maintain it; a managed service still requires your team to configure access and assess whether it fits the task. Test the proposed arrangement under an unavailable dependency and a planned update. Define the person who decides whether the pilot can resume. A deployment that looks simple on a component diagram may still have a difficult incident handoff. How long setup takes depends on what is still open: access to sources, sign-in and networking, model testing, connection and recovery tests, and training the people who will run it. Estimate those steps for your task instead of borrowing a generic timeline. ## Match the architecture to a documented offer Ask a supplier to identify the supported components, customer duties, data destinations, and recovery behavior in writing. Keep optional architecture ideas separate from currently offered deployments. > **In AgentShelf** > > The documented offer includes [AgentShelf-managed services](/technology/infrastructure) and supported [customer-managed or external runtimes](/technology/developer-runtime). These are the appropriate starting points for an evaluation. If you need a hybrid or fully on-premises arrangement, confirm with AgentShelf what is available for your requirements before planning around it. Continue with [LLM infrastructure fundamentals](/knowledge/ai-foundations/llm-infrastructure) and [workspaces and external agents](/knowledge/ai-agent-integration/workspaces-and-external-agents) to distinguish the components and their bindings. ### What Is LLM Infrastructure? A Guide for Teams Building AI Agents - Route: https://agentshelf.ai/knowledge/ai-foundations/llm-infrastructure - Language: en - Description: Understand the model access, runtime, data, reliability, and cost controls behind an AI agent, then map ownership before a pilot. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) LLM infrastructure is the set of services and operating controls that lets an application use large language models reliably. For an AI agent, the model endpoint is one dependency within a larger system: the agent also needs an execution environment, permitted information, tools, and a way to report outcomes. A useful starting point is to trace one task from the user to a checked result. This reveals who operates each dependency and where a failure could prevent useful work. ![A user request passes through an agent runtime and model gateway to a configured model; approved data and tools support the runtime.](/content/knowledge/visuals/llm-infrastructure.svg) *The model endpoint is one dependency; the runtime, data, and tools complete the system.* ## Separate model serving from agent execution **Model serving** runs the model and returns generated output. **Agent execution** runs the application logic that assembles context, calls the model, invokes permitted tools, and decides what to do next. These can run in different environments with different owners. A gateway can provide a common point of access to configured model endpoints. It does not by itself define the agent's job or decide which business actions a person must approve. For the broader system, see [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture). ## Map the six parts of an LLM infrastructure solution A long list of available models tells you little about whether a supplier can run your work. Trace one complete task instead and ask, for each of the six parts below, who runs it and what happens when it fails. - **Model access:** sends requests to an approved model. Usually run by the platform team and the model provider. Watch for: the model is unavailable, or the only alternative is not good enough for the task. - **Agent runtime:** carries out the task step by step. Usually run by the application operator. Watch for: a task that stops halfway, leaving nobody sure whether it finished. - **Knowledge and tools:** the information the agent may read and the actions it may take. Usually run by each source owner. Watch for: missing, outdated, or blocked information. - **Work in progress and results:** where drafts and finished results are kept. Usually run by the application's data owner. Watch for: a half-finished draft that looks complete. - **Recovery rules:** when to try again, switch to another model, or stop. Usually set by the workflow owner. Watch for: repeating an action, such as a message or a record update, that may already have happened. - **Usage and cost:** what each task costs and which budget applies. Usually owned by the budget owner. Watch for: costs nobody can trace, or a request that no budget checks. Ask the agent to draft the worksheet from the task description and the systems it will connect to. Your team then checks each answer with the person who actually runs that part. Keep the list of models separate from the agent's permissions: adding a model should never quietly give the agent access to new records or new actions. > **Infrastructure requirements worksheet (blank)** > > - Model access: who runs it, what happens when it fails, how we will test it: ___ > - Agent runtime: who runs it, what happens when it fails, how we will test it: ___ > - Knowledge and tools: who owns each source, what happens when one is unavailable, how we will test it: ___ > - Work in progress and results: where drafts are kept, how a half-finished draft is marked, how we will test it: ___ > - Recovery rules: when to retry, when to switch, when to stop, and who is told: ___ > - Usage and cost: who owns the budget, which budget applies to this task, how we will confirm it: ___ ## Example: a service request assistant In this fictional pilot, a facilities team wants an assistant to classify incoming maintenance requests and prepare a suggested response. The model interprets free text; the application checks permitted categories and displays a draft. An operator approves any change to the maintenance record. The team writes a small infrastructure brief: - **Input:** Request text and the approved category guide; exclude unrelated personnel records. - **Execution:** A named application owner maintains the runtime and its tool connection. - **Model choice:** Test configured candidates against ambiguous requests and missing information. - **Output:** A category recommendation, supporting evidence, and a draft response. - **Failure behavior:** Show a pending review state when model access or the category guide is unavailable. - **Operating review:** Inspect failed requests and spending alongside accepted recommendations. Success means the operator can check the recommendation and understand any failure. A reply from the model on its own does not mean the task succeeded. ### The completed worksheet The facilities team's version reads like this. Each test is something the pilot has to pass before real requests go through. > **Infrastructure requirements worksheet: facilities pilot (fictional)** > > - **Model access:** The platform team runs one approved model with no untested backup. If the model is unavailable, the request waits as “pending” and the facilities operator handles it by hand. *Test:* switch the model off in a test environment and confirm the request shows as pending. > - **Agent runtime:** The application operator runs it. The agent checks the request against approved categories and prepares a draft; it never changes the maintenance record. If a task stops halfway, it stays marked incomplete until the operator looks at it. *Test:* interrupt a task and confirm it cannot pass for finished. > - **Knowledge and tools:** The facilities team owns the category guide, and the agent can read only the approved version. If the guide is missing, out of date, or blocked, the agent stops and asks for manual handling. *Test:* try an old version, a missing guide, and blocked access. > - **Work in progress and results:** Drafts stay “pending” until the operator accepts them, and only the facilities team can see them. *Test:* interrupt a save, then sign in as a second user and check what they can see. > - **Recovery rules:** The agent retries once when a model call clearly fails. If it cannot tell whether a step finished, it stops and the operator checks before anything is repeated. *Test:* simulate a slow response and confirm the agent stops rather than repeats. > - **Usage and cost:** The pilot budget owner tracks model charges, other service charges, and staff review time separately. Missing usage is reported as missing, never as zero. *Test:* send a request that should trigger the budget warning and confirm that it does. One part working does not make the whole task work. Keep the approved worksheet with the pilot results, so the next operator can see what was intended and what was actually tested. ## Plan a pilot around observable outcomes Choose representative cases before tuning infrastructure: a clear request, a request spanning two categories, a missing location, and an unavailable dependency. Record completion time, whether the draft is usable, and the cost of the whole task. Keep assumptions visible when usage records cover only part of the route. Then decide whether your next gap is [provider failover](/knowledge/ai-agent-integration/llm-provider-failover), [deployment ownership](/knowledge/ai-foundations/llm-deployment-options), or the [difference between a gateway and an agent platform](/knowledge/ai-agent-integration/llm-gateway-vs-agent-platform). When you compare running costs, count failed attempts and the time people spend fixing results, not only model prices. The [cost-per-completed-task worksheet](/knowledge/ai-governance/ai-agent-governance-and-cost-controls#calculate-cost-per-completed-task) shows how. Budgets are a separate question: they cap spending, while this worksheet tells you what a useful result really costs. > **In AgentShelf** > > The [infrastructure overview](/technology/infrastructure) describes managed services and configured model access. Provider availability depends on configuration, credentials, region, plan, and catalog. Review the [developer runtime](/technology/developer-runtime) for supported execution options and [governance and cost controls](/platform/governance-cost-controls) for monetary budgets and their coverage boundaries. ### The Agent Harness - Route: https://agentshelf.ai/knowledge/ai-foundations/what-is-an-agent-harness - Language: en - Description: An agent harness defines a model’s job, context, available tools, limits, and review rules. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent harness is the setup that defines a model’s job, context, available tools, limits, and review rules. It turns a broad instruction into a repeatable workflow that a team can inspect and test. Consider a hypothetical Northstar Supplies onboarding agent. Procurement asks: “Prepare an onboarding review from the intake packet, approved checklist, and current vendor record. Flag missing evidence and draft a document request for review. Do not approve the vendor or send a message.” The harness describes what the agent may read, what draft it should produce, and where a person must take over. ![Diagram of a model inside a Northstar Supplies agent harness, surrounded by instructions, context, tool access, limits, and checks](/content/knowledge/visuals/what-is-an-agent-harness.svg) *A model enclosed by task controls.* ## Define the parts around the task - **Job:** Prepare an onboarding review and draft a request for missing evidence. - **Context:** Use the submitted packet, approved checklist, and current vendor record. Identify which source supports each finding. - **Tools:** In this hypothetical setup, allow reading those sources and creating a draft. Do not provide approve or send actions. - **Rules:** Flag missing or conflicting information, do not fill gaps by guessing, and stop before approval or sending. - **Review:** Give the draft to procurement, which decides whether to request another document or continue the review. Illustrative output from fictional Northstar Supplies records: > **Onboarding review — draft** > > - **Finding:** A current insurance certificate is missing from the intake packet. > - **Draft request:** “Please provide a current insurance certificate so procurement can continue its review.” > - **State:** No message sent; no vendor approval made. This sample shows how job, context, tools, and limits shape the result. If the checklist or current record cannot be read, the agent should report that gap and hand off rather than present an unverified conclusion. Instructions alone do not guarantee correct behavior; test the workflow against complete, incomplete, and conflicting packets. ## A harness is more than a prompt A prompt can describe the role and operating rules, but the overall setup also includes the information and actions actually available to the model, plus the environment and review process. > **Control rule:** A written rule that says “do not approve” is not a substitute for withholding approval capability where the system allows that control. Without those controls, the Northstar workflow has visible failure modes. If the checklist cannot be read but the draft still says the certificate is missing, the reviewer has no checklist evidence for that finding. If the agent still has access to a send action despite its draft-only instructions, check the outgoing-message status for any request sent before review. Require evidence from the named sources, stop and hand off when a source is unavailable, and withhold approval and send actions from this workflow. Before testing, make sure a teammate can: - State the job in one sentence. - Name every source. - Explain each permitted action. - Identify the human decision point. Narrow the task if any of these remain unclear. For a component map, read [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture). To define the job, see [How to define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). For a product overview of focused jobs, approved knowledge, and bounded actions, consult the [AgentShelf agent harness page](/platform/agent-harness). ### What Is an AI Agent? - Route: https://agentshelf.ai/knowledge/ai-foundations/what-is-an-ai-agent - Language: en - Description: An AI agent uses a model, tools, and defined rules to work toward a goal, check results, and hand off when needed. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An AI agent uses a model, tools, and defined rules to work toward a goal, check results, and hand off when needed. The model supplies reasoning and output; the surrounding workflow determines what information and actions are available. ## Example: prepare a vendor onboarding review Northstar Supplies submits an onboarding packet. Procurement asks: “Prepare an onboarding review from the intake packet, approved checklist, and current vendor record. Flag missing evidence and draft a document request for review. Do not approve the vendor or send a message.” The agent consults only those three sources. It checks the packet against the checklist, compares relevant details with the current record, identifies missing information, and prepares a draft for procurement. The sample below uses fictional information and illustrates the expected kind of output; it is not a real vendor result. > **Northstar Supplies — onboarding draft** > > - **Finding:** A current insurance certificate is missing from the intake packet. > - **Draft request:** “Please provide a current insurance certificate so procurement can continue its review.” > - **Decision:** Vendor approval has not been made; procurement must review the draft. The agent’s useful action is preparing a grounded draft. If a source is unreadable or details conflict, the agent should say what it could not verify and route the case for review. > **Review rule:** Approval and sending remain with a person. ![Illustrative agent loop for the Northstar Supplies request, with a missing-information branch to human review](/content/knowledge/visuals/what-is-an-ai-agent.svg) *The agent completes the review when the evidence is clear. If information is missing, it checks further or hands the case to a person.* ## What makes this an agent? - **Job:** Prepare a review. - **Context:** Use the approved packet, checklist, and record. - **Tools:** Determine what the system can read or change. - **Rules:** Describe how to handle missing evidence and where to stop. Together, these let the system choose a next step within a bounded task. A model alone could summarize the submitted form. A fixed automation could check that required files are present. The example agent compares evidence across allowed sources and adapts its draft to what it finds. That flexibility needs clear permissions and a way to check the result. ## When the pattern fits Use an agent when: - The request varies. - The next step depends on what approved information shows. - A person can check the output or handle exceptions. A fixed workflow or direct model call may be easier to define for a stable sequence or single transformation. Before giving an agent a consequential action, decide: - Who owns unresolved cases. - Which facts require verification. - What the agent must never do. For a comparison with chatbots and automation, read [AI agent vs. chatbot vs. automation](/knowledge/ai-foundations/ai-agent-vs-chatbot-vs-automation). For the system components, continue to [AI agent architecture](/knowledge/ai-foundations/ai-agent-architecture) and [the agent harness](/knowledge/ai-foundations/what-is-an-agent-harness). ### AI Agent Governance, Evaluation, and Cost - Route: https://agentshelf.ai/knowledge/ai-governance - Language: en - Description: Plan how to evaluate an AI agent, set its permissions and operating limits, and decide when a person needs to review its work. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Before running an agent pilot, name its owner and decide who may use it, what it may access, which results need review, and when to stop it. Keep evidence that another person can check. These decisions form the basis of governance. ![A six-step oversight cycle with a person responsible for the decision](/content/knowledge/visuals/governance.svg) This path supports pilot owners, operations teams, and reviewers. The guides offer questions and working templates; specific enforcement behavior belongs in the documentation for the systems you use. ## Prepare for a pilot decision 1. [Evaluate an agent before production](/knowledge/ai-governance/evaluate-an-ai-agent). Define representative cases, expected outcomes, and release criteria before judging the pilot. 2. [Review permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). Check information access and action authority separately. 3. [Design human review](/knowledge/agent-design/human-in-the-loop-ai-agents). Name the reviewer and define how work pauses or escalates. 4. [Plan governance and cost controls](/knowledge/ai-governance/ai-agent-governance-and-cost-controls). Assign ownership for usage, spending, changes, and incidents. ## Keep a small decision record A practical record identifies the agent and version, the job owner, allowed sources and actions, evaluation evidence, known limits, and the person who accepted the pilot scope. Add a date for the next review and a way to stop the workflow. For example, a limited internal policy Q&A pilot could record: - **Owner:** The policy owner maintains the approved source set and reviews exceptions. - **Evaluation evidence:** Include questions answered by current policy, a missing source, and conflicting versions. Proceed only when supported answers cite a current source and the other cases are routed clearly. See [evaluation guidance](/knowledge/ai-governance/evaluate-an-ai-agent). - **Permission:** Read approved policy material for this job; no employee-record access or edits. Review the boundary with [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). - **Limit and decision:** Draft explanations only. If evidence is missing or conflicts, pause and route the question to the named owner. Keep the pilot within this scope until the owner reviews its results. Do not collapse quality, spending, and permission failures into one overall score. An inexpensive run may still produce an unusable answer; a persuasive answer may still exceed the workflow's authority. Give serious boundary failures their own decision rule. ## Review after a meaningful change Revisit the evidence when instructions, source material, models, tools, or access change. Repeat the cases affected by the change and retain enough context to explain the decision. For AgentShelf product descriptions, see [trust boundaries](/platform/trust-boundaries) and [governance and cost controls](/platform/governance-cost-controls). Return to [agent design](/knowledge/agent-design) when the job itself needs to change. ## Use agents for cyber defense The [Cyber Defense learning path](/knowledge/ai-cyber-defense) applies these ownership and permission controls to defensive work. Start with [a defensive agent job brief](/knowledge/ai-cyber-defense/defensive-ai-agents), then choose the exposure to investigate. ## All guides in this topic - [Evaluate an AI Agent](/knowledge/ai-governance/evaluate-an-ai-agent): Evaluate an agent by testing representative tasks, tool use, failure handling, and approval boundaries before widening access. - [AI Agent Permissions and Boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries): Set an agent’s boundary across identity, information, capability, surface, and oversight, then check each limit in the connected systems. - [Governance and Cost Controls for AI Agents](/knowledge/ai-governance/ai-agent-governance-and-cost-controls): Govern an agent by naming its owner, limiting data and actions, reviewing outcomes, and tracking cost per completed, human-checked task. - [AI Agent Failure Modes and Recovery](/knowledge/ai-governance/ai-agent-failure-modes): Diagnose an agent failure from evidence, then choose a bounded retry, correction, safe stop, or human handoff. - [AI Agent Observability: What to Track](/knowledge/ai-governance/ai-agent-observability): Track workflow activity, errors, handoffs, and resource signals so an owner can investigate a run and decide what needs review. - [AI Agent Security Review Checklist](/knowledge/ai-governance/ai-agent-security-review): Review an agent’s users, information flows, identities, tools, dependencies, tests, and response owners before expanding its access or use. - [An AI Agent Governance Checklist for Teams](/knowledge/ai-governance/ai-agent-governance-checklist): Give every agent workflow a named owner, approved scope, review path, operating contact, and decision for changing or stopping it. - [Define Who Can Use and See an Agent’s Work](/knowledge/ai-governance/agent-operating-boundaries): Set separate audience, workspace, and administrator boundaries so people can invoke, maintain, and review an agent in the right context. - [Manage Agent Changes with Review and Rollback](/knowledge/ai-governance/ai-agent-change-management): Record changes to an agent’s instructions, sources, tools, model, and access, then retest affected cases before widening use. - [Manage Unapproved AI Use in Your Team](/knowledge/ai-governance/shadow-ai-governance): Make AI use visible through clear guidance, a safe reporting path, proportionate risk review, and an approved way to do useful work. - [Review an Agent’s Tools and Data Access](/knowledge/ai-governance/review-agent-tools-and-data-access): Inspect each connected tool for its identity, data scope, allowed operations, side effects, returned information, and failure behavior. - [How to Set LLM Budgets](/knowledge/ai-governance/llm-budget-management): Plan monetary budgets, supported request coverage, and spending review. - [Share AI Agents Across Teams with Access Rules](/knowledge/ai-governance/share-ai-agents-across-teams): Distinguish submission, manager approval, library scope, and underlying data permissions. ### Define Who Can Use and See an Agent’s Work - Route: https://agentshelf.ai/knowledge/ai-governance/agent-operating-boundaries - Language: en - Description: Set separate audience, workspace, and administrator boundaries so people can invoke, maintain, and review an agent in the right context. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Decide who can use the agent, who can see its context and results, and who can configure or review it. Check access to the public experience, workspace, and administration separately from the agent’s permission to call tools or change records. ## Trace one support question across three contexts Suppose a service team offers a public agent for basic support questions. The approved public return policy says to request a return label through the support form before shipping an item. A separate private support note says this visitor’s account has an unresolved return exception. A support specialist can review that note in the staff workspace; it does not belong in a public answer. An administrator manages the settings and access for both experiences. The public response could be: > “To request a return label, submit the support form before shipping the item. For account-specific help, contact a support specialist.” Separately, an internal reviewer records that the answer uses only the approved public policy. The private exception remains available only to an authorized specialist in the staff workspace. Neither the note nor the existence of the exception is included in the visitor’s response. These are design expectations for the example. Confirm how the actual application recognizes each user, what information each surface can reach, and which records an administrator can review. ![Three separately checked operating boundaries labeled Public, Workspace, and Admin](/content/knowledge/visuals/agent-operating-boundaries.svg) *Check access independently for the public experience, staff workspace, and administration.* ## Review the three operating boundaries | Context | Questions to answer | Evidence to inspect | |---|---|---| | Audience and surface | Who can start a conversation or submit work? Is the experience public, embedded in another application, or limited to authenticated users? | Session and origin checks, audience settings, user-facing inputs, and the information the surface is prepared to return. | | Workspace | Which staff members can view or change the agent’s context, conversations, outputs, and working materials? Are those materials separate from the public experience? | Workspace membership, source ownership, output visibility, activity access, and rules for sharing or exporting results. | | Administration | Who can configure instructions, sources, tools, deployment settings, and access? Who can inspect operational records or change the audience? | Admin roles, configuration history, connected-system access, review records, and the process for removing access. | For every boundary, name the owner and the expected behavior when a person or request is outside its scope. Verify those expectations through the actual interface and connected systems. A page that looks private does not by itself prove that the underlying data or tool calls are restricted. The [permissions matrix](/content/knowledge/visuals/ai-agent-permissions-and-boundaries.svg) used in a broader review illustrates resources against actions—read, draft, update, send, and approve. It helps test what the agent can do within a context; it does not depict audience, workspace, or administrator boundaries. ## Keep audience boundaries distinct from action permissions An audience boundary asks who can access an experience or see its information. An action-permission review asks what the agent’s tools can read, create, update, send, or approve. The two interact, but either can fail independently: a correctly scoped public interface might still call an overly powerful tool, while a read-only tool might return information to the wrong audience. In the support example, the public agent’s response comes from public help content, while a specialist can consult internal procedure in a separate work context. The administrator can manage the configuration, but the public visitor cannot change it. The team should verify that this is how the deployed path behaves before relying on the separation. Map the boundary again when the audience, workspace members, context sources, deployment surface, or administrator group changes. For tool-by-tool questions, continue to [review an agent’s tools and data access](/knowledge/ai-governance/review-agent-tools-and-data-access). For broader access risks, see [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) and the [security review checklist](/knowledge/ai-governance/ai-agent-security-review). AgentShelf’s current public description is on the [Trust and Boundaries page](/platform/trust-boundaries); confirm product behavior against the configured path. ### Manage Agent Changes with Review and Rollback - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-change-management - Language: en - Description: Record changes to an agent’s instructions, sources, tools, model, and access, then retest affected cases before widening use. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) When you change an agent, record the change and test the behavior it could affect before expanding use. Changes to instructions, approved sources, tools, models, access, or where the agent runs can alter the workflow. For each material change, name an owner and decide how to recover if it fails. ## Update one equipment-support workflow The service team uses an agent to compare equipment repair requests with the approved repair policy and asset record, then prepare a response draft for a technician. A revised policy now requires a condition photo before the agent may recommend repair. The agent can read the request, policy, and asset record and prepare a draft, but it cannot approve or schedule the repair. In this fictional test, the team checks four requests: one with the required photo, one without it, one whose asset record conflicts with the request, and one outside the repair scope. The updated version cites the photo, asks for the missing photo, routes the conflict to a technician, and declines to recommend an out-of-scope repair. The completed change record is: > **Repair guidance update — release decision** > > - **Version:** `repair workflow v4 → v5` (illustrative configuration labels). > - **Change:** Replace the prior repair-policy version with the approved revision. > - **Behavior changed:** Require a condition photo before recommending repair; request it when missing, route conflicting asset data to a technician, and refuse out-of-scope repairs. > - **Owner:** Service process owner; policy owner confirms the source is current. > - **Approver:** Service process owner accepts the test evidence after the policy owner confirms the source. > - **Affected checks:** Photo present, photo missing, conflicting asset data, and out-of-scope repair. > - **Review result:** All four cases returned the expected response, including the out-of-scope refusal; no repair was approved or scheduled. > - **Recovery:** Revert the technical configuration only if it still meets the current policy. Otherwise pause the agent workflow and route requests to a technician applying the current requirements. > - **Decision:** Release the revised policy to the existing pilot group; review new exceptions before expanding. This sample records a decision for an invented scenario. In a real change, the team must confirm which source the agent reads and base release on its own test evidence. ![A cycle to set limits, review quality and cost, and adjust controls, with model, tools, retries, and human review shown as cost sources](/content/knowledge/visuals/ai-agent-governance-and-cost-controls.svg) *Reassess limits and quality after a material change.* ## Keep a small versioned change record For each change, capture: | Field | What to record | |---|---| | Change identity | Agent or workflow, configuration version, date, and person proposing the change. | | Reason and owner | The need being addressed, process owner, and any source or system owner who must approve it. | | Approval | Approver by role, evidence reviewed, decision, and date. | | Affected parts | Instructions, knowledge sources, tools, model, audience, permissions, deployment, or review steps that changed. | | Expected effect | The behavior expected to change and the behavior that must remain within its existing boundary. | | Evidence | Cases run before and after, observed differences, reviewer corrections, unresolved limits, and release decision. | | Recovery | A fallback configuration checked against current policy, owner for disabling or reverting, and how affected work will be handled. | Match review effort to the effect of the change. A typo that cannot alter task meaning may need a light check. A new data source, action, user group, model, or policy rule may change exposure or outcomes and needs a more deliberate review. Follow the organization’s required security, privacy, legal, or subject-matter process where it applies. ## Retest the cases connected to the change 1. **Preserve a baseline.** Keep representative cases and expected outcomes from the current workflow, including exceptions and boundary checks. 2. **Identify affected behavior.** Map the change to the source, instructions, tool, or decision step that uses it. Add cases for new or changed requirements. 3. **Compare results.** Run the same relevant cases against the prior and proposed configuration. Review output, source use, tool activity, and handoffs; do not rely only on fluent wording. 4. **Release in a bounded scope.** Name who accepts the evidence, which users receive the change, and what signal will trigger a pause or rollback. 5. **Check operation afterward.** Review representative live work and exceptions, then update the record with the decision and any follow-up. For the repair-policy change, test a request with all required evidence, one missing it, one with a conflicting asset record, and an unrelated request. The technician should see which policy and record supported the draft. If the change weakens that evidence or crosses the workflow boundary, pause use while the owner investigates unless a fallback configuration has been verified against the current requirements. A technical rollback does not authorize restoring a superseded business policy. Review the operating record with the [team governance checklist](/knowledge/ai-governance/ai-agent-governance-checklist), [agent evaluation guide](/knowledge/ai-governance/evaluate-an-ai-agent), and [observability guide](/knowledge/ai-governance/ai-agent-observability). ### AI Agent Failure Modes and Recovery - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-failure-modes - Language: en - Description: Diagnose an agent failure from evidence, then choose a bounded retry, correction, safe stop, or human handoff. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) An agent failure can come from missing information, an unavailable tool, conflicting sources, an unsupported action, or a result that does not meet the job. Diagnose the cause from the run evidence before choosing a response; repeating the whole task is not a safe default. ## Start with one equipment request A facilities coordinator asks: “Check this equipment replacement request against the current policy and inventory record. If required information is missing, draft a question for review. Do not place an order.” The agent can read the submitted request, approved policy, and inventory record. Its only output is a recommendation draft. If the inventory system is temporarily unavailable, the agent cannot confirm whether the item is in stock. A responsible result would be: > **Replacement review — incomplete draft** > > - **Checked:** The submitted request and current replacement policy. > - **Could not verify:** Current inventory; the source did not respond. > - **Decision:** Do not recommend a replacement until inventory is checked. > - **Next step:** Retry the read later if the system confirms it is safe, or route the case to facilities. The draft keeps the verified work useful while making its limit visible. It does not claim that the inventory lookup succeeded or that a replacement is approved. ![Illustrative evaluation scorecard separating outcome, process, boundaries, and recovery for an agent workflow](/content/knowledge/visuals/evaluate-an-ai-agent.svg) *Record what failed before deciding how to recover.* ## Diagnose the failure before acting | Symptom | Evidence to check | Response to consider | |---|---|---| | A source is missing, unreadable, or stale | Source identifier, version or date, retrieval result, and any access error | Mark the result incomplete. Ask the source owner to restore or update the reference, or hand off the case. | | Two approved sources disagree | The exact fields and dates that conflict, plus the source owner for each | Show the disagreement and pause the decision until an authorized owner resolves it. Do not choose whichever value looks more plausible. | | A tool times out or returns an error | Tool name, operation, error category, retry history, and whether an earlier attempt changed anything | Retry only when the failure appears temporary and repeating the operation is safe. Use a bounded retry policy; otherwise stop and route it. | | The output is incomplete or unsupported | Required fields, source evidence, and the evaluation case that detected the gap | Correct the draft or ask for review. Keep an unsupported result from flowing into a later action. | | A request or document tries to change the job | The original task, untrusted text, selected tool, and permission decision | Treat the text as evidence to assess, not as authorization. Deny or pause any action outside the defined job. | Use these questions to investigate the failure. The records and error details available will vary by system, so check what your run history retains and what the receiving tool reports. ## Choose a recovery path with a stop condition 1. **Preserve the evidence.** Keep the request, active configuration, source versions, tool outcome, and visible error needed to explain the failure. Protect sensitive records under the team’s access and retention rules. 2. **Classify the condition.** Separate a temporary dependency problem from a missing reference, policy conflict, invalid input, or unsupported request. Ask the relevant source or system owner when the cause is uncertain. 3. **Choose the smallest safe response.** Retry a read only when it is safe and bounded. Do not repeat a write or external action until its prior status is known. Correct a draft only after the evidence is available; otherwise stop and hand off. 4. **Make the state visible.** Tell the requester what was checked, what remains unknown, and who owns the next step. Do not label a partial run as complete. For the equipment case, a failed read should leave the recommendation pending. A facilities reviewer can check the inventory record, then either continue or close the request. If the system cannot tell whether an action already ran, the operator should resolve that state before trying again. ## Retest the failure path Keep the original case that exposed the problem and add a nearby variation: an unreadable source, a delayed response, a conflicting record, and an out-of-scope request. Confirm both the final result and the path taken. A retry that produces an answer may still be wrong if it repeats a side effect, uses an unapproved source, or hides the uncertainty. Review the evidence with [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent), [observability for agent runs](/knowledge/ai-governance/ai-agent-observability), and the [security review checklist](/knowledge/ai-governance/ai-agent-security-review). The [defensive operations example](/knowledge/ai-cyber-defense/operate-defensive-ai-agents) applies bounded retries, independent health checks, and unanswered-escalation rules to an overnight security job. ### AI Cost Governance: An Owner, Limit, and Review Framework - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-governance-and-cost-controls - Language: en - Description: Govern AI costs with named owners, monetary limits, verified request coverage, and regular reviews of quality and cost per completed task. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) To govern an agent, define its purpose, access, and review process, then assign someone to oversee its operation and cost. Measure cost against useful work, such as a completed intake review. Name who will respond when quality or cost falls outside the agreed limits. ![Set limits, review, and adjust in a continuing cycle, with model, tools, retries, and human review shown as cost components.](/content/knowledge/visuals/ai-agent-governance-and-cost-controls.svg) *Set limits, review quality and cost, then adjust with a named owner.* ## Use an owner, limit, and review framework AI cost governance connects three decisions: **who owns the work and spending**, **which limits apply**, and **what evidence triggers a review**. A budget is one control inside that framework. Quality, permissions, and human review still determine whether the work is acceptable. | Decision | Record before launch | Review question | | --- | --- | --- | | Owner | Workflow owner, budget owner, organization admin, and exception responder | Who acts when the workflow becomes costly or unreliable? | | Limit | Monetary allowance, currency, period, scope, and applicable request path | Does this path apply the policy and the intended response? | | Review | Completed tasks, quality findings, repeated attempts, and spending | Are cost changes explained by more useful work or avoidable rework? | AgentShelf supports monetary budgets for organization, team, user, and widget scopes. Organization admins choose hard or soft budgets. On supported covered paths with an active policy, soft limits warn and continue; hard limits reject covered requests at the limit. Other paths can continue without a budget check. Agent and workspace reporting provides visibility, not separate enforcement. These controls make budget responsibility concrete while leaving source permissions and quality review as separate decisions. For choosing amounts, periods, scopes, and verifying actual request coverage, use the [LLM budget management guide](/knowledge/ai-governance/llm-budget-management). The framework below explains how to operate that policy alongside quality and authority controls. ## Assign the workflow and budget owners Use one fictional workflow throughout this guide: a procurement reviewer asks, “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent compares the submitted packet with the current vendor intake checklist and record. The packet lacks a current insurance certificate, so the agent prepares a review summary and a draft request. A person still decides whether to send the request or continue the vendor review. The operating record for that draft could read: > **Northstar Supplies intake — operating review (draft)**\ > **Owner:** Procurement process owner; assign a named person before the pilot.\ > **Allowed:** Read the packet, current checklist, and current vendor record; prepare a summary and draft request.\ > **Human decision:** A procurement reviewer checks the evidence and decides whether to send the request. The agent cannot update the record or approve the supplier.\ > **Review signals:** Missing-evidence findings, reviewer corrections, handoffs, and cost per reviewed packet.\ > **Cost limit:** Set with the budget owner from an expected workload and pilot baseline; no threshold is set in this example.\ > **Status:** Draft for review before pilot. Before a pilot, assign a process owner and an operator for exceptions. Record who may request the review, which packet and reference sources are in scope, what the agent may read, and what it may prepare. In this example, the permitted output is draft text; changing the vendor record, sending a request, or approving the supplier remains outside the agent’s authority. Name who can pause the workflow and who reviews the draft. ## Review cost per useful task through each stage 1. **Before the pilot:** Agree on the job, approved sources, read and write permissions, human review point, fallback path, and tests. Set a monetary spending allowance and verify the response on the selected request path. 2. **During the pilot:** Review completed drafts and exceptions. Track packet volume, cost per reviewed packet, time spent by reviewers, missing-evidence detection, and corrections. Interpret the measures together: a low cost per packet is not useful if reviewers must redo the work, and a handoff can be the correct outcome when evidence is missing. 3. **Before expanding:** Confirm the owner, user group, data access, tools, and review rules still match the workflow. Revisit the tests when the checklist, source records, or permissions change. For the Northstar example, count a useful unit as one packet that a reviewer can assess using the summary and evidence. Include model usage, repeated attempts, connected service charges, and review or correction time when measuring cost. Do not infer savings from the number of drafts; compare cost and quality against the current human process over the same set of work. ## Calculate cost per completed task A cheap model can still produce an expensive workflow. If its results need heavy fixing, the staff time can outweigh any savings on model charges. To compare options fairly, add up everything a workflow costs, including failed attempts and the time people spend reviewing and correcting results. Then divide by the number of results you could actually use. **Cost per usable result = (model charges + other service charges + staff time reviewing and fixing results + any running costs you choose to include) ÷ usable results.** Compare options on the same task, over the same period, using the same rule for what counts as usable. The agent can fill in most of the worksheet from its own usage records and the review outcomes. Your team sets what counts as usable and the hourly rate for staff time. > **Cost per completed task worksheet (blank)** > > - Task, and what counts as a usable result: ___ > - Period and number of tasks submitted: ___ > - Model attempts and charges (include retries and failed attempts that were charged): ___ > - Other service calls and charges (include repeated calls): ___ > - Staff time reviewing and fixing results, and the hourly rate used: ___ > - Running costs included, and how they were divided, or a note that they were left out: ___ > - Usable results (count results, not attempts): ___ > - Total cost, and cost per usable result (if no results were usable, report the total cost and that outcome): ___ Here is a fictional comparison of two options on the same 100 tasks. The numbers are made up to show the method. They are not real model prices or customer results. | Item | Cheaper model | Pricier model | | --- | --- | --- | | Tasks submitted | 100 | 100 | | Model attempts | 200 at $0.01 = $2 | 100 at $0.03 = $3 | | Other service calls | 200 at $0.02 = $4 | 100 at $0.02 = $2 | | Staff time reviewing and fixing | 400 minutes at $30/hour = $200 | 100 minutes at $30/hour = $50 | | Usable results | 80 | 90 | | Total cost | $206 | $55 | | **Cost per usable result** | **$2.58** | **$0.61** | Staff time makes almost all of the difference here. That is an assumption of the example, not a rule that pricier models need less review, so measure it in your own pilot. Hosting and other fixed costs are left out of both columns. In a real comparison, say what you left out and check quality on the same set of tasks. This worksheet measures what a result really costs. A budget does something different: it caps spending on the requests it covers, and staff time is not part of it. See [AgentShelf's budget controls](/platform/governance-cost-controls) for what a budget covers. ## Use a cost governance checklist - Name the owners of the workflow, the budget, and exceptions. - Agree what counts as a usable result, and fix the workload and period you will measure. - Record the budget and how requests reach the agent, then test what happens at the limit. - Count failed attempts, and say which costs are measured and which are left out. - Review quality, rework, usable results, and spending together. - Record whether you will adjust, pause, or continue, and what triggers the next review. ## Define separate cost, quality, and authority responses Choose a trigger and owner for each kind of stop. These fictional Northstar examples do not set a universal threshold: | Condition | Example trigger | Response | |---|---|---| | Quality | A reviewer cannot trace a required finding to the approved packet, checklist, or vendor record. | Pause that packet’s draft, identify the missing or conflicting evidence, and rerun the affected case before accepting the result. | | Spend | The pilot reaches the monetary limit set with the budget owner. | A covered hard policy rejects requests; a covered soft policy warns and continues. The named owner reviews spending and decides whether to pause the workflow or change its allowance. | | Authority | A run attempts to send a request, change the vendor record, or approve the supplier. | Treat it as a boundary failure, block the action, and verify system state before any retry. | Set the spending threshold from expected workload and the cost of a reviewed packet. Confirm that the configured path applies it to the intended workflow; if the environment cannot pause use, assign an operator to monitor and stop it manually. Review available run records for sources, tool activity, handoffs, and failures. Compare a repeatable set of ordinary, incomplete, and conflicting packets after changes. If a record cannot explain a draft, add an appropriate review step before expanding use. ## Keep the owner, limit, and review record current Keep a current record of: - **Ownership:** The workflow owner and intended users. - **Scope and permissions:** Approved sources, action scope, and approval rules. - **Evidence and evaluation:** Evaluation criteria and cost baseline. - **Operating limits:** Known limits and the pause procedure. - **Review:** The review date. Revisit the record on a schedule and after a material change. See the [permissions review](/knowledge/ai-governance/ai-agent-permissions-and-boundaries), [pre-pilot evaluation guide](/knowledge/ai-governance/evaluate-an-ai-agent), and AgentShelf’s [governance and cost controls overview](/platform/governance-cost-controls) for related guidance. ### An AI Agent Governance Checklist for Teams - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-governance-checklist - Language: en - Description: Give every agent workflow a named owner, approved scope, review path, operating contact, and decision for changing or stopping it. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Use this checklist to record who owns the agent workflow, which tasks and information it covers, who reviews the results, and who can change or stop it. Keep it up to date during the pilot as users, sources, or responsibilities change. ## Use one proposed workflow to assign responsibility Imagine an internal facilities team asks: “Review this equipment replacement request against the approved policy and current asset record. Flag missing information and draft a follow-up question for review. Do not change the record or place an order.” The agent can read the request, policy, and asset record, then prepare the draft. A facilities reviewer decides what to do with it. Before the pilot, the team assigns a facilities process owner, a reviewer, and an operator for exceptions. The source owners confirm that the replacement policy and asset record are current. The completed operating record for this illustrative setup is: > **Equipment request review — pilot decision record** > > - **Process owner:** Facilities lead responsible for the request workflow and policy. > - **Sources:** Submitted request, approved replacement policy, and current asset record; each source has a named owner. > - **Permitted output:** Recommendation and follow-up question in draft form. > - **Decision owner:** Facilities reviewer approves the next step. > - **Exception operator:** Named person investigates missing sources, access failures, and conflicting records. > - **Pause or retirement:** The process owner can suspend the workflow and decide when it should be revised or withdrawn. > - **Decision:** Approve a draft-only pilot with the listed sources and review point. This record separates routine operation from the human decision. It does not assume that a platform setting enforces each rule; confirm controls in the connected systems. ![Six linked oversight steps—set boundaries, test, review, decide, monitor, and reassess—surround a person responsible for the decision](/content/knowledge/visuals/governance.svg) *A responsible person stays at the center of the review cycle.* ## Review the operating questions | Area | Question for the team | Evidence or owner to record | |---|---|---| | Purpose and users | What exact task is supported, who may request it, and who is affected by its output? | Job statement, intended users, process owner, and any excluded cases. | | Information | Which sources are approved, who maintains them, and what happens when they are missing or conflict? | Source list, data owner, freshness expectation, and exception route. | | Actions and decisions | What may the agent read or prepare, what actions remain unavailable, and where must a person decide? | Read/write scope, reviewer, approval boundary, and stop condition. | | Quality and release | Which cases must work, what failure blocks the pilot, and who accepts the evidence? | Test set, acceptance criteria, evaluation owner, and decision date. | | Daily operation | Who sees exceptions, who responds to a failure, and who can pause the workflow? | Operator, response channel, available run records, and pause owner. | | Change and retirement | Who approves changes to the job, sources, tools, or audience, and who can withdraw the workflow? | Change owner, affected checks, rollback or disable path, and retirement decision. | Assign one accountable owner for the end-to-end job even when security, privacy, operations, and subject-matter reviewers contribute. Give each contributor a clear decision to make rather than treating “the team” as a single approver. ## Keep the checklist distinct from a cost review This checklist answers who is responsible, what evidence supports the workflow, and how the team operates or stops it. A separate cost review can define budgets, usage limits, and cost per completed task. Link those records, but do not use a cost limit as a substitute for a named operator or a quality decision. For this example, the facilities owner could pause the pilot if the policy is unavailable or the asset record cannot be checked. The reviewer could reject a recommendation that lacks evidence. The team records each decision and revises the job before testing it again. ## Revisit governance as the work changes Review the record before expanding the user group, connecting a new source, enabling a new action, or changing the review point. Recheck it after an incident or repeated exception. If no owner can explain the current scope or take responsibility for the next step, pause expansion until that gap is resolved. Use [governance and cost controls](/knowledge/ai-governance/ai-agent-governance-and-cost-controls) for the separate operating-cost review, the [security review checklist](/knowledge/ai-governance/ai-agent-security-review) for security intake, and [agent change management](/knowledge/ai-governance/ai-agent-change-management) to assess material updates. ### AI Agent Observability: What to Track - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-observability - Language: en - Description: Track workflow activity, errors, handoffs, and resource signals so an owner can investigate a run and decide what needs review. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) An agent returns an incomplete answer. Did a document or tool fail? Available, protected run records can help investigate the cause. Evaluate answer quality separately. ## Follow one request through a run Imagine a facilities team asks an agent: “Review this equipment replacement request against the current policy and inventory record. Flag missing details and prepare a recommendation for review. Do not place an order.” The agent may read the request, the approved replacement policy, and the inventory record. It can prepare a draft, but a person decides what happens next. The inventory lookup times out. The trace records the failed lookup, and the draft remains incomplete. *Illustrative fields and timings, not an SDK schema or measured result. All rows: run `demo-042`, configuration `v3`. Source categories omit request contents and personal data.* | Step | Source or operation | Outcome | Duration | Retries | | --- | --- | --- | --- | --- | | 1 | Read submitted request | Success | 120 ms | 0 | | 2 | Read approved replacement policy | Success | 80 ms | 0 | | 3 | Read inventory | Timeout | 2,000 ms | 0 | | 4 | Prepare review draft | Incomplete: inventory unverified | 350 ms | 0 | **Final state:** The automated run stopped with an incomplete draft; the business decision remains pending review. No order operation was invoked. The trace shows that the inventory read timed out. It does not explain why or tell you whether the draft is accurate. **Inventory-timeout rate** Runs with at least one inventory timeout ÷ runs that attempted an inventory lookup in the same reporting period. - Count each run once, even if it retries. - Exclude runs that never attempted an inventory lookup. - Report how many runs lack telemetry. **Illustrative day: 4 / 50 = 8%.** This is an operational measure, not a measure of answer quality. ![Illustration of an agent run producing events that an operator examines to understand what happened](/content/knowledge/visuals/ai-agent-observability.svg) *A run produces events for an operator to investigate.* ## Choose signals that answer operating questions | Signal | What it can help answer | What to verify | |---|---|---| | Run identity and configuration version | Which task and setup produced this result? | Can the team tie a run to the job, date, and active configuration without exposing unnecessary content? | | Step and tool outcomes | Which sources were read, which tools ran, and where did the workflow stop? | Are success, failure, and skipped steps distinguishable? Are permission denials visible? | | Timing and retries | Was the run delayed, repeated, or left incomplete? | Can the team tell a safe retry from a repeated action with side effects? | | Handoff and completion state | Did the case go to a person or another system, and was it accepted or finished? | Do the available records distinguish “sent,” “accepted,” “completed,” and “unresolved”? Use the [agent handoff guide](/knowledge/agent-design/agent-handoffs) to define the receiving system’s acknowledgment and completion states. | | Resource and usage signals | Which runs consumed more computing resources or used more external services than expected? | What resource use is recorded, when is it available, and how does it relate to billing records? | A **trace** follows the request to the timeout. A **metric** shows how often it happens. An **event log** records the failed lookup. Check what your system captures: some omit inputs, tool results, or entire record types. Access, retention, and export settings govern what you can inspect. ## Keep observability separate from evaluation Use run records to ask what happened: which source failed, whether a tool was called, or when a handoff occurred. Use an evaluation set and reviewer criteria to ask whether the result met the job. A complete trace can still document a poor answer; a run with a short trace may still produce a useful draft. Before a pilot, choose a few cases that matter: a routine request, an unavailable source, conflicting information, and a request outside the job. For each, name the signal that would reveal the outcome and the person who will investigate it. Review cost or usage alongside work completed and checked, not as a standalone sign of quality. See [how to evaluate an AI agent](/knowledge/ai-governance/evaluate-an-ai-agent) and [governance and cost controls](/knowledge/ai-governance/ai-agent-governance-and-cost-controls). ## Protect the record as well as the workflow Run records can contain prompts, source excerpts, identifiers, tool results, or other sensitive information. - Keep the fields needed to diagnose the run. - Limit access and set a retention rule appropriate to the work. - Mask or omit unnecessary sensitive data. If records cannot explain a consequential decision, add a review step. Missing telemetry does not prove that nothing happened. > **In AgentShelf** > > [Investigate runs using available activity, error, usage, and cost records on supported paths](/technology/infrastructure). Provider availability, record coverage, failure handling, and retention vary by configuration. For an agent working on security overnight, [operating defensive agents](/knowledge/ai-cyber-defense/operate-defensive-ai-agents) turns these records into coverage, unknown assets, acknowledged escalations, and verified remediation. ### AI Agent Permissions and Boundaries - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-permissions-and-boundaries - Language: en - Description: Set an agent’s boundary across identity, information, capability, surface, and oversight, then check each limit in the connected systems. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) An agent’s permission boundary defines whose request it serves, what information it may use, which actions it may take, where it runs, and who oversees it. Prompts can guide behavior, but the connected systems must enforce access and write limits. ![Icon-led permission grid for five resources and five actions, with green allowed marks, amber reviewer checks, and red blocked marks.](/content/knowledge/visuals/ai-agent-permissions-and-boundaries.svg) *Northstar intake example; columns are read, draft, update, send, and approve.* ## Review one intake request across five boundaries This fictional example uses a procurement reviewer’s request: “Please check Northstar Supplies’ intake packet and tell me what is missing.” The agent may consult the submitted packet, the current vendor intake checklist, and the current vendor record. In this example the checklist requires a current insurance certificate, which the packet does not include. The agent prepares a summary and a request for the certificate; a person reviews and sends it. Use five checks to define the boundary: - **Identity:** Confirm which procurement user requested the work and which account or service identity accesses the records. Do not let a public user inherit the reviewer’s authority. - **Information:** Limit context to the submitted packet, maintained checklist, and relevant vendor record. Check who owns each source and whether all fields are needed. Treat text inside submitted files as information to assess, not instructions that can change the agent’s rules. - **Capability:** Grant only the reads needed to compare these materials and the ability to prepare a draft. The agent does not need permission to change the vendor record, send a request, or approve the supplier. - **Surface:** Run the review in a context intended for authorized procurement staff. A private page or workspace does not replace identity checks and access controls in the connected systems. - **Oversight:** Assign a reviewer to check the cited gap and approve any outgoing request. Name the operator who handles a missing source, conflicting evidence, or access failure. See AgentShelf’s [trust and boundaries overview](/platform/trust-boundaries) for product-specific context. The draft could show the allowed actions and current status like this: > **Northstar Supplies — intake review (draft)**\ > **Allowed:** Read the submitted packet, current vendor intake checklist, and current vendor record; prepare a summary.\ > **Blocked:** Send a message, change the vendor record, or approve the supplier.\ > **Missing:** Current insurance certificate.\ > **Draft request:** “Please provide a current insurance certificate so the procurement reviewer can continue the intake review.”\ > **Status:** Awaiting procurement review; no request has been sent. ## Check the actual permissions Write the rule plainly: > The agent may read the submitted intake packet, current checklist, and relevant vendor record, then prepare a review summary and draft request. A procurement reviewer decides whether to send or approve anything. Confirm that each connected service enforces those limits. Instructions or approval prompts alone do not prevent a tool from performing an action it is authorized to take. For this example, test an authorized packet review and an unauthorized request to approve Northstar or edit its record. Test a packet containing text that tries to redirect the agent to another task. The system should deny or route the unsupported action, keep unrelated records out of the answer, and give the reviewer enough evidence to understand the draft. ## Keep a review record Before the pilot, document the owner, intended users, sources, read and write access, surface, approval point, failure path, and person who can pause the workflow. Recheck these details when the user group, data, integration, job, or deployment surface changes. Pair this review with [human approvals and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents) and [representative tasks and failure cases](/knowledge/ai-governance/evaluate-an-ai-agent). See the [defensive agent example](/knowledge/ai-cyber-defense/defensive-ai-agents) for a tested production-action denial and separate agent-completion and exposure-closure checks. ### AI Agent Security Review Checklist - Route: https://agentshelf.ai/knowledge/ai-governance/ai-agent-security-review - Language: en - Description: Review an agent’s users, information flows, identities, tools, dependencies, tests, and response owners before expanding its access or use. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) A security review for an AI agent maps who will use it, what information it handles, which systems it can reach, and how the team will respond to failure or misuse. Use the review to decide whether a bounded test can proceed and which issues must be resolved first; it is not a security certification. ## Start with one supplier-document request A procurement team asks an agent: “Compare this supplier packet with the approved onboarding requirements. Identify missing documents and prepare a request for review. Do not send a message or change the supplier record.” In a fictional access test, the agent reads the assigned packet and requirements. The send and update operations are denied, but the supplier-record scope has not been verified. A reviewer is responsible for any outgoing request. The completed security intake records the verified test results and keeps expansion on hold: > **Supplier-document review — security decision** > > - **Information:** Submitted packet and approved requirements; a named owner maintains each source. > - **Identity and audience:** Authorized procurement staff request and review the work; the public surface has no access to the packet. > - **Capabilities:** Read the two approved sources and prepare draft text. Sending and supplier-record changes are outside scope. > - **Test result:** Assigned packet and requirement were readable; send and update operations were denied. Supplier-record scope remains unverified. > - **Decision:** Hold expansion until the record scope and exception path are confirmed. The sample separates what the workflow intends from what the connected systems must enforce. A written instruction is not evidence that a tool cannot perform a restricted action. ![Permission matrix comparing Packet, Checklist, Record, Message, and Approval resources with read, draft, update, send, and approve actions, marked allowed, subject to review, or blocked](/content/knowledge/visuals/ai-agent-permissions-and-boundaries.svg) *Use the resource-and-action matrix as one part of the wider security review.* ## Work through the security questions | Review area | Questions and evidence | |---|---| | Purpose, users, and data | What exact task is in scope? Which people use the agent, what data enters, and which output may affect a person, record, or process? Draw the path from source to model, tool, and recipient. | | Identity and access | Which user, service, or application identity makes each request? Can the connected system limit that identity to the required records and operations? How are credentials protected, rotated, and revoked? | | Tools and side effects | List each tool, operation, read/write scope, and consequential action. Can it send, publish, update, delete, or approve? Remove capabilities the job does not need and test that blocked actions are rejected by the connected system. | | Untrusted input and output | Can a user, document, or retrieved page contain instructions that conflict with the job? Check how untrusted content is treated and whether generated output is validated before another system acts on it. | | Dependencies and exposure | Identify model, connector, service, library, and data dependencies. Check where information is sent, what is returned, and which parties can access the stored records. | | Testing and response | Try ordinary, malformed, conflicting, out-of-scope, and deliberately misleading inputs. Name the security contact, incident route, operator, records available for investigation, and condition for pausing the workflow. | Choose review depth according to the data, audience, actions, and consequences. A pilot that only prepares a draft still needs boundaries, but an agent that reaches sensitive systems or can trigger external changes deserves closer security and privacy review. ## Keep security approval separate from workflow quality Security review asks whether the access paths, data handling, and controls are appropriate for the proposed deployment. Evaluation asks whether the agent produces useful and accurate results on representative work. Human review decides whether an individual result or action is acceptable. A successful test in one area does not settle the others. For the supplier example, the reviewer can approve a limited pilot only after a test confirms that the agent can read the intended packet and requirements, cannot send or update, and leaves a clear handoff when a source is unavailable. Record the tested configuration and outstanding issues. If the actual permission behavior is unknown, keep the pilot on hold. Revisit the review when users, data sources, model, tools, audience, or output actions change. For per-tool checks, see [review an agent’s tools and data access](/knowledge/ai-governance/review-agent-tools-and-data-access); for outcome testing, see [how to evaluate an AI agent](/knowledge/ai-governance/evaluate-an-ai-agent). The broader [permissions and boundaries guide](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) covers the agent’s information and action limits. For an agent assigned to defend your systems, apply this review to [a defensive job brief](/knowledge/ai-cyber-defense/defensive-ai-agents) and the [software and suppliers it trusts](/knowledge/ai-cyber-defense/ai-supply-chain-security). ### Evaluate an AI Agent - Route: https://agentshelf.ai/knowledge/ai-governance/evaluate-an-ai-agent - Language: en - Description: Evaluate an agent by testing representative tasks, tool use, failure handling, and approval boundaries before widening access. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent evaluation checks whether the configured workflow does its job, uses only allowed information and actions, and handles failure safely. For example, imagine a Northstar Supplies onboarding agent asked to prepare a procurement brief from an intake packet, an approved checklist, and the current vendor record. It must flag a missing insurance certificate and draft a request for review; it must never approve the vendor or send the request on its own. ![Illustrative Northstar Supplies evaluation scorecard across routine, missing-evidence, conflicting-record, and lookup-failure cases](/content/knowledge/visuals/evaluate-an-ai-agent.svg) *Illustrative scorecard, not measured results.* In this sample: - **Routine packet:** Passes all four checks. - **Missing evidence:** Produces a useful draft within its limits, but its process and recovery need review. - **Conflicting records:** Fails because the draft neither resolves nor clearly hands off the disagreement, even though it respects permissions. - **Tool failure:** Cannot complete the requested brief, so its outcome fails. Its process, limits, and recovery pass because it reports the failed lookup and hands off safely. A safe handoff and a completed task are separate results. For this illustrative release decision: - **Stop:** A permission breach or unknown side-effect state blocks the run; resolve it before resuming. - **Revise:** A correctable evidence or handoff gap must be fixed and retested before widening. - **Widen:** Consider it only after affected cases meet their written expectations and the owner accepts the evidence. **Decision for these sample results: revise before widening.** The conflicting-record case does not hand off clearly, and the missing-evidence case needs procedure and recovery review. The tool-failure case passes process, boundaries, and recovery while its business outcome remains incomplete. ## Define the expected result Before testing, write down what a good run must contain and what it must not do. For this example, the agent should compare the packet with the checklist, ground each finding in the supplied materials, call out the missing certificate, and leave both the approval and outgoing message to a person. A polished brief that invents evidence or sends the request is a failed run even if its wording looks convincing. Choose a workflow owner and a reviewer who can judge whether the brief is useful. Agree which errors block a pilot, which can be handled with review, and which can be tracked. Set thresholds for the consequences and the team’s review capacity. Write these expectations into [a focused agent job brief](/knowledge/agent-design/define-a-focused-agent-job) so the task, evidence, allowed actions, and stop conditions stay fixed while you test. ## Test a representative set Use a small set of safe, representative packets: - One complete packet. - One missing the certificate. - One with conflicting details. - One with an unreadable attachment. Record the expected result and why it is correct for each packet. Include varied phrasing and requests outside the agent’s job. Use synthetic or appropriately protected data in the test environment. Keep the task and success criteria fixed as the packet changes. This makes it easier to see whether a result changed because of the evidence, the prompt, or the configured tools. Repeat runs when the same input can produce different results, and inspect the steps as well as the final brief. ## Inspect the run and draft Check which sources the agent read, what it extracted, whether it used the permitted lookup, and whether it stopped before approval or sending. Review the returned draft for missing facts, unsupported claims, and clear ownership of the next step. Illustrative output using fictional Northstar Supplies records: > **Northstar Supplies — onboarding draft** > > - **Finding:** A current insurance certificate is missing from the intake packet. > - **Draft request:** “Please provide a current insurance certificate so procurement can continue its review.” > - **Decision:** Vendor approval has not been made; a reviewer must approve any outgoing request. This sample is not a real vendor record or a measured system result. In a test, verify that the missing-document finding matches the packet and checklist, that the message stays a draft, and that no approval or send action occurred. ## Probe failures and score the result Test a missing source, an unreadable file, a tool error, conflicting records, an irrelevant instruction inside a document, and an unanswered or rejected approval. The agent should explain what it could not verify and route the case as designed. Score four things separately: | Measure | What to check | | --- | --- | | **Outcome** | The brief’s accuracy and usefulness. | | **Process** | Whether the agent followed the allowed sequence. | | **Boundaries** | Whether it stayed within its permissions. | | **Recovery** | Whether it recovered or handed off clearly. | Use direct checks for required fields and unchanged records, and human review for judgments that need subject knowledge. Compare automated grades with reviewer decisions before using them to triage runs. ## Retest before widening access Keep the task set, agent version, configuration, results, reviewers, limitations, and decision together. When something changes, rerun the case that exposed the issue and nearby cases. Treat results as evidence about the tested setup and scenarios, then identify what still needs human review before expanding the pilot. For related checks, read [AI agent governance and cost controls](/knowledge/ai-governance/ai-agent-governance-and-cost-controls) and [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). ### LLM Budget Management: Set Limits and Assign Owners - Route: https://agentshelf.ai/knowledge/ai-governance/llm-budget-management - Language: en - Description: Manage LLM spending with monetary budgets, named owners, clear periods, and verified hard or soft limits for the request paths your agents use. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) LLM budget management turns a spending allowance into an operating rule: who may spend, on which workflow, over what period, and what happens at the limit. Start with a monetary budget and a named owner, then verify the request path that will apply it. A spending report alone cannot stop a request. ![An owner defines scope, amount and period, verifies the request path, then chooses warning and continuation or rejection.](/content/knowledge/visuals/llm-budget-management.svg) *Ownership, request coverage, and the response at the limit belong in the same record.* ## Set the amount from useful work Estimate expected task volume and observed model cost per acceptable completed task. Include repeated attempts in the pilot measurement. Estimate connected services and human review separately so model spending does not stand in for the total operating cost. Fictional example: Cedar Services expects 400 reviewed intake summaries in a month. A pilot measures average model cost of USD 0.20 per accepted summary, including repeated attempts. That gives a USD 80 planning baseline. The owner chooses a hypothetical USD 100 allowance for variation and reviews it weekly. These figures illustrate planning; they are not AgentShelf prices or promised costs. Write down the currency and the budget period's start and end. Verify how the configured policy represents that period before launch. Do not treat the allowance as a prepaid balance or assume a calendar boundary has reset a limit without checking the active policy. ## Choose a scope and owner AgentShelf supports monetary budgets at organization, team, user, and widget scopes. Organization admins choose hard or soft budgets. Match the scope to the responsibility you intend to assign. | Scope | Planning question | Owner to record | | --- | --- | --- | | Organization | What allowance covers the organization? | Organization budget owner | | Team | What allowance supports this team's work? | Team budget owner | | User | What allowance supports this person's use? | Person responsible for the allocation | | Widget | What allowance supports this website surface? | Website operations owner | Role and group are not additional budget scopes. Agent and workspace reporting provides visibility, not separate budget enforcement. Token counts can explain usage, but these budgets are monetary limits, not direct token caps. If several scopes apply, verify the policies with the actual request rather than assuming a precedence rule. ## Choose the response at the limit On covered paths with an active policy, a soft limit warns and allows requests to continue. A hard limit rejects covered requests when the applicable limit is reached. A warning signals an operator; it does not by itself authorize or reject requests. Cedar's organization admin might choose a hard allowance because summaries can wait for a spending review. Another workflow might use a soft allowance so work continues while the owner investigates. Record who reads warnings, who decides on additional spending, and how people handle work that cannot proceed. Soft budgets need an active response owner because spending can exceed the allowance. ## Verify coverage before relying on a limit Supported authenticated workspace and external-agent requests can apply organization, team, and user policies. Supported widget requests can apply organization and widget policies. Enforcement requires a supported request path and an active policy; other paths can continue without a budget check. Test the real entry point in a controlled pilot. Confirm attribution to the intended scope and verify the configured warning or rejection. Document uncovered paths and assign an operator. A cost record demonstrates reporting, not that a budget check ran. ## Record a budget policy you can verify Keep a one-page record of each budget next to the workflow it pays for. The agent can draft it from the workflow description and its recent usage, and the budget owner confirms the amount, the limit behavior, and the people involved. > **Budget policy record (blank)** > > - Amount, currency, and period (with start and end dates): ___ > - Scope (organization, team, user, or widget), and whose spending it covers: ___ > - Budget owner, organization admin, who receives warnings, and who handles exceptions: ___ > - How requests reach the agent (workspace, external agent, or website widget), and the active policy: ___ > - At the limit: warn and continue (soft), or reject (hard): ___ > - Test: one controlled request showing that spending is counted against the right budget and the limit behaves as set: ___ > - When to review spending, and who may change the policy or confirm a reset: ___ For Cedar Services, the record would show USD 100 a month at team scope. The budget is hard, because summaries can wait for a spending review. The team lead owns the budget and reads warnings, and a test request was rejected at the limit before launch. ## Can budgets apply to roles, groups, or token quotas? Not directly. AgentShelf budgets are set for an organization, a team, a user, or a website widget. To give a role or group its own allowance, put those people in a team and budget the team, or set budgets for each user. Budgets are set in currency, not tokens. Token counts help explain *why* spending went up, because longer inputs and more attempts both use more tokens, but the limit itself is an amount of money. Rate limits, which cap how fast requests can be sent, are a separate control from budgets, so ask about them separately. Before you run more agents at once, check the expected workload, how often tasks need repeat attempts, whose budget the spending lands in, and whether every request is covered by a budget. Then raise the allowance. Reports by agent or workspace show where money goes, but the budget itself still applies at the organization, team, user, or widget level. The [cost-per-completed-task worksheet](/knowledge/ai-governance/ai-agent-governance-and-cost-controls#calculate-cost-per-completed-task) helps you understand the workload before you change a policy. ## Review changes before raising limits Use this launch checklist: - Name the budget owner, organization admin, and exception responder. - Record amount, currency, period, scope, and expected workload. - Confirm the active policy and supported request path. - Verify soft continuation or hard rejection and the human fallback. - Review spending, completed tasks, repeated attempts, and quality together. - Record why an allowance changes and when to review it again. If Cedar spends faster than expected, check volume, longer inputs, and repeated attempts first. Raise the allowance after the owner understands the change. Read the [cost governance framework](/knowledge/ai-governance/ai-agent-governance-and-cost-controls) for the wider process and [AgentShelf's LLM budget controls](/platform/governance-cost-controls) for current product scope. If a provider key may be exposed, use [exposed-key response](/knowledge/ai-cyber-defense/exposed-ai-api-keys). A gateway budget covers supported request paths; revocation and recovery require the issuer and every affected consumer. ### Review an Agent’s Tools and Data Access - Route: https://agentshelf.ai/knowledge/ai-governance/review-agent-tools-and-data-access - Language: en - Description: Inspect each connected tool for its identity, data scope, allowed operations, side effects, returned information, and failure behavior. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Review an agent’s tools one operation at a time: confirm what each can read or change, which identity it uses, which records it can reach, and what evidence shows that limits work. A workflow-level instruction does not replace access checks in the connected system. ## Review one equipment request A facilities coordinator asks an agent to check a replacement request against the approved equipment catalog and current stock list, then prepare draft text for review. The agent may read the assigned ticket, approved catalog, and stock for the requested item at the assigned site. It cannot submit a purchase or update inventory. In this fictional test, the lookup tools run as a dedicated facilities service account. The connected systems permit the assigned ticket and item/site stock lookup, while denying an unrelated ticket and stock at another site without returning their contents. An unapproved catalog item is excluded; purchase submission and inventory updates are unavailable. The agent returns draft text to the coordinator rather than writing a requisition to another system. The completed review is: | Operation | Identity and scope | Access and side effect | Return and failure response | |---|---|---|---| | Ticket lookup | Facilities service account; assigned request only. | Read is allowed; an unrelated-ticket lookup is denied by the ticket system. | Return assigned-request fields only; the denial returns no record details. The operator handles a failed lookup. | | Catalog lookup | Facilities service account; approved items and requirements. | Read is allowed; no catalog-edit operation is available. An unapproved item is excluded. | Return the approved item and requirements. If the source is unavailable, do not infer its contents; route the lookup failure to the operator. | | Stock lookup | Facilities service account; requested item at the assigned site. | Read is allowed; another-site lookup is denied without revealing its contents. | Return availability for the assigned site only. If the lookup fails, leave stock unverified and route it to the operator. | | Requisition draft | Agent workflow returns text to the facilities coordinator; no connected-system identity is used for this output. | Preparing draft text is allowed; purchase submission is unavailable. | Return a draft for review. If a required lookup failed, mark it incomplete and do not submit a purchase. | | Inventory update | No identity or update operation is granted. | Blocked; it would change the inventory record. | No inventory data changes. If an update path is present in the configured system, hold the pilot until its denial is verified. | **Decision:** Allow a bounded pilot for the listed read and draft operations; an operator handles lookup failures. This review checks the actual tools and data paths for the example. It does not imply that a named platform supplies these controls; confirm each operation in the configured system. ![A task at the center of four connected categories: knowledge, skills, tools, and connections](/content/knowledge/visuals/knowledge-skills-tools-and-connections.svg) *Knowledge, procedures, tools, and connections play different roles in one task.* ## Use one row for each tool operation | Check | Questions to answer | |---|---| | Owner and purpose | Who owns the source or service? Which step of the job needs this operation? | | Identity | Does the call run as a user, agent, service, or shared account? Whose access does that identity represent, and can it be revoked? | | Scope | Which records, folders, fields, or tenants are reachable? Can the system constrain the request to the relevant case? | | Operation and side effect | Is the tool reading, searching, creating a draft, submitting, updating, deleting, or sending? What downstream effect follows? | | Data returned or sent | Which fields come back to the agent, and what information leaves for the connected service? Can unnecessary fields be omitted? | | Validation and failure | How are inputs checked? What happens on denial, timeout, malformed output, or duplicate request? Is it safe to retry? | | Evidence and review | Which allow and deny tests show the real behavior? Who can see failures and investigate them? | Do not treat a service’s label as its full permission scope. A tool called “lookup” might expose broad search results; a tool called “draft” might save data in a shared location. Inspect its actual arguments, return values, side effects, and account permissions. ## Test both the permitted and blocked paths For the equipment example, test an assigned ticket, an unrelated ticket, permitted and blocked item/site stock lookups, a catalog item that is not approved, a request to submit a purchase, and a timeout followed by a retry. Confirm which system enforces each decision. The agent should receive only the intended item and should not gain additional access because a person asked it to ignore the boundary. Retest when the connector, account, scope filter, operation, or agent job changes. Separate this per-tool review from the audience and workspace review in [operating boundaries](/knowledge/ai-governance/agent-operating-boundaries), and pair it with the [security review checklist](/knowledge/ai-governance/ai-agent-security-review). For the broader distinction among approved information, procedures, tools, and connections, see [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections). For security workflows, extend this per-tool review with [software supply chain security with AI](/knowledge/ai-cyber-defense/ai-supply-chain-security), connecting provenance and deployed artifacts to the access each component holds. ### Manage Unapproved AI Use in Your Team - Route: https://agentshelf.ai/knowledge/ai-governance/shadow-ai-governance - Language: en - Description: Make AI use visible through clear guidance, a safe reporting path, proportionate risk review, and an approved way to do useful work. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Give staff clear rules for AI use, an easy way to ask for help, and an approved way to do the work. When you learn about unapproved or undisclosed use, first find out what task was done, what information was shared, which account was used, and what actions were taken. Match the response to what was actually exposed. ## Understand one undisclosed use case An employee reports using an AI service that the organization has not reviewed to summarize an internal support ticket and draft a reply. The employee confirms sharing the ticket’s contact field and service-problem description from a personal account, using no connected systems. The draft has not been sent. The organization cannot verify whether the external service retained the information. The initial review records the confirmed facts, pauses further sharing, and gives the data and security owners a clear next step: > **AI use review — initial decision** > > - **Task:** Summarize an internal support ticket and prepare a reply. > - **Confirmed:** Contact field and service-problem description were entered through a personal account; no connected systems were used. > - **Immediate step:** Stop adding internal ticket data while the data owner and security contact review the sharing. > - **Next step:** Use an approved workflow to draft the reply and keep a person responsible for sending it. > - **State:** No reply sent; external retention is unknown, so deletion is not assumed. This response focuses on a concrete exposure and a path to resume the useful work. It does not assume misconduct or claim that the organization can retract information already shared. ![Six linked oversight steps—set boundaries, test, review, decide, monitor, and reassess—surround a person responsible for the decision](/content/knowledge/visuals/governance.svg) *A responsible person stays at the center of the review cycle.* ## Build visibility without treating every use alike 1. **Publish plain-language guidance.** Say which kinds of information are allowed in which approved environments, which actions need review, and where to ask before trying a new tool. Update the guidance when an approved path changes. 2. **Offer a reporting route.** Publish the organization’s named AI-use or security intake channel; if there is no dedicated channel, direct staff to their manager and the designated data or security contact. Ask for the service, task, information category, account used, connected systems, and whether anything was sent or changed. Do not ask employees to paste sensitive content again when a description is enough. 3. **Create a proportionate inventory.** Record the use case, data types, user group, service or system, account owner, connected sources, outputs, and whether the result triggers another action. Keep only details needed for governance. 4. **Triage by exposure and consequence.** A low-impact task using public material may need documentation and an approved alternative. A workflow that shares sensitive records, connects business systems, or influences a consequential decision may need security, privacy, legal, or process-owner review before use continues. 5. **Resolve the workflow.** Support a suitable approved use, redesign its information and permissions, or stop a use that the organization cannot accept. Assign an owner and a review date. An inventory is a starting point, not a control by itself. Use it to connect each use to a responsible owner, an appropriate decision, and a maintained alternative. Avoid collecting employees’ personal prompts or unrelated activity just to increase visibility. ## Return to the task with a safer route For the support-ticket example, the data owner and security contact can decide whether the shared fields require incident handling under the organization’s policy. The team can then test an approved drafting workflow using a representative ticket, confirm what information it can read, and keep a person responsible for sending the reply. If an approved path is unavailable, document the unmet need and decide whether to defer the task. Do not treat an approval label or an internal account as proof that every data flow is appropriate. Confirm where information goes, who can access it, how it is retained, and whether the configured service supports the needed controls. Review the outcome when the tool, data, users, or connected actions change. Pair this process with the [team governance checklist](/knowledge/ai-governance/ai-agent-governance-checklist), [operating-boundaries guide](/knowledge/ai-governance/agent-operating-boundaries), and [security review checklist](/knowledge/ai-governance/ai-agent-security-review). For an approved agent assigned to investigate security exposure, [defensive AI agents](/knowledge/ai-cyber-defense/defensive-ai-agents) shows how to define the job, evidence, authority, and accountable owner. ### How to Share AI Agents Across Teams with Access Rules - Route: https://agentshelf.ai/knowledge/ai-governance/share-ai-agents-across-teams - Language: en - Description: Share reusable agents through submission, manager approval, and organization or team availability, with separate checks for data access and operating ownership. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Sharing an AI agent across teams requires an audience decision, manager approval, and a separate review of the information and actions the workflow may use. In AgentShelf, anyone can submit an agent to an organization or team library. Organization or team managers vet the submission and approve what makes the cut. ![A manager reviews a submission and approves organization-wide or team-member availability; data access is checked separately.](/content/knowledge/visuals/share-ai-agents-across-teams.svg) *Approve the audience deliberately and verify source access as a separate boundary.* ## Choose the audience before submitting An approved organization agent is available throughout that organization. An approved team agent is available only to that team's members. Choose based on who should use the job, not simply who helped create it. For several teams in the same organization, organization availability may fit if the job is suitable for the whole organization. If the work belongs to one team's process, submit it for that team. Resolve audience requirements with relevant managers before describing a team-only agent as shared more broadly. These rules cover sharing inside one organization, not between organizations. See [what an AI agent library is](/knowledge/ai-use-cases/ai-agent-library) for public versus internal collections. Public discovery, such as browsing the [AgentShelf Agent Library](/discover), finds candidates; internal approval decides what belongs in your collection. ## Submit a reviewable operating brief Give the manager enough evidence to assess the workflow. A short brief like this one gives the reviewer what they need: | Item | What the reviewer should learn | | --- | --- | | Job and audience | Who needs the agent and which result it prepares | | Sources | Which information is approved and who may access it | | Actions | What the workflow can do and where a person decides | | Tests | How missing evidence, conflicting records, and out-of-scope requests are handled | | Ownership | Who handles exceptions and maintains guidance | | Cost | Who owns the allowance and reviews usage | A reusable prompt may leave these decisions unresolved. Connect the brief to the [permissions review](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) and budget ownership record before routine use. ## Follow submission, approval, and availability 1. **Submit:** A contributor proposes the agent for an organization or team library with its intended use and evidence. 2. **Vet:** The relevant manager checks task, audience, boundaries, and operating ownership. Resolve gaps before approval. 3. **Approve:** The manager decides whether the submission is included. 4. **Verify availability:** Check organization-wide availability or restriction to team members, according to the approved scope. 5. **Review operation:** Confirm source access and actions with intended users and revisit after material changes. Approval for a collection does not grant access to every underlying dataset. Verify source access and tool authority separately. This availability workflow also does not determine who can edit an approved agent; confirm that responsibility through the applicable management process. ## Apply the rules to a fictional workflow Beacon Works has sales and service teams that want a common customer-meeting outline. The job uses an approved general template and produces a draft for a meeting owner. A contributor proposes organization availability because the outline is useful throughout Beacon Works. The organization manager reviews the job and tests. A sales example contains private deal notes; a service example contains restricted support records. The manager asks the contributor to separate the reusable meeting structure from access to those records. Sharing an agent does not make either team's source material available to the other. The recommended pilot includes an authorized user from each team and verifies which sources each may supply or read. The manager approves inclusion after the job and boundaries are clear. If the agent serves only the sales process, team availability is the appropriate proposal. ## Questions to ask any agent-sharing platform “Shared” is not one permission. It covers who can use an agent, what information it can reach, who approves it, and who looks after it. Ask each platform how it handles the questions below. The third column shows how AgentShelf answers them today. | Question | Why it matters | How AgentShelf handles it | | --- | --- | --- | | Who can use an approved agent? | The audience should match the job. | Organization approval makes an agent available across the organization. Team approval makes it available to that team only. | | Who decides what gets added? | Someone has to vouch for each agent. | Anyone can submit. Organization and team managers review submissions and decide what is added. | | Can each department keep its own data rules? | Shared agents must not widen data access. | Making an agent available does not change who can see the data. Each source keeps its own permissions, so review them for every team. | | Who can change the agent, and how are changes checked? | A change can break work for every team that uses it. | Name who may edit the agent and how changes are tested as part of the approval, and record it with the agent. | | Can you see how it is being used? | Owners need to spot problems and costs. | Usage and cost reporting covers spending by model, agent, and workspace where those details are recorded. Decide who on your team reviews it. | | Can another organization use it? | Sharing outside the company is a separate decision. | Library approval covers your own organization only. | For a template that touches business-unit data, settle two things separately: who may use the template, and what data each of them may read. Test with a real user from each team before launch. ## Sharing an agent is not sharing its results Sharing an agent decides who may *use* it. Sharing a finished brief or a set of notes decides who may *see* that result. One does not imply the other. Before you pass results around, check who the intended recipients are and whether the underlying information is restricted. [Workspaces and external agents](/knowledge/ai-agent-integration/workspaces-and-external-agents) covers the wider setup. ## Keep an owner after approval Approval is the start of an agent's working life, not the end of the review. Keep a short maintenance record with each approved agent. The maintainer can ask the agent to draft updates from its recent results and the problems users report, then confirm the record. > **Shared agent maintenance record (blank)** > > - Agent and approved audience (organization or team): ___ > - Maintainer, and the manager who approved it: ___ > - Information it uses and actions it may take: ___ > - Last review: date, changes, tests run, open questions: ___ > - Where users report a bad result, and who can pause the agent: ___ > - What triggers the next review (a source or policy change, a new audience, a failed test, repeated corrections): ___ > - Who decides to retire it, and where users go instead: ___ For Beacon's meeting outline, the maintainer reviews each new version of the template, while each team checks its own restricted records. If the agent were asked to *send* follow-ups instead of drafting them, that would be a new decision about its authority, and it would go back to the manager. Retirement is a decision your team makes and records. Name who receives problem reports and who brings changes back to the relevant manager. Review audience fit when membership, the task, sources, or actions change. Keep the current operating brief and tests accessible to the people responsible. Before expanding reuse, verify audience, approval, source access, actions, owner, and spending responsibility. Read [change management](/knowledge/ai-governance/ai-agent-change-management) for ongoing review and [AgentShelf's trust boundaries](/platform/trust-boundaries) for current product context. ### Reusable Agents and Business Use Cases - Route: https://agentshelf.ai/knowledge/ai-use-cases - Language: en - Description: Assess an agent pattern against your workflow, evidence, permissions, and review needs before choosing to reuse or build. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) A reusable agent pattern gives you a starting point for a recurring job. Its usefulness still depends on your inputs, allowed actions, expected result, and review process. ![Inquiry, vendor intake, and policy assistance share a task-and-review structure, with distinct input and result symbols for each job.](/content/knowledge/visuals/use-cases.svg) This path helps teams compare candidate workflows and assess whether an existing pattern fits. Start with the work, then inspect the pattern against it. ## Choose the job before choosing the agent Use [how to choose an AI agent use case](/knowledge/agent-design/choose-an-ai-agent-use-case) to compare candidate tasks. Prefer a first pilot whose output people can inspect and whose mistakes can be contained. Record what success means before browsing implementations. ## Compare three example jobs | Job | Shared path: input → task → result → review | What changes for your team | | --- | --- | | Visitor inquiry | Visitor question → find an approved answer → response and request summary → staff checks unclear requests. | Current service pages, contact route, and staffed hours. | | Vendor intake | Form and documents → check evidence and gaps → structured intake brief → owner verifies exceptions. | Intake requirements, allowed documents, and who resolves risk. | | Policy question | Question and role → find the applicable rule → sourced explanation or gap → policy owner reviews conflicts. | Current policy version, scope, and exception owner. | These examples share the same stages, but each depends on different source material, access limits, and review decisions. ## Reuse, configure, or build | Approach | Questions to resolve | | --- | --- | | Reuse a pattern | Does its intended job and output match ours? What must be reviewed before use? | | Configure a pattern | Can we adapt sources, instructions, permissions, and review points without changing the job? | | Build a custom workflow | Which requirement needs a different integration or operating process, and who will maintain it? | Reuse a pattern when its job, inputs, permissions, and limits already fit. Configure it when supported settings let you change sources, permissions, or review without changing the workflow. Build a custom solution only if a required workflow or integration need still cannot be met. ## Pilot the adapted workflow Write a [focused job brief](/knowledge/agent-design/define-a-focused-agent-job) and [evaluate representative work](/knowledge/ai-governance/evaluate-an-ai-agent). A promising demonstration does not settle whether the pattern fits your sources or operating boundaries. Browse the [Agent Library](/discover) for current listings. Use [agent design](/knowledge/agent-design) to prepare the configuration and [governance](/knowledge/ai-governance) to plan operation after the pilot. ## Defend the systems you run The [Cyber Defense learning path](/knowledge/ai-cyber-defense) covers ongoing security jobs with explicit authority and completion checks. Choose [a first defensive job](/knowledge/ai-cyber-defense/defensive-ai-agents) or use AI to [find, fix, and retire legacy systems](/knowledge/ai-cyber-defense/ai-legacy-system-security). ## All guides in this topic - [AI Agents for Internal Knowledge Work](/knowledge/ai-use-cases/ai-agents-for-internal-knowledge): Use an agent for internal questions when approved policies and procedures can support a reviewable answer and the workflow can route exceptions. - [AI Agents for Lead Qualification and Enrichment](/knowledge/ai-use-cases/ai-agents-for-lead-qualification): Use an agent to organize stated prospect needs against approved criteria, identify missing details, and prepare a human-reviewable follow-up. - [AI Agents for Meeting Preparation](/knowledge/ai-use-cases/ai-agents-for-meeting-preparation): Prepare a reviewable meeting brief from approved agendas, current records, and action notes while keeping decisions and commitments with people. - [AI Agents for Research Briefs](/knowledge/ai-use-cases/ai-agents-for-research-briefs): Use an agent to organize a bounded research question, compare approved sources, and draft a brief with traceable claims and visible uncertainty. - [Build vs. Reuse: When to Use an Agent Library or Build a Custom Agent](/knowledge/ai-use-cases/agent-library-vs-custom-build): Reuse a pattern when its job and limits fit; configure it when supported inputs differ; build custom when a real workflow requirement remains unmet. - [What Is an AI Agent Library?](/knowledge/ai-use-cases/ai-agent-library): Compare public discovery with approved organization and team libraries. ### Agent Library vs. Custom Build - Route: https://agentshelf.ai/knowledge/ai-use-cases/agent-library-vs-custom-build - Language: en - Description: Reuse a pattern when its job and limits fit; configure it when supported inputs differ; build custom when a real workflow requirement remains unmet. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Reuse an agent pattern when its intended job, information, actions, and review point match your workflow. Configure it when your differences fit supported settings. Build custom only when a necessary integration, control, or operating step remains unmet and your team can maintain it. Fictional example: Maple Freight wants to review supplier onboarding packets. A pattern in its approved Agent Library reads a packet, compares it with an intake checklist, flags missing evidence, and drafts a follow-up request. Maple’s workflow also needs to compare the packet with its current vendor record. The team cannot assume the pattern has that connection or can access it; it must verify the listing and allowed configuration first. ![Reuse when the job fits, configure supported differences, or build custom for a necessary unmet requirement; check sources and actions in every case.](/content/knowledge/visuals/agent-library-vs-custom-build.svg) *Choose by workflow fit, then verify sources and actions for the selected option.* ## Compare the three choices | Choice | Use it when | Check before committing | | --- | --- | --- | | Reuse | The pattern already covers the task and its expected output. | Does its source scope, authority, review point, and failure path fit your process? | | Configure | The task is the same, but approved sources, wording, or bounded options need to change. | Are these differences supported settings, and can you verify what each setting changes? | | Build custom | A required system connection, control, or operating step is outside the pattern’s supported scope. | Can the team test, secure, monitor, and maintain the added workflow? | ## Separate discovery, approval, and build effort A [reusable agent library](/knowledge/ai-use-cases/ai-agent-library) helps you find a starting point. Public discovery and internal approval are different steps: anyone can submit an agent to an organization or team library, and the relevant managers vet and approve what is included. Approved organization agents are available throughout the organization; approved team agents are limited to team members. Verify access to business data separately from that availability. Before comparing development effort, write the one requirement that could force a custom build. For Maple, it is authorized comparison with the current vendor record. A wording preference is usually a configuration question; a necessary unsupported connection or review state can change the architecture. Compare setup effort, testing, maintenance, and exception handling over the same operating period. Neither a library listing nor custom code removes those responsibilities. ## Test Maple’s request against the pattern Maple’s request is: “Compare the supplier packet with our approved intake checklist and current vendor record. List missing evidence and draft a request for review. Do not approve the supplier or send a message.” The packet and checklist match the pattern’s stated job. The current vendor record is an additional source, so Maple first checks whether the pattern can use that authorized source without changing the required approval boundary. If the source can be added through a supported setting, the team can configure and test the same pattern. If the library pattern cannot access the record but another approved read-only integration can provide it, the team may compare that integration with its requirements before building. If the required access, review step, or audit trail is unavailable, the agent does not fit yet. Custom development is justified only if that difference is necessary for the job and an owner can operate it. The decision note could read: > **Decision:** Test the existing supplier-intake pattern first. Its packet review, missing-evidence list, and draft request match the task. The vendor-record comparison is an unresolved requirement. Proceed only if an authorized read-only source can be configured and tested. Keep approval and sending with a procurement reviewer. The open question is whether the pattern can read Maple’s vendor record with the required permissions. Resolve that before committing to custom development. ## Record the reuse, configure, or build decision Write the decision down before the pilot starts. The record keeps everyone working from the same answer, and it shows the next owner why the choice was made. The agent can draft most of it from the listing, your job description, and the sources you name. The team confirms the job, the decisions people keep, the owner, and the final choice. > **Reuse, configure, or build decision record (blank)** > > - Job and what a good result looks like: ___ > - Candidate agent and date checked: ___ > - Information it needs, and who owns each source: ___ > - Connections the agent does not have yet: ___ > - What the agent may do, and what a person decides: ___ > - Test cases (ordinary, missing information, conflicting information, source unavailable): ___ > - Owner for problems, changes, costs, and retirement: ___ > - Decision (reuse, configure, or build): ___ > - What must be confirmed before going ahead: ___ Maple's completed record looks like this: > **Reuse, configure, or build decision record: Maple Freight (fictional)** > > - **Job and what a good result looks like:** Review each supplier packet, list missing evidence, and draft a request for the supplier. The agent does not approve suppliers or send messages. > - **Candidate agent and date checked:** The existing supplier-intake agent, checked against its current listing. > - **Information it needs:** The submitted packet and the approved intake checklist, both owned by procurement. Vendor-record access is not settled yet. > - **Connections the agent does not have yet:** Read-only access to the current vendor record. > - **What the agent may do, and what a person decides:** The agent compares, lists, and drafts. A procurement reviewer approves suppliers and sends every request. > - **Test cases:** A complete packet, a missing certificate, contradictory dates, and a vendor record that cannot be reached. > - **Owner:** The procurement process owner, who names the day-to-day operator before the pilot. > - **Decision:** Configure, as long as the vendor record can be added without giving the agent any new actions. Otherwise, pause and price the custom work. > - **What must be confirmed before going ahead:** That a supported, read-only connection to the vendor record exists and passes the four tests. The last line matters as much as the decision itself. When you compare options, compare them over the same workload and the same period. Include testing, repeat attempts, exceptions, and upkeep, not only setup. ## Verify the operating fit, not just the demonstration For any option, compare the real request, accepted output, approved sources, permitted actions, human decision, exception path, and owner. Inspect how incomplete data and conflicting records are handled. Try a representative test set, including an out-of-scope request and an unavailable source. A polished demonstration does not show whether the agent fits your own information or permissions. Estimate ongoing work too: source updates, connection credentials, reviewer time, version changes, error handling, and retirement. Reuse can reduce repeated design work, but it does not remove the need to validate the workflow. Custom development adds choices the team must document and maintain. Browse the current [Agent Library](/discover), then write a [focused job brief](/knowledge/agent-design/define-a-focused-agent-job) and [evaluate the adapted workflow](/knowledge/ai-governance/evaluate-an-ai-agent). For AgentShelf-specific configuration concepts, see the [agent harness overview](/platform/agent-harness). ### AI Agent Library: What It Is and How to Choose - Route: https://agentshelf.ai/knowledge/ai-use-cases/ai-agent-library - Language: en - Description: Find reusable AI agents, compare libraries with frameworks and prompt collections, and check task fit before approving an agent for your team. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) An AI agent library is a collection of agents people can find, assess, and reuse for defined jobs. A useful entry explains the task, expected inputs and outputs, operating boundaries, and maintenance responsibility. Reuse starts with that fit check, not with assuming that a listed agent can access your business systems. ![Public discovery leads to a fit check; internal submissions pass manager approval into organization or team availability.](/content/knowledge/visuals/ai-agent-library.svg) *Discovering a candidate and approving it for internal use are separate decisions.* Want to see available patterns? [Browse the AgentShelf Agent Library](/discover), then use the checks below to decide whether a candidate fits your job. ## Distinguish public discovery from internal reuse A public library or marketplace helps people discover agents for common tasks. An internal library establishes which agents an organization or team has approved for availability within its scope. They answer different questions: “What might help?” and “What belongs in our approved collection?” AgentShelf's public [Agent Library](/discover) is a discovery starting point. Organization and team libraries follow a separate workflow: anyone can submit an agent; organization or team managers vet submissions and approve what is included. Approved organization agents are available throughout that organization. Approved team agents are available only to that team's members. Library membership describes agent availability. Review access to sources and connected systems separately. Finding an agent in a library does not mean it can read every record your task needs. ## Know what kind of library you are looking at “Library” can mean three different things, and each leaves your team with different work. | Starting point | What you get | What your team still does | | --- | --- | --- | | Agent library | Ready-made agents, each built for a stated job. | Pick the job, connect your information, test the results, and name an owner. | | Development framework | Building blocks that engineers use to create agents. | Design, build, connect, and run the agent yourselves. | | Prompt collection | Instructions and examples to paste into an AI tool. | Supply everything else: the model, your information, the tools, the permissions, and the testing. | The lines can blur. A library agent may be built on a framework, and every agent contains instructions. What matters is how much of the job is already done when you start. ## Judge the library, then the agent A good library tells you, for every entry, what job the agent does, who maintains it, what information it needs, and where to report a problem. If entries leave those questions open, the size of the collection does not help. Once you have a candidate, try it on a small sample of your own work before anything else. Two public listings show how the fit question changes from job to job: - [Account & Prospect Researcher](/discover/account-prospect-researcher) prepares dated account briefs and maps the people involved. Check that its sources match the ones your sales team trusts. A well-researched brief tells you about an account; it does not tell you the account is ready to buy. - [Discovery & Meeting Copilot](/discover/discovery-meeting-copilot) prepares for meetings, captures what was said, and drafts follow-ups. Check what notes you can give it and who reviews each follow-up. Drafting a follow-up and sending it are separate steps, and you decide who takes the second one. Listings change over time, so check the current description before each new use. ## Look for a focused job “Prepare a meeting brief from approved notes” is easier to assess than “manage our operations.” Identify the request, sources, output, allowed actions, and human decision. Resolve unclear requirements before testing real work. | Check | Question to answer | | --- | --- | | Task | Does the agent do the same job you need? | | Inputs | Can authorized information be supplied through supported means? | | Output | Can a person assess the result against a clear acceptance rule? | | Authority | Does the action scope match your process? | | Operation | Who handles failures, changes, and retirement? | An internal review record can hold these answers even when a public listing does not. Keep it with the workflow owner so future users understand the approved use. ## Decide how ready-made the agent really is A ready-made agent brings the job: what to do, in what order, and what a good result looks like. Your organization brings the rest: its information, its terms, the systems it connects to, and the decisions people keep. An agent that prepares a meeting brief from notes you supply may work on day one. An agent that updates your customer records needs a connection to that system and your approval for each kind of change. That gives three paths: - **Reuse it** when the job already matches. Test it on your work and adopt it. - **Configure it** when the available settings cover the difference. Adjust, test, and adopt. - **Build your own** when a connection or control you need is missing and the gap is worth the ongoing cost of maintaining custom work. The [reuse, configure, or build decision record](/knowledge/ai-use-cases/agent-library-vs-custom-build#record-the-reuse-configure-or-build-decision) walks through the choice and gives you a template to keep. ## Work through a fictional decision Harbor Studio wants a repeatable way to prepare project-review meetings. Its coordinator discovers a candidate that summarizes notes and drafts an agenda. The output fits, but the studio must confirm how it will supply approved project notes and who checks the brief. Discovery identifies a candidate; it does not complete the review. The coordinator tests a fictional project with complete notes, a missing update, and conflicting deadlines. An acceptable brief states known facts, identifies the missing update, and leaves the conflict for the meeting owner. The agent must not quietly choose a deadline or distribute the brief before review. The coordinator submits the agent to the team library with the job statement, tests, source boundaries, and a named maintainer. The team manager vets the submission and decides whether it belongs in the collection. Team approval makes it available to team members; organization-wide availability is a separate scope decision. ## Keep reuse useful as work changes Reuse can reduce repeated design work, but operating responsibility remains. Review the agent when approved sources, the task, actions, or audience changes. Give users a clear way to report unsuitable results. An agent that fit one process version can become unsuitable after a policy update. Before adopting a library agent: - Describe the job and an acceptable result in one sentence. - Check sources and actions against your access rules. - Try ordinary, incomplete, and out-of-scope requests. - Assign an owner for corrections and future changes. - Record the audience and human review point. Use [library versus custom build](/knowledge/ai-use-cases/agent-library-vs-custom-build) to decide whether to reuse, configure, or develop. Read [sharing agents across teams](/knowledge/ai-governance/share-ai-agents-across-teams) for approval guidance. Current public candidates remain in the [Agent Library](/discover). ### AI Agents for Internal Knowledge Work - Route: https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-internal-knowledge - Language: en - Description: Use an agent for internal questions when approved policies and procedures can support a reviewable answer and the workflow can route exceptions. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent can help with internal knowledge work when employees need to find and apply current policies or procedures across approved sources. Keep the job narrow, show which source supports the answer, and route decisions that require an owner instead of presenting a generated response as policy. Fictional example: At Wrenfield Works, an employee asks, “Can I book an overnight train for the regional conference on October 14, and what approval do I need?” The agent may consult the current travel policy and the expense-submission guide. It may prepare an answer or a draft approval request, but a manager approves travel and the agent does not book tickets. ![Approved knowledge, a work method, a lookup capability, and an authorized system connection support one bounded task.](/content/knowledge/visuals/knowledge-skills-tools-and-connections.svg) *Internal knowledge work combines information with a permitted next step.* ## Pick a question with a checkable answer Good early candidates include questions about a current procedure, a policy’s stated requirements, or how to find the right internal form. Avoid combining several approvals or personal decisions into one broad “ask anything” agent. If an answer depends on a person’s role, region, account, or case history, confirm that the workflow can retrieve only the needed, authorized context. For Wrenfield, the travel policy says overnight travel requires manager approval before booking. The expense guide explains how to submit costs after travel. These sources answer the employee’s process question; neither decides whether a manager should approve this trip. ## Decide who maintains each source and who can read it Name the owner and audience for each source. Separate current policy from archived guidance, identify effective dates, and resolve conflicts before making files available. Apply access limits at the connected system: the agent should not gain access to personnel records or other private material just because it answers employee questions. For Wrenfield, the policy owner confirms the rule, and finance owns the submission steps. The agent only needs those approved documents. If the employee asks about an exception or a personal reimbursement balance, the workflow routes the question to the authorized manager or finance contact rather than searching unrelated employee records. ## Return an answer the employee can verify The answer should state the rule, link or identify the current source, and make the boundary clear. A suitable draft is: > **Travel guidance:** “The current travel policy requires manager approval before booking overnight travel. The expense guide explains how to submit costs after the trip. I can prepare an approval request for October 14; I have not booked travel or approved the trip.” The agent has answered from two approved documents and offered a draft next step. It has not made a booking or decision. If the policy version is unclear, the source is missing, or the employee asks for an exception, the answer should identify what needs confirmation and name the right owner. For a missing-answer case, suppose an employee asks whether a guest may attend the regional conference, and neither approved source covers guests. The agent should say that it found no approved answer, offer to ask the travel policy owner, and stop before booking or approving anything. A draft to that owner could read: “Please confirm whether a guest may attend the regional conference. The current travel policy and expense guide do not address guests; no booking or approval has been made.” ## Evaluate the workflow before broad access Test direct questions, paraphrases, outdated policy, conflicting instructions, role-specific requests, and cases outside the job. Check whether retrieved passages support the response and whether the route respects access limits. Include an example where the right behavior is to stop and ask a person. During a pilot, use information the organization has approved for evaluation, and restrict review access to people who need it. Define who updates each policy, how stale content is detected, and how employees can report a missing or wrong answer. Revisit the scope if source ownership, access, or approval rules change. For source setup, read [how to ground an agent in approved context](/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context) and [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections). Use [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) to review access, then [evaluate the workflow](/knowledge/ai-governance/evaluate-an-ai-agent) before broadening it. For a candidate to assess against your approved-source workflow, see the [Knowledge Base agent](/discover/knowledge-base). Verify its current scope and access requirements before using business information. ### AI Agents for Lead Qualification and Enrichment - Route: https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-lead-qualification - Language: en - Description: Use an agent to organize stated prospect needs against approved criteria, identify missing details, and prepare a human-reviewable follow-up. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent can compare an inbound prospect’s stated needs with approved service criteria. It can organize the relevant business information and flag what a person still needs to confirm. Make the criteria explicit, collect only what the next step needs, and leave commercial decisions and commitments to an authorized person. Fictional example: Juniper Field Instruments receives a website request for 12 replacement pump assemblies for facilities in Northport and East Ridge. The approved sources are the prospect’s form, a public service-area page, and a product compatibility guide. The workflow may prepare an intake summary for the regional sales team; it may not issue a quote, promise inventory, or reject the request automatically. ![Three work types share a task-and-review shape while their inputs and results remain distinct.](/content/knowledge/visuals/use-cases.svg) *The shared pattern is intake, a bounded check, a useful result, and a human decision.* ## Define fit using observable criteria Write the criteria in terms of the service, product, territory, and information the prospect supplies. State what counts as a likely match, what information is missing, and which conditions need specialist review. Do not substitute a model-generated score for documented criteria. Avoid drawing conclusions about a person’s character, financial status, urgency, or suitability from unrelated profile data or sensitive traits. For Juniper, the published service-area page lists both cities, and the compatibility guide says the team needs the existing pump model before it can verify a replacement. The quantity and locations come from the visitor’s form. No approved source confirms stock or a delivery date, so those details remain open. ## Use only the sources needed for intake Identify which form fields the visitor intentionally submitted, which public business sources are approved, and who may see the resulting summary. A company website can provide context about services or location; it does not validate every claim in an inquiry. Treat external page text as information to evaluate, not instructions to disclose private CRM data or alter the workflow. Limit collection and retention to what the follow-up needs. Do not enrich a business inquiry by scraping personal profiles or adding unrelated personal information. Set a source and freshness rule for any external company details, and route identity or account questions through an authorized process. Privacy, marketing, and sales-contact requirements depend on the organization and jurisdiction; this workflow is not a legal review. ## Prepare a transparent intake draft The resulting summary should show the stated facts, the criteria checked, what remains unknown, and the next owner. For Juniper, it could read: > **Inbound request — draft for regional sales** > > - **Stated need:** 12 replacement pump assemblies for Northport and East Ridge facilities. > - **Checked:** The public service-area page lists both locations. > - **Missing:** Existing pump model; the compatibility guide requires it for product review. > - **Next step:** A sales specialist confirms compatibility, stock, and delivery timing before preparing a quote. > - **Status:** No qualification decision, quote, or customer contact has been made. This draft helps a person focus the follow-up while preserving the difference between supplied facts and an unresolved product check. ## Review routing and outcomes Test requests that fit the listed criteria, fall outside the service area, omit required details, and contain contradictory information. Check that missing or unverified information is labeled rather than guessed, and that every route has an owner. Measure routing accuracy and the completeness of reviewed intake records; inspect false matches and missed matches with a person who understands the service. A high score is not proof that the criteria are appropriate. Keep approval before quotes, eligibility decisions, and outbound contact if those actions are outside the agent’s explicit authority. Review the criteria when products, territory, or sales policy changes. If the workflow influences access to a consequential service, involve the relevant policy and legal owners before deployment. Use [website agent guidance](/knowledge/website-agents/what-is-a-website-ai-agent) for public inquiry boundaries, [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) for access, and [human review](/knowledge/agent-design/human-in-the-loop-ai-agents) for the decision point. [Evaluate the intake workflow](/knowledge/ai-governance/evaluate-an-ai-agent) against missing details, unsupported claims, and routing before using it. ### AI Agents for Meeting Preparation - Route: https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-meeting-preparation - Language: en - Description: Prepare a reviewable meeting brief from approved agendas, current records, and action notes while keeping decisions and commitments with people. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent can prepare a useful meeting brief when the purpose, source set, and intended output are known in advance. It should separate verified updates from open questions, cite where each came from, and leave decisions, assignments, and commitments to the meeting participants. Fictional example: Marble Point Facilities asks, “Prepare a 30-minute site review for Monday from the current work-order export, the approved maintenance checklist, and last meeting’s action log. Highlight unresolved items. Do not reassign or close tickets.” The agent may read those three sources and draft an agenda; it cannot update the work-order system. ![A task brief organizes the owner, meeting trigger, inputs, output, and stopping conditions before review.](/content/knowledge/visuals/define-a-focused-agent-job.svg) *Define what the agent should prepare and which decisions belong to the meeting participants.* ## Set the purpose and source limits State who will use the brief, what the meeting must accomplish, and which records are current. Limit access to the relevant site or project. Do not import a full mailbox or unrelated customer history just to fill out the agenda. Assign owners to the checklist and action log, and record the date of the work-order export. For Marble Point, the current export lists an East Wing pump inspection as open. The last action log says the filter swap was completed, while the export still marks that task “in progress.” The maintenance checklist says the generator run test is due this quarter. These are concrete items to prepare for discussion, not proof that work was completed or that a ticket should be closed. ## Draft a brief people can act on Ask for an output that distinguishes source facts, conflicts, and decisions. A concise draft could be: > **East Wing site review — Monday** > > - **Purpose:** Confirm open maintenance work and the next safe steps. > - **Verified updates:** Current work-order export: the pump inspection is open. Approved maintenance checklist: the quarterly generator test is due. > - **Needs confirmation:** Previous action log: the filter swap is complete. Current work-order export: it is still “in progress.” Ask the work-order owner to verify the status. > - **Decision for the meeting:** Confirm the filter-swap status before closing the ticket. No ticket has been changed. The draft brings relevant evidence into one place while leaving conflicting records visible. It does not decide that the older action log or newer export is correct. The work-order owner confirms the status during the meeting. ## Keep the brief useful and current Use a format that fits the meeting: purpose, short agenda, confirmed updates, open questions, decisions needed, and source notes. Include the last-updated date and identify stale or missing material. If the agent cannot access a record, it should label that gap rather than fill it with an assumption. Prepare different views only for people authorized to see them. A leadership summary may not need the same detail as a technician’s work list. Remove unnecessary personal or customer information, and let a meeting owner correct the draft before it is distributed. ## Test before relying on the agenda Try a complete source set, a missing action log, a stale export, conflicting status, and an item outside the meeting scope. Check that the draft identifies each issue, does not invent attendees or due dates, and stops before assigning work. If a person reviews the document, test what happens when they edit, reject, or leave it untouched. For a repeatable task definition, read [how to define a focused agent job](/knowledge/agent-design/define-a-focused-agent-job). Use [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent) to check evidence handling and [human review](/knowledge/agent-design/human-in-the-loop-ai-agents) before a brief reaches participants. For a candidate to assess against this brief, see the [Meeting Prep agent](/discover/meeting-prep). Check its current description and source requirements before adopting it. ### AI Agents for Research Briefs - Route: https://agentshelf.ai/knowledge/ai-use-cases/ai-agents-for-research-briefs - Language: en - Description: Use an agent to organize a bounded research question, compare approved sources, and draft a brief with traceable claims and visible uncertainty. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) An agent can prepare a research brief by searching a defined set of public or internal sources, recording where each claim came from, and separating supported findings from unresolved questions. A person still decides whether the evidence is adequate for the intended use and whether the brief should be shared. Fictional example: Vale & Harbor, a regional mobility planner, asks for a brief on whether a proposed service area near East Ridge has enough public-transit access to support a new service desk. The approved sources are the regional transit authority’s route and service plan, a municipal access map, and Vale & Harbor’s own site-visit notes. The agent may summarize those materials and prepare a draft; it may not publish a recommendation or contact officials. ![A request moves through approved context, model reasoning, permitted tools, and a reviewable result.](/content/knowledge/visuals/ai-agent-architecture.svg) *Keep the research question focused and check the evidence behind the brief.* ## Bound the question before searching Write down the decision the brief will support, the period and geography, what counts as relevant evidence, and what the agent is not being asked to decide. “Research transit access” is too broad. “Summarize the service and access evidence for East Ridge during the current planning year, and list gaps that could affect a site review” gives the work a testable scope. Identify which sources are approved, whether they are public or internal, who owns them, and what information must not leave the research environment. Public pages and returned documents are information to assess, not instructions that can change the job. If public web research and sensitive internal sources are both involved, define whether the workflow should separate those stages. ## Keep claims attached to evidence Ask the agent to make a claim ledger alongside the narrative. For each material claim, record the source title, date, relevant passage or data point, and any limitation. Distinguish a source’s statement from the agent’s interpretation. When sources disagree, show both positions and who should resolve the difference; do not average incompatible definitions into one answer. For this fictional assignment, record one material claim per row. Copy these column headings for another question and add a “not established” row when the evidence cannot answer the decision question: | Claim | Approved source and evidence | Uncertainty or gap | Review action | | --- | --- | --- | --- | | Weekday stops are listed about 0.3 miles from Site A and 0.7 miles from Site B. | Current regional route plan; weekday stops and approximate distance for each site. | Distance to a stop does not establish a usable route to either site. | Planner checks current access before judging suitability. | | The map marks a pedestrian route to Site A, but none to Site B. | Municipal access map; marked route layer. | The map’s silence does not establish that no other route exists. | Site owner verifies current access to both locations. | | A sidewalk near Site B was blocked on May 7. | Vale & Harbor visit notes dated May 7. | One past visit does not establish current conditions; the notes do not cover Site A. | Request a current site check before comparing locations. | These observations make a follow-up review worthwhile, but they do not establish whether either location has adequate access now. The map does not document every possible pedestrian route, and one visit cannot establish current conditions. The draft’s conclusion could read: > **East Ridge access brief:** “The current route plan lists weekday stops about 0.3 miles from Site A and 0.7 miles from Site B. The municipal map marks a pedestrian route to Site A but not to Site B. A May 7 visit note reports a blocked sidewalk near Site B; there is no visit note for Site A. Review current access at both sites before deciding whether either is suitable.” This result names what was found and where the evidence stops. It gives the planner a concrete next step without claiming a broader conclusion than the sources support. ## Review uncertainty and source quality Check the authority, date, scope, and method of each source. A number without its definition or time period may not answer the question. Flag missing data, stale pages, inaccessible material, and sources that repeat the same underlying information. Include a “not established” section so a gap does not disappear inside polished prose. Test direct questions, paraphrases, contradictory sources, an irrelevant page, and a request outside the brief. Review both retrieval and synthesis: did the agent locate appropriate evidence, preserve its meaning, and avoid adding unsupported details? If the brief depends on calculations, check the inputs and method separately. ## Keep a person accountable for the brief Have a subject owner verify consequential claims before they guide a decision. Make the reviewer’s task easy by showing the question, source ledger, draft, limitations, and open issues together. Do not let a citation list substitute for checking that a citation supports the adjacent claim. For the research workflow’s source design, read [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections) and [ground an agent in approved context](/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context). Use [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent) to test evidence handling and review the [permissions guide](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) before connecting private material. ### AI Agent Glossary - Route: https://agentshelf.ai/knowledge/glossary - Language: en - Description: Plain-language definitions of agents, harnesses, context, tools, permissions, and operating concepts, with paths to deeper guides. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Use these working definitions to read and discuss agent designs. Terminology varies between systems; follow the linked product documentation when a term affects an implementation. ![Four connected vocabulary groups: System, Information, Actions, and Oversight](/content/knowledge/visuals/glossary.svg) Browse the groups: [System](#system) · [Information](#information) · [Actions](#actions) · [Oversight](#oversight). ## System ### AI agent **General concept.** A system that uses a model to help select and carry out steps toward a goal within configured limits. The interface may be conversational, but the interface alone does not determine whether a system is an agent. See [what is an AI agent?](/knowledge/ai-foundations/what-is-an-ai-agent). ### Agent harness **General concept and AgentShelf product concept.** The surrounding setup that gives a model instructions, context, capabilities, and operating rules for a job. Different systems include different responsibilities in this term. See [the harness explainer](/knowledge/ai-foundations/what-is-an-agent-harness) and [AgentShelf's harness overview](/platform/agent-harness). ### Agent runtime **General concept.** The execution environment that carries out the agent's work, such as coordinating requests, tool calls, and results. A runtime executes behavior; a job brief describes what that behavior should accomplish. See [agent architecture](/knowledge/ai-foundations/ai-agent-architecture). ### Dedicated workspace **AgentShelf product concept with a broader industry meaning.** AgentShelf describes a dedicated workspace as the place a user manages an agent's context, tools, conversations, results, and available activity. Do not infer access isolation or retention guarantees from the word alone. See [the product overview](/platform/agent-harness) and [workspace documentation](/docs/workspaces). ### External agent **AgentShelf documentation term.** An agent made available to an external application through the documented integration surface. Consult [the developer documentation](/docs) for supported configuration and lifecycle behavior. ### Session **General concept with implementation-specific behavior.** A session lets a system recognize continuity between interactions. Its lifetime, storage, and user identity rules depend on the implementation and may differ from a browser session. See [sessions and storage](/docs/sessions-and-storage). ## Information ### Approved context **Working editorial term.** Information selected and authorized for a particular job and audience, such as an approved service description. Approval needs an owner and a scope; it does not mean a source remains accurate forever. See [knowledge and tools](/knowledge/knowledge-tools). ### Knowledge grounding **General concept.** Connecting an answer or decision to relevant supplied or retrieved evidence. Grounding helps make a result inspectable, but the result still needs evaluation for relevance and faithfulness. See [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections). ### Agent memory **General concept.** Information retained or retrieved to support continuity across steps or interactions. Conversation context and persistent storage are different mechanisms; check what the implementation stores, for whom, and for how long. See [architecture](/knowledge/ai-foundations/ai-agent-architecture). ### Public reference **AgentShelf documentation term.** A reference used in the external-agent integration flow to identify a configured public agent surface. It does not authenticate a user or authorize an action. The backend uses a separate bootstrap credential to sign the assertion and keeps that credential server-side. See [getting started](/docs/getting-started) for the reference's exact use and [public references and secure bootstrap](/knowledge/ai-agent-integration/public-references-and-secure-bootstrap) for the boundary between them. ### Artifact **General concept with implementation-specific behavior.** A produced result, often a file or another separately accessible output. Its availability and access rules depend on the system. See [files and artifacts](/docs/files-and-artifacts). ## Actions ### Skill **Working editorial term aligned with AgentShelf copy.** Reusable instructions or methods for a class of work, such as a research procedure. A skill describes a method; a tool provides a capability. Product-specific packaging varies. See [the resource comparison](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections). ### Tool calling **General concept.** A model requests a defined capability, and the surrounding system decides whether and how to execute it. A requested action and a completed action are different states. See [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). ### Connection **Working editorial term aligned with AgentShelf copy.** A configured path to an external resource or system. It may involve an API, credentials, a connector, or MCP. The existence of a connection does not determine which actions a user may perform. See [AgentShelf's connections overview](/platform/knowledge-tools-automation). ### MCP tool **General integration concept.** A callable capability exposed through the Model Context Protocol. Review the server, the capability, the data exchanged, and the permissions separately; the protocol name is not a trust decision. See [knowledge and connections](/knowledge/knowledge-tools) and [permissions](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). ### Structured output **General concept.** A result organized into an expected format or set of fields. Correct structure makes inspection and downstream handling easier; it does not prove that the values are correct. See [defining a focused job](/knowledge/agent-design/define-a-focused-agent-job). ## Oversight ### Human-in-the-loop **General concept.** A workflow design in which a person reviews, approves, corrects, or takes over at defined points. Name the responsible person and the behavior while review is pending. See [approvals, handoffs, and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents). ### Agent handoff **General workflow concept.** A transfer of responsibility and relevant context to a person, another agent, or a system. Use *human handoff* when a person takes over and *cross-system handoff* when work passes between systems. Define who accepts it and how incomplete transfers are detected. See [human review and handoffs](/knowledge/agent-design/human-in-the-loop-ai-agents). ### Agent observability **General operating concept.** The ability to inspect evidence about execution, such as results, errors, tool activity, and usage. Decide what records are necessary without assuming every interaction should be retained. See [governance and cost controls](/knowledge/ai-governance/ai-agent-governance-and-cost-controls). ### Shadow AI **General organizational term.** AI use outside an organization's approved or visible processes. Review the underlying workflow need as well as access and accountability. See [governance](/knowledge/ai-governance) for a starting framework. ## Continue learning Return to [foundations](/knowledge/ai-foundations) for the broader mental model, or use [agent design](/knowledge/agent-design) to apply the terms to a specific job. ### Knowledge, Tools, and Connections - Route: https://agentshelf.ai/knowledge/knowledge-tools - Language: en - Description: Decide which sources, methods, capabilities, and business connections an AI agent needs for a defined job. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) A useful design separates what the agent should know from what it should be allowed to do. A policy document can inform an answer; a tool can request or perform an action. Giving access to one does not settle the rules for the other. ![Documents, instructions, actions, and systems connected to one job](/content/knowledge/visuals/knowledge-tools.svg) This path is for teams choosing the resources behind an agent workflow, including source owners and people responsible for connected systems. ## Start with the distinctions Knowledge supplies job-relevant information; skills guide a reusable method; tools expose defined actions; connections give tools a path to external systems. Treat access to information and authority to act as separate decisions. Read [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections) for a detailed chooser, then review [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) before enabling a capability. ## Prepare a resource inventory List the documents, reusable instructions, tool actions, and connected systems the job needs. For each one, record: - Its purpose: which part of the job it supports. - The person responsible for its accuracy or availability. - Access limits: who may see information and whether a capability may read, create a draft, or change an external record. - How you will detect an outdated source, a failed request, or an incomplete result. - How to remove access when the job or owner changes. For example, a service inquiry assistant may need approved service descriptions and a way to collect a visitor's question. That does not automatically require access to internal commercial notes or permission to alter customer records. Review each additional capability against the [focused job brief](/knowledge/agent-design/define-a-focused-agent-job). ## Test resources as well as answers Include conflicting documents, unavailable connections, and denied actions in the pilot. Define a useful response for each failure, such as asking for clarification, identifying missing information, or handing the task to a person. See [evaluation guidance](/knowledge/ai-governance/evaluate-an-ai-agent) for the pilot process, the [glossary](/knowledge/glossary) for terminology, and [AgentShelf's knowledge and tools overview](/platform/knowledge-tools-automation) for product details. ## All guides in this topic - [Knowledge, Skills, Tools, and Connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections): Knowledge provides information, skills guide work, tools perform actions, and connections give those tools a path to other systems. - [Connect an AI Agent to Business Systems](/knowledge/knowledge-tools/connecting-agents-to-business-systems): Choose an integration by separating its protocol, connection, identity, and permissions; a protocol alone does not grant access to a business system. - [How to Ground an AI Agent in Approved Business Context](/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context): Give an agent a bounded task, current sources with named owners, and a tested way to handle missing or conflicting evidence. ### Connect an AI Agent to Business Systems - Route: https://agentshelf.ai/knowledge/knowledge-tools/connecting-agents-to-business-systems - Language: en - Description: Choose an integration by separating its protocol, connection, identity, and permissions; a protocol alone does not grant access to a business system. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Connect an agent to a business system only after you have named the data and actions the job needs. An API defines how systems exchange requests; MCP standardizes how AI applications connect to servers that expose context and tools; permissions decide which user or agent may use an operation. These choices support one another, but they are not interchangeable. ![Documents, instructions, actions, and systems connected to one bounded job.](/content/knowledge/visuals/knowledge-tools.svg) *Sources, instructions, actions, and systems connect to one bounded job.* ## Separate the protocol, connection, and permission Each layer answers a different question: | Layer | What it answers | What it does not decide | | --- | --- | --- | | API | What request and response a business system accepts. | Whether this user or agent should be allowed to make that request. | | MCP | How an AI application connects to a server that offers resources, prompts, or tools. | Whether the server’s data or actions are authorized for a particular workflow. | | Agent policy | Which public capabilities, tools, and limits an external agent currently exposes. | Whether an arbitrary API or MCP server is available to the agent. | MCP can make a server’s interface easier to discover and use across compatible applications. The protocol does not enforce your organization’s business permissions by itself; each implementation must apply its own access and consent controls. In the current External Agents SDK documentation, integrations inspect the agent’s public policy and negotiated capabilities. The docs do not describe a general MCP connector, so do not assume that adding an MCP server makes it available through this SDK. A connection is the configured path from an agent workflow to a system. It includes an owner, an identity, the operation exposed, and the rules enforced by the system. A read-only lookup and an update endpoint may use the same API, but they have different consequences and should receive separate authorization. ## Work through one bounded request Consider a service desk that receives: “Check the inspection status for asset A-104.” The system of record contains one inspection entry, marked complete on September 25. The first job is to return that record; it does not need to edit the inspection or schedule maintenance. Check the identity and permission boundary at each step: 1. **Verify the requester.** Authenticate the person through the application's normal sign-in flow; do not rely on an identity supplied only in browser data. The service-desk owner decides which users may ask. 2. **Name the source and owner.** The maintenance system owns inspection status, and its owner confirms which approved operation can read it. 3. **Identify the connection identity.** Record which user or service identity will make the system call, then confirm its actual access with the system owner. 4. **Limit the system permission.** For this request, allow a read of inspection status for permitted assets. Keep updates or maintenance scheduling outside this connection unless separately approved. 5. **Check the agent capability.** For an external agent, inspect its current public policy and domain-tool details before presenting an action. Confirm the operation's side-effect class and whether approval is required; a protocol name alone does not establish access. 6. **Verify the result and stop condition.** Return the recorded status and date. Route a missing record or conflicting evidence to its owner instead of inferring a result. > **Completed lookup (illustrative)**\ > **Request:** Check inspection status for asset A-104.\ > **Requester:** A signed-in service-desk employee authorized by the service-desk owner to ask.\ > **Connection identity:** An approved read-only integration identity can read inspection status.\ > **Agent capability:** The current policy exposes the lookup; the interface shows no update action.\ > **Source result:** Inspection marked complete on September 25.\ > **Allowed action:** Read the status; no record change.\ > **Reply:** “The latest inspection is marked complete as of September 25.” This example assumes a read-only lookup is already authorized in the system. It does not imply that the SDK supplies this operation or that MCP grants access to the maintenance data. ## Test the boundary before expanding it Try a permitted request, a user who lacks access, a missing record, and a record with conflicting dates. Confirm that denied or uncertain cases reveal no unrelated data. For any operation that changes a record, identify who approves it and what evidence confirms the change completed. For the core distinction, read [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections). Review [agent permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries), then check the External Agents SDK’s [policy and capabilities guide](/docs/policy-and-capabilities) for the capabilities actually exposed by an agent. ### Ground an AI Agent in Business Context - Route: https://agentshelf.ai/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context - Language: en - Description: Give an agent a bounded task, current sources with named owners, and a tested way to handle missing or conflicting evidence. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Ground an AI agent by defining the answer it should produce, giving it a small set of current sources with clear owners, and testing how it handles gaps and disagreements. Retrieval can connect an answer to supplied information; it does not prove that the sources are complete or that the answer is correct. Fictional example: Cedarline Property Services asks, “Tell our maintenance lead whether after-hours visits are included for the Brookfield site. Use the approved service standard and location schedule, then prepare a short reply. Do not promise a visit time.” The requested result is a sourced draft, not a booking. ![Knowledge, a reusable method, tools, and connections support one task.](/content/knowledge/visuals/knowledge-skills-tools-and-connections.svg) *The diagram separates the kinds of resources that support a grounded answer.* ## Define what the agent must answer Turn the request into a question that can be checked: Does the current service standard include after-hours visits, and does the Brookfield schedule identify an exception? Tell the agent what counts as an answer, what it may do, and where it must stop. In this example, it can read approved service documents and draft a reply. It cannot invent availability, schedule a technician, or change the policy. This boundary matters because “use our knowledge” is too broad. A team may have many documents with different audiences, dates, and authority. Granting access to every file makes it harder to know which one supports an answer and whether the agent should use it. ## Choose sources people can maintain For Cedarline, the fictional approved source set is deliberately small: | Approved source | Owner | Authority and scope | Freshness evidence | Refresh trigger | | --- | --- | --- | --- | --- | | After-hours service standard | Operations lead | Sets service-wide rules: urgent visits are allowed; routine work is scheduled during business hours. | Effective July 1, 2026; confirm this is still the approved version. | A policy revision or the owner's review date becoming due. | | Brookfield location schedule | Regional coordinator | Lists site-specific exceptions; none are listed for Brookfield in this example. | Reviewed in September 2026; confirm there is no newer approved schedule. | A schedule or site change, or its next review date. | The standard governs the service itself; the location schedule can narrow availability at one site. Neither source authorizes a particular appointment. A public page or private file is not authoritative just because search returns it. Record each source's audience and version, decide which approved source takes precedence if documents disagree, and keep active material separate from archived copies and drafts. ## Make retrieved passages easy to check Organize information so a lookup can return a relevant passage with its source identity. Depending on the system, useful controls may include clear headings, small topic-focused documents, metadata for location or effective date, and filters that limit the search scope. These are design options, not features every agent platform provides. Ask the agent to preserve enough source detail for a person to check its claim: document name, section, date, or a direct passage when the interface supports it. Keep the source separate from the generated wording. If retrieval returns no useful passage, the answer should say what it could not confirm and ask for help or route the question to the source owner. ## Test real questions and failure cases Prepare representative questions before the workflow goes live. Include a direct question, a paraphrase, an ambiguous location, an outdated source, conflicting documents, and a question outside the approved scope. For each one, write the expected answer or safe response and the evidence that should support it. A successful lookup on one example does not establish reliable performance across the set. For Cedarline, the test set should include Brookfield and another site with different hours. One case should use an archived schedule; another should ask for an exact arrival time. On the stated sources, the completed draft is: > **Reply to the maintenance lead:** “The service standard allows after-hours visits for urgent incidents. It schedules routine work during business hours, and the Brookfield schedule lists no additional exception. No visit time has been confirmed.” The agent has compared the current standard with the site schedule and drafted a bounded answer. It has not booked or dispatched anyone. Review whether the cited passages support every sentence. ## Set a rule for change and disagreement Name the person who updates each source and the signal that triggers a refresh: a policy change, a new location, an expired review date, or repeated questions the sources cannot answer. Define what happens when the sources conflict. The agent should identify the conflict and route it to an owner; it should not resolve policy by guessing or blending two versions. Start with [knowledge, skills, tools, and connections](/knowledge/knowledge-tools/knowledge-skills-tools-and-connections), then review [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries). Use [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent) to test retrieval and answers as the source set changes. ### Knowledge, Skills, Tools, and Connections - Route: https://agentshelf.ai/knowledge/knowledge-tools/knowledge-skills-tools-and-connections - Language: en - Description: Knowledge provides information, skills guide work, tools perform actions, and connections give those tools a path to other systems. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Knowledge supplies facts, a skill describes a procedure, a tool performs a specific operation, and a connection provides an authorized route to a system. These parts work together but do different jobs. Northstar Supplies submits a vendor onboarding packet. Procurement asks for a review using the approved checklist and current vendor record, a flag for missing evidence, and a draft document request for review. In this fictional example, the checklist requires a current insurance certificate, but the packet does not include one. A person must review and send the request; the agent does not approve the vendor. ## Follow one request through the four parts - **Knowledge:** The approved onboarding checklist states that a current insurance certificate is required. Procurement owns the checklist and keeps it current. - **Skill:** The procedure compares the intake packet and current vendor record with the checklist, identifies missing evidence, drafts a request, and stops for human review. It does not grant access by itself. - **Tool:** A read-only vendor-record lookup retrieves the current record for comparison. It cannot approve the vendor or send a request. - **Connection:** An authorized, read-only connection gives that lookup access to the vendor-record system. The connection is limited to the access procurement has granted. Illustrative result for fictional Northstar Supplies records: > **Review draft: Northstar Supplies** > > - **Finding:** A current insurance certificate is missing from the intake packet. > - **Draft request:** “Please provide a current insurance certificate so procurement can continue its review.” > - **State:** No vendor approval made; a person must review and send the request. If the vendor record or packet cannot be read, or the sources conflict, the agent should identify what it could not verify and leave the decision to procurement. ![Knowledge, skills, tools, and connections surround and support one vendor-intake task, rather than forming sequential steps.](/content/knowledge/visuals/knowledge-skills-tools-and-connections.svg) *Policy, procedure, lookup, and authorized access.* ## Choose only what the task needs Keep the task small, then choose the resources needed to produce a useful result: | If the job needs... | Choose... | Check before use | | --- | --- | --- | | Approved facts or records | Knowledge | Name the source and owner; confirm its scope and freshness. | | A repeatable method and stop rules | A skill | State the steps and what to do when evidence is missing or conflicts. | | A specific operation, such as a lookup or update | A tool | Define its permitted action, side effects, and any approval needed. | | A route to another system | A connection | Confirm the calling identity and the access the system owner actually granted. | More documents do not automatically make knowledge more useful, and a prompt asking for care is not a substitute for a system permission. Test missing, stale, and unexpected data. Where practical, pass only the necessary information between steps and use structured fields; these practices reduce some risks but cannot guarantee correctness. For product-specific context, see AgentShelf’s [knowledge, tools, and automation overview](/platform/knowledge-tools-automation). Continue with [human review and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents), [agent permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries), and [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent). ### Website AI Agents and AI Front Desk - Route: https://agentshelf.ai/knowledge/website-agents - Language: en - Description: Assess website agent fit and plan approved answers, visitor handoffs, and useful pilot measures. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Start by deciding whether visitors need a conversation, a clear page, or a short form. If a website agent fits, plan when a person takes over and how you will judge the pilot. [What is a website AI agent?](/knowledge/website-agents/what-is-a-website-ai-agent) explains the concept. ![A visitor asks, gets an answer, clarifies, and reaches a next step or team handoff](/content/knowledge/visuals/website-agents.svg) This path is for website owners and teams responsible for service inquiries, lead intake, or visitor support. ## Decide whether the experience fits Start with [what is a website AI agent?](/knowledge/website-agents/what-is-a-website-ai-agent). Map the questions visitors ask before selecting features. Some needs are best served by a clear page or a short form; others benefit from a conversation that gathers context and directs the visitor to an appropriate next step. ## Design the conversation around a useful outcome For a service inquiry, a useful outcome might be an accurate answer and a brief summary a staff member can review. Agree on which details the summary needs. Ask only for information needed for the task, and explain what the next step involves. Map the exchange in order: answer from published information, clarify a missing detail, then offer a next step. When the answer is uncertain or needs a person, pass the question and relevant context to the team. Prepare answers to practical questions: What should happen when the published information is insufficient? Can the visitor reach a person? What happens outside staffed hours? How will the experience avoid implying that an unconfirmed request is already booked or accepted? Use [human review and escalation guidance](/knowledge/agent-design/human-in-the-loop-ai-agents) to make those paths explicit. ## Judge the pilot by visitor progress In the [evaluation guide](/knowledge/ai-governance/evaluate-an-ai-agent), choose cases that reflect visitor intent, ambiguous questions, missing information, and failed handoffs. Inspect answer usefulness and handoff completeness separately. A longer conversation does not by itself mean the visitor got more help. Explore [AI Front Desk](/solutions/ai-front-desk) for AgentShelf's website-facing product experience, or review [knowledge and tools](/knowledge/knowledge-tools) before preparing the underlying resources. ## All guides in this topic - [Website AI Agents](/knowledge/website-agents/what-is-a-website-ai-agent): A website AI agent uses approved information and bounded actions to answer visitors, guide next steps, and hand off exceptions. - [How to Design a Website AI Agent Knowledge Base](/knowledge/website-agents/design-a-website-agent-knowledge-base): Build website context from current public pages with clear owners, scoped visitor questions, and tests for missing or conflicting details. - [How to Measure Website AI Agent Quality](/knowledge/website-agents/measure-website-agent-quality): Measure whether website answers are useful and supported, and whether handoffs reach the right person with enough context. - [Human Handoff for Website AI Agents](/knowledge/website-agents/human-handoff-for-website-agents): Define when a website agent should pause, what context to pass, who accepts the request, and what the visitor sees while waiting. - [Website AI Agent vs. Chatbot vs. Live Chat](/knowledge/website-agents/website-agent-vs-chatbot-vs-live-chat): Choose a visitor conversation approach by how fixed the questions are, what approved information can answer, and when a person must be available. - [What Is an AI Front Desk Agent?](/knowledge/website-agents/ai-front-desk-agent): Plan answers, routing, appointment booking, and staff handoffs around a front desk role. ### What Is an AI Front Desk Agent? - Route: https://agentshelf.ai/knowledge/website-agents/ai-front-desk-agent - Language: en - Description: An AI front desk agent answers visitor questions, routes requests, books appointments, and hands off work that needs a person. Learn how to define the role. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) An AI front desk agent performs the reception role on a website: answer initial questions, identify the next step, help book an appointment, and hand off requests that need a person. Its value depends on completing that reception task with accurate information and clear boundaries. The broader [website AI agent definition](/knowledge/website-agents/what-is-a-website-ai-agent) explains the category. A front desk agent has a specific job: help a visitor reach the right service or person without taking over the entire customer relationship. ![A visitor reaches the front desk, which answers, routes, books an appointment, or hands off to a person.](/content/knowledge/visuals/ai-front-desk-agent.svg) *The right reception outcome can be an answer, a route, a booking, or a human handoff.* ## Define four responsibilities | Responsibility | Useful result | Boundary to define | | --- | --- | --- | | Answer | A response based on approved business information | What happens when information is missing or outdated | | Route | The visitor reaches the right service or contact path | Which requests need human assessment | | Book | An appointment is booked through the supported workflow | Which details and confirmation establish the booking | | Hand off | A person receives enough context to continue | Who receives the request and what the visitor should expect | Measure these outcomes separately. Someone asking about opening hours may need only an answer. An unusual request may need a handoff. Asking everyone to book creates unnecessary work and can hide failures to answer straightforward questions. ## Follow a fictional visitor Willow Repair, a fictional service business, wants help receiving website enquiries. A visitor asks: “Do you repair this type of equipment, and can I arrange a visit?” The agent checks approved service information. If the equipment is covered, it explains the next step and helps with booking through the configured workflow. Before launch, Willow should decide which appointment details the visitor must confirm and what a successful booking looks like in the actual system. A request for a visit and a confirmed booking are different states. If the booking fails or its result is unclear, the agent should explain that the appointment is not confirmed and offer the agreed contact route. It should not encourage repeated submissions without checking the earlier result. If the equipment is outside the approved service description, the useful outcome is a handoff. The agent summarizes the question and details already provided, using only information needed by the receiving person. It should not promise that the business will accept the job or invent a response time. ## Prepare information and escalation rules Start with current service descriptions, contact routes, opening hours, location information, and approved answers to common questions. Give each source an owner and refresh process. Define the booking workflow and confirmation state with the business owner; support for appointments does not establish a particular calendar integration. Write escalation rules for missing information, unsupported services, complaints, failed bookings, and visitors requesting a person. Decide what context to pass, where it goes, and what the visitor sees next. The [human handoff guide](/knowledge/website-agents/human-handoff-for-website-agents) expands that design. ## Test reception outcomes Use representative conversations: - A question answered by current approved information. - A question whose answer is absent or contradictory. - A visitor who knows the service they want and requests an appointment. - An incomplete appointment request and an unclear booking result. - An out-of-scope service request and an explicit request for a person. Check accuracy, routing, booking confirmation, and handoff usefulness separately. Review what happens when a source or connected step is unavailable. Count completed reception tasks when the relevant outcome is established, rather than counting every chat as a successful lead or booking. ## Choose the product path after defining the job [AgentShelf AI Front Desk Starter](/solutions/ai-front-desk) helps businesses handle website reception, including appointment booking. The [free offer](/solutions/ai-front-desk/free) has its own page. Assess the current offer and define your sources, appointment handling, escalation, and ownership before setting visitor expectations. Next, build an [approved website knowledge base](/knowledge/website-agents/design-a-website-agent-knowledge-base), then test the four responsibilities with the people who will operate them. ### How to Design a Website AI Agent Knowledge Base - Route: https://agentshelf.ai/knowledge/website-agents/design-a-website-agent-knowledge-base - Language: en - Description: Build website context from current public pages with clear owners, scoped visitor questions, and tests for missing or conflicting details. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) A website AI agent knowledge base should contain the current public information needed to answer a defined set of visitor questions. Give every source an owner and scope, keep internal material out unless the workflow explicitly needs it, and test what happens when the site cannot support an answer. Fictional example: Blue Quay Solar asks its website agent to answer whether it installs battery storage in Northport, what a visitor should prepare for an assessment, and how to request an appointment. The approved sources are the public service-area page, the battery installation page, and the assessment checklist. The agent can explain these details and link to the request form; it cannot promise an installation date or quote for a particular property. ![A website agent checks approved site information, clarifies a visitor’s question, and offers a next step.](/content/knowledge/visuals/what-is-a-website-ai-agent.svg) *The example shows why public source content and a clear visitor task belong together.* ## Start with visitor questions and decisions Review actual inquiry categories, support notes, and website search terms that your team is authorized to use. Use them to choose a small set of questions for the agent to answer, such as service coverage, preparation, public pricing, eligibility, or next steps. For each category, identify what the visitor needs to know and whether the answer is fully public. Avoid starting with a document dump and expecting the agent to discover which questions it should answer. For Blue Quay, the fictional service-area page lists Northport for home battery installation, the installation page confirms that the company offers the service, and the assessment checklist asks visitors to have their inverter model and typical evening electricity use ready. The request form accepts an inquiry; it does not confirm a date or price. A draft answer based on those sources could read: > “Blue Quay’s site lists home battery installation in Northport. For an assessment, have your inverter model and typical evening electricity use ready. You can use the request form to ask about next steps; the team will confirm property-specific details and availability.” An appointment request remains a request until the team checks capacity and confirms it. ## Build a small, maintainable source set Prefer clear, current pages that the organization already approves for public use. Assign an owner to each one and record its audience, location or service scope, effective date, review trigger, and next step. Make headings say what a section covers. Keep separate services or regions distinct when their rules differ. Remove obsolete duplicate pages from the agent’s search scope or label them so a retrieval system can tell them apart. Do not add private operating notes just because they could help answer more questions. Internal staffing schedules, account records, unpublished prices, and technician notes may have a different audience and access rule. If an answer needs one of those sources, define that job and access path separately; a public-site conversation should not silently inherit internal permissions. ## Set rules for gaps and conflicts Decide which source controls if a service page and a location page disagree. Define how the agent reports a missing or stale answer, when it asks one clarifying question, and when it offers a person’s help. It should not infer a service from a neighboring region or combine unrelated pages into an unsupported promise. Use separate test cases for missing and conflicting information: - **Missing:** If the location page says nothing about Northport, no approved page establishes coverage. The agent should say that the site does not confirm service there and offer the request form or a team check; it should neither promise service nor interpret silence as a denial. - **Conflicting:** If the service page lists Northport but the location page excludes it, the agent should identify both pages and pause the coverage answer. Unless an approved source rule resolves the conflict, send the two details to the source owner to reconcile them; do not choose one page or promise service while the conflict remains. ## Test the content before relying on it Create a question set from the scope. Include direct questions, paraphrases, misspellings, ambiguous places, unsupported services, a page with an expired review date, and a conflict between sources. For each question, note the expected answer, approved source, and safe fallback. Check both whether the right passage is retrieved and whether the answer stays within it. Retrieval quality and answer quality are related but separate checks. Ask a source owner to confirm the test answers. Repeat affected questions after page updates, changes to service scope, or a retrieval configuration change. Keep a route for visitors who need a commitment the public pages cannot make. See [how to ground an agent in approved context](/knowledge/knowledge-tools/how-to-ground-an-agent-in-business-context) for source ownership and conflict handling. Continue with [website agent design](/knowledge/website-agents/what-is-a-website-ai-agent) and [permissions and boundaries](/knowledge/ai-governance/ai-agent-permissions-and-boundaries) before connecting additional sources. ### Human Handoff for Website AI Agents - Route: https://agentshelf.ai/knowledge/website-agents/human-handoff-for-website-agents - Language: en - Description: Define when a website agent should pause, what context to pass, who accepts the request, and what the visitor sees while waiting. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) A website agent handoff works when the visitor knows a person will respond, the right team receives a useful summary, and someone accepts responsibility for the next step. Define the trigger, the minimum information to pass, and the fallback if no one is available before enabling the transfer. Fictional example: A visitor to Selby Home Repair asks whether the company can inspect a roof leak in Hollis, a town missing from the published service-area list. The site also says routine appointment requests receive a reply during business hours. The agent cannot confirm coverage or dispatch help. It may explain that the site does not list Hollis, ask whether the visitor wants a team member to check, and prepare a handoff draft with the visitor’s requested callback window. ![A reviewer can approve, revise, reject, or pause a prepared request at a clear human checkpoint.](/content/knowledge/visuals/human-in-the-loop-ai-agents.svg) *A handoff is a decision point with an owner, not just a transfer icon.* ## Choose the moments that require a person Route a visitor to a person when the answer is outside published information, sources conflict, the request needs a commitment, or the visitor asks for human help. Define any additional triggers for complaints, accessibility needs, safety concerns, or account-specific questions. The agent should not treat a lack of information as permission to guess. For Selby, the trigger is an unlisted location. A missing callback number is not permission to collect unrelated details; first ask what the visitor wants to share and explain why the team needs it. Do not call a routine service request an emergency route unless the company has defined and staffed that response. ## Prepare a short summary for the receiving team Give the receiving person enough context to continue without asking the visitor to repeat everything. A useful packet may include: - The visitor’s original question and their stated goal. - The relevant published page and the detail the agent could not confirm. - Any answer already given, clearly separated from unresolved facts. - Contact details the visitor chose to provide and the agreed way to follow up. - The time of the request, current status, and the team expected to respond. Keep personal information to what the next step needs. Let the visitor inspect or correct the summary when practical. Make clear whether a request has only been prepared, has reached a queue, or has been accepted by a person. For Selby, the handoff draft could say: “Please check whether roof-leak inspections are available in Hollis and call after 3 p.m. if coverage is confirmed. The visitor asked about a roof leak; the published service-area page does not list Hollis. No appointment has been offered.” The agent has not made a booking or promised service. ## Assign ownership and acknowledgement Name the team that watches each queue, the hours it is monitored, a response expectation, and a backup owner. Decide what the visitor sees after submitting a request. If no immediate response is available, state when and how the team expects to reply, or offer another contact path. Do not show “connected” or “accepted” until a person or system has actually confirmed ownership. For Selby, show distinct messages for confirmed and unconfirmed handoffs: > **Acknowledged:** “The Selby team has received your request to check service in Hollis. The site says routine appointment requests receive a reply during business hours. No inspection has been booked.” > **Unconfirmed:** “I can’t confirm that the team received your request, so it has not been accepted yet. Please use the contact method published on the site.” Keep unconfirmed requests pending and do not promise a response time beyond the published guidance. Test routine hours, after-hours requests, unavailable queues, duplicate submissions, and a visitor who changes or withdraws the request. Check whether the right person receives the packet, whether the visitor sees an accurate status, and whether the case can be followed through to a response. A transfer event alone does not show that the handoff was completed. Use [human review and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents) to choose the decision point. For the website conversation itself, see [website AI agents](/knowledge/website-agents/what-is-a-website-ai-agent) and [evaluate the visitor workflow](/knowledge/ai-governance/evaluate-an-ai-agent). ### How to Measure Website AI Agent Quality - Route: https://agentshelf.ai/knowledge/website-agents/measure-website-agent-quality - Language: en - Description: Measure whether website answers are useful and supported, and whether handoffs reach the right person with enough context. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Measure a website agent on whether its answers help visitors and stay within approved sources, then assess whether handoffs reach the right team with enough context. Keep these outcomes separate from conversation volume or length; more interaction does not by itself mean better service. Fictional example: An agent for Harborview Workshop helps visitors ask about a training room. Its public pages state a seated capacity of 36, describe a step-free entrance, and explain how to request a date. The agent can answer those facts and prepare an inquiry, but cannot check the live room calendar or reserve the space. ![A repeatable evaluation checks routine questions, missing evidence, conflicting sources, and tool failures.](/content/knowledge/visuals/evaluate-an-ai-agent.svg) *Use separate cases to inspect answer quality, boundaries, and recovery.* ## Choose measures that show whether visitors got help Start with the result the visitor needs. For Harborview, choose measures such as: - **Supported answer rate:** What share of sampled factual replies has every material claim supported by the current approved pages? - **Answer usefulness:** Does the response answer the question, use the right location or service detail, and state important limits? - **Correct next step:** When availability is unknown, does the agent offer the request path without implying a reservation? - **Handoff completeness:** Does the team receive the visitor’s question, relevant source, missing decision, and chosen contact details? - **Handoff acceptance:** What share of submitted handoffs receives an acknowledgement of ownership within the agreed response window? - **Follow-up completion:** What share of accepted handoffs receives the promised follow-up by its deadline? Define each measure with a numerator, denominator, and review method. Supported answer rate is the number of sampled factual answers with every material claim supported, divided by all sampled factual answers. A reviewer decides which claims matter and what counts as support; an answer with one unsupported material claim does not pass. For handoffs, define a submission cohort and response windows before measuring. For example, allow one business day to acknowledge ownership and two business days after acceptance to complete follow-up. Calculate the rates only once every case in the cohort has had its full applicable window; show younger cases as pending. An illustrative weekly sample—not a product benchmark—could contain 20 factual answers, with 18 fully supported: **18 / 20 = 90%**. Of 10 submitted handoffs, 8 are accepted within one business day: **8 / 10 = 80%**. If 6 of those 8 receive follow-up within two business days of acceptance, completion is **6 / 8 = 75%**. The other two accepted cases remain overdue or unresolved; acknowledgement alone does not count as follow-up. ## Score a concrete example Suppose a visitor asks, “Can 36 people sit in the room, is the entrance step-free, and can I book October 16?” The agent checks the capacity, accessibility, and request pages. A suitable reply is: > “The room page lists seating for 36, and the accessibility page describes a step-free entrance. I can prepare a request for October 16, but the room is not reserved until the team checks the calendar and confirms it.” The answer is useful if the cited pages support the capacity and entrance details and the visitor can reach the request form. Check packet completeness when the team receives the date, relevant question, and chosen contact details. Record acceptance when the team acknowledges ownership, and follow-up completion when it responds to the visitor. None of those events proves a booking took place. The following single-case scores are illustrative, not a product benchmark. If the visitor asks the team to check the date, score the answer and handoff separately: | Outcome | Check for this visitor | Illustrative score | | --- | --- | --- | | Usefulness | The reply addresses capacity and step-free access, offers a way to request October 16, and says no booking is confirmed. | 3 / 3 checks | | Approved support | The capacity and entrance claims match their current approved pages; availability remains unconfirmed. | 2 / 2 claims supported | | Handoff quality | The draft records the October 16 question, pages checked, unresolved calendar decision, and room team as owner. The visitor has not chosen a follow-up route. | 4 / 5 fields; keep the draft pending | ## Test common and difficult cases Build a small evaluation set from visitor needs: a direct question, a paraphrase, an ambiguous request, an answer absent from the site, conflicting page details, a request to guarantee a date, and a case that needs a person. Record the expected answer, source, next step, and failure behavior for each. Test response quality and routing separately so a strong answer cannot hide a broken handoff. During a pilot, sample real interactions only under the organization’s privacy and retention rules. Limit what is collected, restrict who can inspect it, and redact details that reviewers do not need. Ask people who own the visitor task to review a consistent sample; automated scores can help organize review but do not decide whether the service outcome is acceptable. ## Choose a decision rule before expanding Set release thresholds with the people responsible for the service, review capacity, and consequences of a wrong answer. Define which errors stop the pilot, which require a corrective change, and who approves expansion. If a source, prompt, or handoff route changes, retest the cases affected by that change. Report the sample and its limits alongside the result rather than presenting one score as proof of overall quality. Start with [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent), define the [human handoff](/knowledge/website-agents/human-handoff-for-website-agents), and review the [website agent pattern](/knowledge/website-agents/what-is-a-website-ai-agent) before widening the visitor experience. ### Website AI Agent vs. Chatbot vs. Live Chat - Route: https://agentshelf.ai/knowledge/website-agents/website-agent-vs-chatbot-vs-live-chat - Language: en - Description: Choose a visitor conversation approach by how fixed the questions are, what approved information can answer, and when a person must be available. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Choose a website conversation approach by the visitor’s need, the information available, and who must make the next decision. A scripted chatbot fits predictable paths; an AI agent can work across approved information for less predictable questions; live chat puts a person in the conversation. These options can also work together. Fictional example: A visitor to Juniper Hall asks, “Can you host 80 seated guests, is the entrance step-free, and can I reserve the room for next Friday?” The venue’s published event page lists a seated capacity of 80, the accessibility page describes the entrance, and a request form collects event dates. The agent may answer those published details and prepare an availability inquiry, but it cannot see the live calendar or confirm a booking. ![A visitor gets an answer, clarifies a detail, and reaches a next step or a team handoff.](/content/knowledge/visuals/website-agents.svg) *The visitor’s path can end in self-service or a clearly owned handoff.* ## Compare the work each option handles | Approach | A good fit when | Decide before launch | | --- | --- | --- | | Scripted chatbot | Visitors can choose from a small set of known topics or steps. | Which paths are supported, and how does a visitor leave a dead end? | | Website AI agent | Questions vary, approved pages can support answers, and the task has a safe stopping point. | What sources may it use, what can it do, and which cases require a person? | | Live chat | A person needs to interpret nuance, make a judgment, or take responsibility for a request. | When is staff available, who owns unanswered requests, and what context reaches them? | Present live chat as available only during times when a named person or team is assigned to monitor requests and can accept them. When nobody is on duty, switch to a contact or callback request, show the expected response window, and do not imply that a person is connected. If a request enters a queue, describe it as pending until the receiving team confirms ownership. A search page, FAQ, or short form may be simpler than any of these when the next step is already known. A scripted flow can be easier to inspect for a fixed process. An agent can adapt a response to the visitor’s wording, but its flexibility makes source quality, boundaries, and testing important. Live chat lets a person handle the conversation directly, but it is available only when staff can respond. ## Apply the comparison to one visitor request For Juniper Hall, a scripted chatbot could direct visitors to the capacity, accessibility, and booking pages. That may be enough if most questions follow the same route. A website agent could combine the relevant published details in one answer and prepare the availability request. A staff member could confirm the date after checking the calendar and clarify any event requirements. The visitor-facing answer should stay within the evidence: “The event page lists capacity for 80 seated guests, and the accessibility page describes a step-free entrance. I can prepare an availability request for next Friday. The venue team must check the calendar and confirm the date.” The agent has not sent a request or reserved the room. The separate request draft for a staff member is: “Please check whether Juniper Hall is available for 80 seated guests next Friday. The visitor also asked about step-free access; the published accessibility page describes a step-free entrance.” The staff member checks the live calendar, sends the inquiry, and confirms any booking directly. If the visitor asks the agent to guarantee the date, it should explain that it cannot confirm availability and offer the staff handoff. ## Decide what happens between self-service and a person The choice does not have to be exclusive. A chatbot or agent can answer routine questions and offer a live handoff when it reaches a boundary. Make the transition visible: tell the visitor what information will be passed along, capture only what the team needs, and name the group responsible for replying. Set a path for out-of-hours requests so the experience does not imply immediate human coverage. Before choosing an agent, list the top visitor questions and the approved page that supports each answer. Include a missing-source case, a conflicting answer, a request to make a commitment, and a case where a person is needed. Measure answer usefulness and handoff completion separately; a long conversation does not show whether the visitor reached a useful outcome. For the agent pattern and its boundaries, read [website AI agents](/knowledge/website-agents/what-is-a-website-ai-agent). Use [human review and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents) to define the handoff, then [evaluate the workflow](/knowledge/ai-governance/evaluate-an-ai-agent) before expanding it. ### What Is a Website AI Agent? - Route: https://agentshelf.ai/knowledge/website-agents/what-is-a-website-ai-agent - Language: en - Description: A website AI agent uses approved site information and bounded actions to answer visitor questions, guide next steps, and hand off requests it cannot resolve. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) A website AI agent helps visitors complete a specific task: answer a question, find a next step, or prepare a handoff to a person. It uses approved information and stays within defined limits on what it can do. **Example visitor question:** “Do you service HVAC in Oakfield? What should I prepare, and how do I book a consultation?” In this fictional example, the approved service-area page lists Oakfield for HVAC service, the preparation checklist asks visitors to have the equipment model and a short problem description ready, and the booking page offers a consultation. The agent checks those pages and answers only from the details they provide. Illustrative reply; the site content and visitor are fictional: > “The service-area page lists Oakfield for HVAC service. Before the consultation, please have your equipment model and a short description of the problem ready. You can use the consultation page to request one.” **Grounding and handoff:** The exact answer should come from the site’s current pages. If the visitor’s area is not listed, the pages disagree, or the visitor asks for an account-specific commitment, the agent should explain what it cannot confirm and offer a person’s help. **Worked handoff:** The consultation page has a request form but no available times. If asked to guarantee an appointment tomorrow, the agent could reply: > “The site does not show tomorrow’s availability. Would you like me to ask the team to check? I haven’t booked a consultation.” With the visitor’s agreement, it prepares a draft with the requested date, page checked, and unanswered availability question. The request stays pending until the receiving team acknowledges it. ![Illustrative website conversation showing a grounded Oakfield answer, a clarification question, and handoff to a person](/content/knowledge/visuals/what-is-a-website-ai-agent.svg) *Illustrative conversation, not an actual site interface.* ## Give the agent a clear job **Job and access:** For this request, the job is to answer service-area and preparation questions, then guide the visitor to the consultation page. The approved pages are its source of truth. A page lookup and a link to the booking route may be enough; account access or the ability to make commitments would add risk without helping this task. **Scope and human review:** Decide which questions are in scope, what information the agent may request, and who handles exceptions. Keep visitor-provided text and page content as information to assess, not permission to ignore the workflow’s limits. For consequential actions, set an explicit human checkpoint and define what context the person receives. ## Know when a website agent fits - **Good fit:** This pattern can help when visitors ask recurring questions, answers live in maintained sources, and there is a clear next step. - **Simpler option:** A searchable FAQ or form may be simpler when questions and paths are predictable. - **Poor fit without an approved route:** An emergency, account-specific decision, or request to promise a booking needs a verified responsible person or system. Do not leave the visitor waiting on an unstaffed handoff. - **Before a pilot:** Check that the approved pages stay current, measure whether answers are supported, and review whether handoffs give staff enough context. For product-specific scope, see AgentShelf’s [AI Front Desk page](/solutions/ai-front-desk) and [website AI agents overview](/marketing/website-ai-agents). For handoffs and testing, continue with [human review and escalation](/knowledge/agent-design/human-in-the-loop-ai-agents) and [agent evaluation](/knowledge/ai-governance/evaluate-an-ai-agent). ### Centro de conocimiento de AgentShelf - Route: https://agentshelf.ai/es/conocimiento - Language: es - Description: Aprende a elegir, diseñar, evaluar y operar agentes de IA enfocados con guías prácticas para equipos de negocio y quienes los desarrollan. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Empieza por la pregunta que necesitas resolver hoy. Estas guías explican cómo funcionan los agentes, cómo elegir una tarea con límites claros y cómo diseñar y evaluar una prueba piloto. También cubren cómo poner el agente en funcionamiento e integrarlo con tus sistemas. ## Empieza con un paso práctico Elige una tarea recurrente. Anota quién es responsable, qué fuentes están permitidas, cómo sería un resultado útil y qué decisiones requieren una persona. Esas elecciones dan un propósito claro al primer piloto. ## Resuelve una pregunta operativa - **Infraestructura:** comprende [las capas de un sistema con LLM](/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm) y compara [opciones de despliegue](/es/conocimiento/fundamentos-de-ia/opciones-de-despliegue-de-llm). - **Integración:** distingue [pasarela y plataforma de agentes](/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes) y planifica [alternativas ante un proveedor no disponible](/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm). - **Gobernanza:** prepara [presupuestos para LLM](/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm) y [reglas para compartir agentes entre equipos](/es/conocimiento/gobernanza-de-ia/compartir-agentes-entre-equipos). - **Aplicaciones:** conoce [las bibliotecas de agentes](/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes) y [la función de recepción con IA](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-recepcion-con-ia). ### Agentes de IA para sitios web y AI Front Desk - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web - Language: es - Description: Evalúa si un agente de sitio web es adecuado y planifica respuestas aprobadas, transferencias a personas y medidas útiles para el piloto. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Empieza por decidir si los visitantes necesitan una conversación, una página clara o un formulario breve. Si un agente es adecuado, define cuándo interviene una persona y cómo evaluarás la prueba piloto. [¿Qué es un agente de IA para sitios web?](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) explica el concepto. ![Un visitante pregunta, recibe una respuesta, aclara una duda y llega al siguiente paso o a una transferencia al equipo.](/content/knowledge/visuals/es-website-agents.svg) Esta ruta está dirigida a responsables de sitios web y equipos de consultas de servicio, recepción de solicitudes o atención a visitantes. ## Decide si la experiencia es adecuada Empieza por [¿qué es un agente de IA para sitios web?](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web). Identifica las preguntas de los visitantes antes de elegir funcionalidades. Algunas necesidades se resuelven mejor con una página clara o un formulario breve; otras se benefician de una conversación que reúna contexto y dirija al visitante al siguiente paso adecuado. ## Diseña la conversación para lograr un resultado útil En una consulta de servicio, un resultado útil podría ser una respuesta precisa y un resumen breve que pueda revisar una persona del equipo. Acuerden qué datos debe incluir el resumen. Pide solo la información necesaria para la tarea y explica en qué consiste el siguiente paso. Organiza la conversación en orden: responde a partir de la información publicada, aclara los datos que falten y después ofrece un siguiente paso. Cuando la respuesta sea incierta o se necesite a una persona, transfiere la pregunta y el contexto pertinente al equipo. Prepara respuestas para preguntas prácticas: ¿qué debería ocurrir si la información publicada no basta? ¿Puede el visitante comunicarse con una persona? ¿Qué ocurre fuera del horario de atención? ¿Cómo evitará la experiencia dar a entender que una solicitud sin confirmar ya está reservada o aceptada? Usa la [guía de revisión humana y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) para dejar claros esos pasos. ## Evalúa el piloto según el avance del visitante En la [guía de evaluación](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia), elige casos que reflejen la intención del visitante, las preguntas ambiguas, la falta de información y las transferencias fallidas. Evalúa por separado la utilidad de las respuestas y la integridad de las transferencias. Una conversación más larga no significa por sí sola que el visitante haya recibido más ayuda. Explora [AI Front Desk](/es/solutions/ai-front-desk), la experiencia de producto de AgentShelf para sitios web, o revisa [conocimiento y herramientas](/es/conocimiento/conocimiento-y-herramientas) antes de preparar los recursos necesarios. ## Todas las guías de este tema - [Agentes de IA para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web): Un agente de IA para sitios web usa información aprobada y acciones acotadas para responder a visitantes, orientar los siguientes pasos y transferir las excepciones a una persona. - [Agente de IA para sitios web, chatbot o chat en vivo](/es/conocimiento/agentes-para-sitios-web/agente-de-ia-vs-chatbot-vs-chat-en-vivo): Elige cómo conversar con los visitantes según lo predecibles que sean sus preguntas, qué información aprobada puede responderlas y cuándo debe haber una persona disponible. - [Cómo diseñar una base de conocimiento para un agente de IA de sitios web](/es/conocimiento/agentes-para-sitios-web/disenar-la-base-de-conocimiento): Prepara el contexto del sitio con páginas públicas vigentes, responsables claros, preguntas delimitadas y pruebas de datos faltantes o contradictorios. - [Cómo medir la calidad de un agente de IA para sitios web](/es/conocimiento/agentes-para-sitios-web/medir-la-calidad-del-agente): Mide si las respuestas del sitio son útiles y se apoyan en fuentes aprobadas, y si las transferencias llegan a la persona adecuada con contexto suficiente. - [Transferencia de agentes de sitios web a una persona](/es/conocimiento/agentes-para-sitios-web/transferencia-a-una-persona): Define cuándo debe pausarse el agente, qué contexto compartir, quién acepta la consulta y qué ve el visitante mientras espera. - [¿Qué es un agente de recepción con IA?](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-recepcion-con-ia): Planifica respuestas, derivación, reserva de citas y transferencia al equipo para la función de recepción. ### Agente de IA para sitios web, chatbot o chat en vivo - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/agente-de-ia-vs-chatbot-vs-chat-en-vivo - Language: es - Description: Elige cómo conversar con los visitantes según lo predecibles que sean sus preguntas, qué información aprobada puede responderlas y cuándo debe haber una persona disponible. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Elige cómo atender las consultas en tu sitio web según las necesidades de los visitantes, la información disponible y quién debe tomar la siguiente decisión. Un chatbot con rutas predefinidas sirve para recorridos predecibles; un agente de IA puede consultar información aprobada para responder preguntas menos previsibles; en el chat en vivo, una persona participa en la conversación. También puedes combinar estas opciones. Ejemplo ficticio: Una persona que visita el sitio de Juniper Hall pregunta: «¿Pueden recibir a 80 personas sentadas? ¿La entrada no tiene escalones? ¿Puedo reservar el salón para el próximo viernes?». La página del recinto indica que tiene capacidad para 80 personas sentadas, la página de accesibilidad describe la entrada y un formulario recibe solicitudes con fechas. El agente puede responder con esos datos públicos y preparar una consulta sobre disponibilidad, pero no puede ver el calendario en tiempo real ni confirmar una reserva. ![Un visitante recibe una respuesta, aclara un detalle y llega al siguiente paso o a una transferencia al equipo.](/content/knowledge/visuals/es-website-agents.svg) *El recorrido del visitante puede terminar en autoservicio o en una transferencia con responsable.* ## Compara qué trabajo puede realizar cada opción | Enfoque | Es adecuado cuando | Qué decidir antes del lanzamiento | | --- | --- | --- | | Chatbot con rutas predefinidas | Los visitantes pueden elegir entre pocos temas o pasos conocidos. | ¿Qué recorridos admite y cómo sale el visitante de un callejón sin salida? | | Agente de IA para sitios web | Las preguntas varían, las páginas aprobadas respaldan las respuestas y la tarea tiene un punto seguro para detenerse. | ¿Qué fuentes puede usar, qué acciones puede realizar y qué casos requieren una persona? | | Chat en vivo | Una persona debe interpretar matices, tomar una decisión o hacerse responsable de la solicitud. | ¿Cuándo hay personal disponible, quién responde las consultas pendientes y qué contexto recibe? | Ofrece el chat en vivo solo durante los horarios en que una persona o un equipo identificado esté asignado a supervisar las consultas y pueda aceptarlas. Cuando no haya nadie de turno, cambia la opción por una solicitud de contacto o devolución de llamada, indica el plazo esperado de respuesta y no des a entender que hay una persona conectada. Si una solicitud entra en una cola, preséntala como pendiente hasta que el equipo receptor confirme que se hará cargo. Una página de búsqueda, una sección de preguntas frecuentes o un formulario breve pueden ser más sencillos cuando el siguiente paso ya está claro. Un flujo predefinido puede ser más fácil de revisar si el proceso no cambia. Un agente adapta la respuesta a las palabras del visitante, pero esa flexibilidad vuelve importante la calidad de las fuentes, los límites y las pruebas. El chat en vivo permite que una persona atienda la conversación directamente, pero solo está disponible cuando hay personal que pueda responder. ## Compara las opciones con una misma solicitud En el caso de Juniper Hall, un chatbot podría dirigir a los visitantes a las páginas de capacidad, accesibilidad y reservas. Eso puede bastar si casi todas las preguntas siguen el mismo recorrido. Un agente podría reunir los datos publicados en una sola respuesta y preparar la consulta de disponibilidad. Una persona del equipo podría confirmar la fecha después de revisar el calendario y aclarar los requisitos del evento. La respuesta al visitante debe ceñirse a la evidencia: «La página del recinto indica capacidad para 80 personas sentadas y la página de accesibilidad describe una entrada sin escalones. Puedo preparar una consulta de disponibilidad para el próximo viernes. El equipo del recinto debe revisar el calendario y confirmar la fecha». El agente no envió la consulta ni reservó el salón. El borrador separado para una persona del equipo sería: «Comprueba si Juniper Hall está disponible para 80 personas sentadas el próximo viernes. La persona también preguntó por el acceso sin escalones; la página pública de accesibilidad describe una entrada sin escalones». La persona revisa el calendario en tiempo real, envía la consulta y confirma directamente cualquier reserva. Si el visitante pide al agente que garantice la fecha, debería explicarle que no puede confirmar la disponibilidad y ofrecer la transferencia al equipo. ## Define el paso entre el autoservicio y una persona No tienes que elegir una sola opción. Un chatbot o un agente puede resolver las preguntas habituales y ofrecer una transferencia cuando llegue a un límite. Haz visible el cambio: informa al visitante qué datos se compartirán, recoge solo lo que el equipo necesita e identifica quién responderá. Define una vía para las consultas que lleguen fuera del horario de atención y evita dar a entender que una persona responderá de inmediato. Antes de elegir un agente, enumera las preguntas frecuentes y la página aprobada que respalda cada respuesta. Incluye casos de fuentes faltantes o contradictorias, solicitudes que exijan un compromiso y situaciones en las que se necesite a una persona. Mide por separado la utilidad de las respuestas y la calidad de las transferencias; una conversación larga no demuestra que el visitante haya obtenido un resultado útil. Para conocer el patrón de agente y sus límites, lee sobre [agentes de IA para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web). Usa la guía de [revisión humana y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) para definir las transferencias y [evalúa el flujo de trabajo](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) antes de ampliarlo. ### Cómo diseñar una base de conocimiento para un agente de IA de sitios web - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/disenar-la-base-de-conocimiento - Language: es - Description: Prepara el contexto del sitio con páginas públicas vigentes, responsables claros, preguntas delimitadas y pruebas de datos faltantes o contradictorios. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) La base de conocimiento de un agente de IA para sitios web debería contener la información pública vigente que necesita para responder a un conjunto definido de preguntas. Asigna a cada fuente una persona responsable y un alcance, excluye el material interno salvo que el flujo lo necesite de forma explícita y prueba qué ocurre cuando el sitio no respalda una respuesta. Ejemplo ficticio: Blue Quay Solar pide a su agente de sitio que responda si instala baterías en Northport, qué conviene preparar para una evaluación y cómo solicitar una cita. Las fuentes aprobadas son la página pública de zonas de servicio, la página de instalación de baterías y la lista de preparación para la evaluación. El agente puede explicar esos detalles y enlazar al formulario; no puede prometer una fecha de instalación ni cotizar un inmueble concreto. ![Un agente de sitio consulta información aprobada, aclara la pregunta de un visitante y ofrece el siguiente paso.](/content/knowledge/visuals/es-what-is-a-website-ai-agent.svg) *El ejemplo muestra por qué deben coincidir la información pública y la tarea del visitante.* ## Empieza con las preguntas y decisiones de los visitantes Revisa las categorías de consultas, las notas de soporte y los términos de búsqueda del sitio que tu equipo tenga autorización para usar. Úsalas para elegir un grupo pequeño de preguntas que responderá el agente, como zonas de servicio, preparación, precios públicos, requisitos o próximos pasos. Para cada categoría, identifica qué necesita saber el visitante y si la respuesta es totalmente pública. No empieces cargando indiscriminadamente todos los documentos para que el agente descubra qué preguntas debería responder. En Blue Quay, la página ficticia de zonas de servicio incluye Northport para instalaciones de baterías domésticas, la página de instalación confirma que la empresa ofrece ese servicio y la lista de preparación pide tener a mano el modelo del inversor y el consumo eléctrico habitual por la tarde. El formulario recibe consultas; no confirma fechas ni precios. Un borrador basado en esas fuentes podría decir: > «El sitio de Blue Quay incluye las instalaciones de baterías domésticas en Northport. Para la evaluación, ten a mano el modelo de tu inversor y el consumo eléctrico habitual por la tarde. Puedes usar el formulario para consultar los siguientes pasos; el equipo confirmará los detalles de tu propiedad y la disponibilidad». Una solicitud de cita sigue siendo una solicitud hasta que el equipo revise la capacidad y la confirme. ## Crea un conjunto de fuentes pequeño y fácil de mantener Da preferencia a páginas claras y vigentes que la organización ya haya aprobado para uso público. Asigna una persona responsable a cada una y registra su público, alcance geográfico o de servicio, fecha de vigencia, motivo de revisión y siguiente paso. Usa encabezados que describan el contenido de cada sección. Mantén separados los servicios o las regiones cuando sus reglas sean diferentes. Excluye de las búsquedas del agente las copias obsoletas o identifícalas para que el sistema pueda distinguirlas. No agregues notas de operación privada solo porque podrían ayudar a responder más preguntas. Los horarios internos del personal, los registros de cuentas, los precios no publicados y las notas de técnicos pueden estar sujetos a otros públicos y permisos. Si una respuesta requiere una de esas fuentes, define la tarea y la vía de acceso por separado; una conversación pública del sitio no debería heredar en silencio permisos internos. ## Define qué hacer ante lagunas y conflictos Decide qué fuente prevalece si no coinciden la página del servicio y la de una región. Define cómo informa el agente que la respuesta falta o está desactualizada, cuándo puede formular una pregunta aclaratoria y cuándo debe ofrecer ayuda de una persona. No debería deducir que se presta un servicio en una región vecina ni combinar páginas no relacionadas para hacer una promesa sin respaldo. Usa casos de prueba distintos para la información faltante y la contradictoria: - **Faltante:** Si la página de zonas de servicio no dice nada sobre Northport, ninguna página aprobada confirma la cobertura. El agente debe decir que el sitio no confirma el servicio en esa zona y ofrecer el formulario o una consulta al equipo; no debe prometer el servicio ni interpretar el silencio como una negativa. - **Contradictoria:** Si la página de servicios incluye Northport, pero la página de zonas lo excluye, el agente debe identificar ambas páginas y pausar la respuesta sobre cobertura. Salvo que una regla aprobada de fuentes resuelva la contradicción, debe pedir a la persona responsable de la fuente que la aclare; no debe elegir una página ni prometer el servicio mientras siga sin resolverse. ## Prueba el contenido antes de depender de él Prepara un conjunto de preguntas que se ajuste al alcance. Incluye preguntas directas, paráfrasis, errores ortográficos, lugares ambiguos, servicios no incluidos, una página con fecha de revisión vencida y fuentes contradictorias. Para cada pregunta, anota la respuesta esperada, la fuente aprobada y la alternativa segura. Comprueba tanto si se recupera el pasaje correcto como si la respuesta se mantiene dentro de sus límites. La calidad de la recuperación y la calidad de la respuesta están relacionadas, pero se evalúan por separado. Pide a una persona responsable de las fuentes que confirme las respuestas previstas. Repite las preguntas afectadas cuando se actualicen las páginas, cambie el alcance del servicio o se modifique la configuración de recuperación. Conserva una vía para los visitantes que necesiten un compromiso que las páginas públicas no puedan confirmar. Consulta [cómo fundamentar un agente en el contexto aprobado](/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial) para definir la propiedad de las fuentes y gestionar conflictos. Continúa con el [diseño de agentes para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) y los [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) antes de conectar otras fuentes. ### Cómo medir la calidad de un agente de IA para sitios web - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/medir-la-calidad-del-agente - Language: es - Description: Mide si las respuestas del sitio son útiles y se apoyan en fuentes aprobadas, y si las transferencias llegan a la persona adecuada con contexto suficiente. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Mide si las respuestas del agente ayudan a los visitantes y se ciñen a fuentes aprobadas. Después, evalúa por separado si las transferencias llegan al equipo adecuado con contexto suficiente. No confundas estos resultados con el volumen o la duración de las conversaciones: interactuar más tiempo no significa necesariamente recibir mejor atención. Ejemplo ficticio: Un agente para Harborview Workshop responde preguntas sobre una sala de capacitación. Sus páginas públicas indican que tiene capacidad para 36 personas sentadas, describen una entrada sin escalones y explican cómo solicitar una fecha. El agente puede responder con esos datos y preparar una consulta, pero no puede revisar el calendario en tiempo real ni reservar la sala. ![Una evaluación repetible comprueba preguntas habituales, evidencia faltante, fuentes contradictorias y fallos de herramientas.](/content/knowledge/visuals/es-evaluate-an-ai-agent.svg) *Usa casos separados para revisar la calidad de las respuestas, los límites y la recuperación.* ## Elige medidas para comprobar si el visitante recibió ayuda Empieza por el resultado que necesita el visitante. Para Harborview, podrías medir: - **Proporción de respuestas respaldadas:** ¿Qué proporción de las respuestas factuales de la muestra tiene todas sus afirmaciones importantes respaldadas por las páginas aprobadas vigentes? - **Utilidad de las respuestas:** ¿La respuesta atiende la pregunta, usa los datos correctos de ubicación o servicio e indica los límites importantes? - **Siguiente paso adecuado:** Cuando no se conoce la disponibilidad, ¿el agente ofrece la vía de solicitud sin dar a entender que ya hay una reserva? - **Integridad de la transferencia:** ¿Recibe el equipo la pregunta del visitante, la fuente pertinente, la decisión pendiente y los datos de contacto que la persona eligió compartir? - **Aceptación de la transferencia:** ¿Qué proporción de las transferencias enviadas recibe confirmación de que alguien se hará cargo dentro del plazo acordado? - **Seguimiento completado:** ¿Qué proporción de las transferencias aceptadas recibe el seguimiento prometido dentro de su plazo? Define cada medida con numerador, denominador y método de revisión. La proporción de respuestas respaldadas es el número de respuestas factuales de la muestra con todas sus afirmaciones importantes respaldadas, dividido por el total de respuestas factuales revisadas. Quien revisa decide qué afirmaciones importan y qué cuenta como respaldo; una respuesta con una afirmación importante sin respaldo no supera la comprobación. Para las transferencias, define un grupo por período de envío y sus plazos antes de medir. Por ejemplo, permite un día hábil para aceptar la responsabilidad y dos días hábiles desde la aceptación para completar el seguimiento. Calcula las proporciones cuando todos los casos del grupo hayan tenido su plazo completo; muestra los casos más recientes como pendientes. Una muestra semanal ilustrativa, que no representa un resultado del producto, podría incluir 20 respuestas factuales, de las cuales 18 están completamente respaldadas: **18 / 20 = 90 %**. De 10 transferencias enviadas, 8 se aceptan en un día hábil: **8 / 10 = 80 %**. Si 6 de esas 8 reciben seguimiento dentro de los dos días hábiles siguientes a su aceptación, la proporción completada es **6 / 8 = 75 %**. Los otros dos casos aceptados siguen atrasados o sin resolver; confirmar la recepción no cuenta como seguimiento. ## Evalúa un ejemplo concreto Imagina que un visitante pregunta: «¿Pueden sentarse 36 personas en el salón, hay una entrada sin escalones y puedo reservarlo para el 16 de octubre?». El agente consulta las páginas de capacidad, accesibilidad y solicitudes. Una respuesta adecuada sería: > «La página del salón indica capacidad para 36 personas sentadas y la página de accesibilidad describe una entrada sin escalones. Puedo preparar una solicitud para el 16 de octubre, pero la sala no quedará reservada hasta que el equipo revise el calendario y lo confirme». La respuesta es útil si las páginas citadas respaldan los datos de capacidad y acceso, y el visitante puede llegar al formulario de solicitud. Comprueba la integridad del paquete cuando el equipo recibe la fecha, la pregunta pertinente y los datos de contacto elegidos. Registra la aceptación cuando el equipo confirma que se hará cargo, y el seguimiento completado cuando responde al visitante. Ninguno de esos eventos demuestra que se haya realizado una reserva. Estas puntuaciones para un solo caso son ilustrativas y no representan un resultado del producto. Si el visitante pide al equipo que compruebe la fecha, evalúa la respuesta y la transferencia por separado: | Resultado | Comprobación para este visitante | Puntuación ilustrativa | | --- | --- | --- | | Utilidad | La respuesta aborda la capacidad y el acceso sin escalones, ofrece una forma de solicitar el 16 de octubre e indica que no hay una reserva confirmada. | 3 / 3 comprobaciones | | Respaldo aprobado | Las afirmaciones sobre capacidad y acceso coinciden con sus páginas aprobadas vigentes; la disponibilidad sigue sin confirmarse. | 2 / 2 afirmaciones respaldadas | | Calidad de la transferencia | El borrador registra la pregunta sobre el 16 de octubre, las páginas consultadas, la decisión pendiente sobre el calendario y al equipo de la sala como responsable. El visitante aún no eligió una vía de seguimiento. | 4 / 5 campos; mantén el borrador pendiente | ## Prueba casos habituales y difíciles Prepara un pequeño conjunto de evaluación a partir de las necesidades de los visitantes: una pregunta directa, una paráfrasis, una solicitud ambigua, un dato que no aparezca en el sitio, páginas contradictorias, una petición para garantizar una fecha y un caso que requiera a una persona. Anota la respuesta esperada, la fuente, el siguiente paso y cómo debe actuar el sistema si falla. Evalúa por separado la calidad de la respuesta y la transferencia para que una buena respuesta no oculte un traspaso fallido. Durante un piloto, revisa una muestra de las interacciones reales solo de acuerdo con las políticas de privacidad y conservación de datos de la organización. Limita los datos recopilados, restringe quién puede revisarlos y oculta los detalles que no sean necesarios. Pide a las personas responsables de la tarea del visitante que revisen una muestra uniforme; las puntuaciones automatizadas pueden ayudar a organizar la revisión, pero no determinan si el resultado de servicio es aceptable. ## Define cómo decidir antes de ampliar Acuerda los umbrales de lanzamiento con las personas responsables del servicio, la capacidad de revisión y las consecuencias de una respuesta equivocada. Define qué errores detienen el piloto, cuáles requieren corrección y quién aprueba la ampliación. Si cambia una fuente, una instrucción o la vía de transferencia, vuelve a probar los casos afectados. Presenta la muestra y sus límites junto con los resultados, sin usar una única puntuación como prueba de calidad general. Empieza por la [evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia), define la [transferencia a una persona](/es/conocimiento/agentes-para-sitios-web/transferencia-a-una-persona) y repasa el [patrón de agente para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) antes de ampliar la experiencia para visitantes. ### ¿Qué es un agente de IA para sitios web? - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web - Language: es - Description: Un agente de IA para sitios web usa información aprobada del sitio y acciones acotadas para responder a visitantes, orientar los siguientes pasos y derivar a una persona lo que no pueda resolver. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente de IA para sitios web ayuda a los visitantes con una tarea concreta: responder una pregunta, encontrar el siguiente paso o preparar una transferencia a una persona. Usa información aprobada y actúa dentro de los límites definidos para esa tarea. **Pregunta de ejemplo:** «¿Ofrecen servicio de climatización en Oakfield? ¿Qué debo preparar y cómo reservo una consulta?» En este ejemplo ficticio, la página de zonas de servicio aprobada incluye Oakfield para climatización, la lista de preparación pide tener a mano el modelo del equipo y una descripción breve del problema, y la página de reservas ofrece una consulta. El agente revisa esas páginas y responde solo con los datos que contienen. Respuesta ilustrativa; el contenido del sitio y la persona visitante son ficticios: > «La página de zonas de servicio incluye Oakfield para servicios de climatización. Antes de la consulta, prepara el modelo del equipo y una descripción breve del problema. Puedes usar la página de consultas para solicitar una cita». **Fundamentación y transferencia:** La respuesta exacta debe basarse en las páginas vigentes del sitio. Si la zona de la persona visitante no aparece, las páginas se contradicen o pregunta por un compromiso específico de su cuenta, el agente debe explicar qué no puede confirmar y ofrecer la ayuda de una persona. **Transferencia con ejemplo:** La página de consultas tiene un formulario, pero no muestra horarios disponibles. Si le piden garantizar una cita para mañana, el agente podría responder: > «El sitio no muestra la disponibilidad de mañana. ¿Quieres que le pida al equipo que lo compruebe? No he reservado una cita». Con el consentimiento de la persona, prepara un borrador con la fecha solicitada, la página consultada y la duda sobre disponibilidad. La solicitud queda pendiente hasta que el equipo receptor confirme que se hará cargo. ![Conversación ilustrativa en un sitio web con una respuesta basada en información sobre Oakfield, una pregunta aclaratoria y la transferencia a una persona.](/content/knowledge/visuals/es-what-is-a-website-ai-agent.svg) *Conversación ilustrativa, no es la interfaz de un sitio real.* ## Asigna un trabajo claro al agente **Trabajo y acceso:** Para esta solicitud, el trabajo consiste en responder preguntas sobre las zonas de servicio y la preparación, y después guiar a la persona visitante a la página de consultas. Las páginas aprobadas son su fuente de información. Una consulta de páginas y un enlace para reservar pueden ser suficientes; acceder a cuentas o poder hacer compromisos añadiría riesgo sin ayudar con esta tarea. **Alcance y revisión humana:** Decide qué preguntas están dentro del alcance, qué información puede solicitar el agente y quién se ocupa de las excepciones. Trata el texto que aporta la persona visitante y el contenido de las páginas como información que se debe evaluar, no como permiso para ignorar los límites del flujo de trabajo. Para las acciones con consecuencias, fija un punto de revisión humana explícito y define qué contexto recibirá la persona encargada. ## Identifica cuándo conviene un agente para sitios web - **Conviene cuando:** Las personas visitantes hacen preguntas frecuentes, las respuestas están en fuentes mantenidas y existe un siguiente paso claro. - **Una opción más sencilla:** Una sección de preguntas frecuentes o un formulario pueden bastar si las preguntas y las rutas son predecibles. - **No conviene sin una vía aprobada:** Una emergencia, una decisión específica de una cuenta o una promesa de reserva requiere una persona responsable o un sistema verificado. No dejes al visitante esperando una transferencia sin supervisión. - **Antes del piloto:** Comprueba que las páginas aprobadas estén actualizadas, mide si las respuestas tienen respaldo y revisa si las transferencias dan al personal contexto suficiente. Para conocer el alcance específico del producto, consulta la página de [AI Front Desk](/es/solutions/ai-front-desk) y el [resumen de agentes de IA para sitios web](/es/marketing/website-ai-agents). Para las transferencias y las pruebas, continúa con [revisión humana y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) y [evaluación de agentes de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). ### ¿Qué es un agente de recepción con IA? - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-recepcion-con-ia - Language: es - Description: Un agente de recepción con IA responde preguntas, dirige solicitudes, reserva citas y deriva casos a personas. Aprende a delimitar este trabajo. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Un agente de recepción con IA desempeña el trabajo de recepción en un sitio web: responde preguntas iniciales, identifica el siguiente paso, ayuda a reservar citas y deriva casos que necesitan una persona. Su valor depende de completar esa tarea con información correcta y límites claros. La [definición de agente de IA para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) explica la categoría general. Recepción tiene un trabajo específico: ayudar a llegar al servicio o persona adecuada sin asumir toda la relación con el cliente. ![Una persona llega a recepción, que responde, dirige la solicitud, reserva una cita o deriva a una persona.](/content/knowledge/visuals/es-ai-front-desk-agent.svg) *El resultado adecuado puede ser respuesta, dirección, reserva o derivación humana.* ## Define cuatro responsabilidades | Responsabilidad | Resultado útil | Límite que debes definir | | --- | --- | --- | | Responder | Una respuesta basada en información aprobada | Qué ocurre si falta información o está obsoleta | | Dirigir | La persona llega al servicio o contacto adecuado | Qué solicitudes necesitan valoración humana | | Reservar | Una cita queda reservada mediante el flujo compatible | Qué datos y confirmación acreditan la reserva | | Derivar | Una persona recibe contexto suficiente para continuar | Quién recibe el caso y qué espera el visitante | Mide estos resultados por separado. Quien pregunta por horarios quizá solo necesite una respuesta. Una solicitud inusual puede necesitar derivación. Pedir a todo el mundo que reserve añade trabajo y puede ocultar fallos al responder preguntas sencillas. ## Sigue una visita ficticia Willow Repair, una empresa ficticia, quiere ayuda para recibir consultas web. Una persona pregunta: «¿Reparan este tipo de equipo y puedo organizar una visita?». El agente consulta información aprobada. Si el equipo está cubierto, explica el siguiente paso y ayuda a reservar mediante el flujo configurado. Antes de lanzar, Willow debe decidir qué detalles debe confirmar el visitante y cómo reconocer una reserva completada en el sistema real. Pedir una visita y tener una cita confirmada son estados diferentes. Si falla la reserva o el resultado no queda claro, el agente debe indicar que no está confirmada y ofrecer el contacto acordado. No debe fomentar solicitudes repetidas sin comprobar el resultado anterior. Si el equipo queda fuera de la descripción aprobada, conviene derivar. El agente resume la pregunta y los detalles ya aportados, usando solo la información necesaria para quien los recibe. No debe prometer que la empresa aceptará el trabajo ni inventar plazos. ## Prepara información y reglas de derivación Empieza por servicios actuales, contactos, horarios, ubicación y respuestas aprobadas a preguntas frecuentes. Asigna responsable y proceso de actualización a cada fuente. Define flujo de reservas y confirmación con el negocio; admitir citas no implica una integración concreta con calendarios. Escribe reglas para información faltante, servicios no admitidos, quejas, reservas fallidas o peticiones de atención humana. Decide qué contexto se transmite, a quién y qué ve después el visitante. La [guía de derivación humana](/es/conocimiento/agentes-para-sitios-web/transferencia-a-una-persona) amplía ese diseño. ## Prueba los resultados de recepción Usa conversaciones representativas: - Una pregunta respondida con información vigente y aprobada. - Una pregunta cuya respuesta falta o es contradictoria. - Una persona que conoce el servicio que quiere y solicita cita. - Una solicitud incompleta y un resultado de reserva incierto. - Un servicio fuera de alcance y una petición explícita de atención humana. Comprueba exactitud, dirección, confirmación de reserva y utilidad de derivación por separado. Revisa qué ocurre cuando falta una fuente o un paso conectado. Cuenta tareas completadas cuando se acredita el resultado, no cada conversación como una oportunidad comercial o reserva lograda. ## Elige el producto después de definir el trabajo [AI Front Desk Starter de AgentShelf](/es/solutions/ai-front-desk) ayuda a los negocios a atender la recepción web, incluidas las reservas de citas. La [oferta gratuita](/es/solutions/ai-front-desk/free) tiene página propia. Valora la oferta actual y define fuentes, citas, derivación y responsabilidad antes de establecer expectativas. Prepara después una [base de conocimiento web aprobada](/es/conocimiento/agentes-para-sitios-web/disenar-la-base-de-conocimiento) y prueba las cuatro responsabilidades con quienes las operarán. ### Transferencia de agentes de sitios web a una persona - Route: https://agentshelf.ai/es/conocimiento/agentes-para-sitios-web/transferencia-a-una-persona - Language: es - Description: Define cuándo debe pausarse el agente, qué contexto compartir, quién acepta la consulta y qué ve el visitante mientras espera. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Una transferencia a una persona funciona cuando el visitante sabe que alguien responderá, el equipo adecuado recibe un resumen útil y una persona asume el siguiente paso. Antes de habilitarla, define qué la activa, qué datos mínimos se comparten y qué alternativa ofrecer si no hay nadie disponible. Ejemplo ficticio: Una persona que visita el sitio de Selby Home Repair pregunta si la empresa inspecciona filtraciones de techo en Hollis, un pueblo que no aparece en la lista pública de zonas de servicio. El sitio indica que el equipo responde las solicitudes habituales de cita durante el horario laboral. El agente no puede confirmar la cobertura ni enviar ayuda. Puede explicar que Hollis no figura en el sitio, preguntar si la persona quiere que el equipo lo compruebe y preparar un borrador de transferencia con el horario preferido para la devolución de llamada. ![En un punto de revisión claro, una persona puede aprobar, modificar, rechazar o pausar la solicitud preparada.](/content/knowledge/visuals/es-human-in-the-loop-ai-agents.svg) *La transferencia es un punto de decisión con responsable, no un simple icono.* ## Decide cuándo debe intervenir una persona Dirige la consulta a una persona cuando la respuesta no esté en la información publicada, haya fuentes contradictorias, se requiera un compromiso o el visitante pida ayuda humana. Define también cuándo escalar quejas, necesidades de accesibilidad, inquietudes de seguridad o consultas específicas de una cuenta. La falta de información no autoriza al agente a adivinar. En Selby, el motivo es que el pueblo no está en la lista. Que falte un teléfono de contacto no da permiso para recopilar datos sin relación con la tarea: primero pregunta qué desea compartir el visitante y explícale por qué lo necesita el equipo. No presentes una solicitud de servicio habitual como una vía de emergencia a menos que la empresa haya definido y dotado de personal esa respuesta. ## Prepara un resumen para quien recibe la consulta Comparte suficiente contexto para que quien recibe la solicitud pueda continuar sin hacer que el visitante repita todo. El paquete podría incluir: - La pregunta original y el objetivo que expresó el visitante. - La página pública pertinente y el dato que el agente no pudo confirmar. - La respuesta ya ofrecida, separada con claridad de los datos pendientes. - Los datos de contacto que el visitante decidió compartir y la vía de seguimiento acordada. - La hora de la solicitud, el estado actual y el equipo que debería responder. Limita los datos personales a los que necesita el siguiente paso. Cuando sea posible, permite que el visitante revise o corrija el resumen. Explica si la solicitud solo se preparó, llegó a una bandeja o ya fue aceptada por una persona. En el caso de Selby, el borrador de transferencia podría decir: «Comprueba si se hacen inspecciones por filtraciones de techo en Hollis y llama después de las 3 p. m. si se confirma la cobertura. La persona pregunta por una filtración; la página pública de zonas de servicio no menciona Hollis. No se ha ofrecido una cita». El agente no hizo una reserva ni prometió el servicio. ## Asigna la responsabilidad y confirma la recepción Indica qué equipo supervisa cada bandeja, en qué horario, en cuánto tiempo espera responder y quién lo reemplaza. Decide qué verá el visitante después de enviar la solicitud. Si no hay respuesta inmediata, indica cuándo y cómo espera contestar el equipo u ofrece otra vía de contacto. No muestres «conectado» o «aceptado» hasta que una persona o un sistema haya confirmado que alguien se hará cargo. En el caso de Selby, muestra mensajes distintos para las transferencias confirmadas y las que siguen pendientes: > **Recepción confirmada:** «El equipo de Selby recibió tu solicitud para comprobar si ofrece servicio en Hollis. El sitio indica que las consultas habituales de citas reciben respuesta durante el horario laboral. No se ha reservado ninguna inspección». > **Sin confirmar:** «No puedo confirmar que el equipo haya recibido tu solicitud, así que todavía nadie la ha aceptado. Usa el método de contacto publicado en el sitio». Mantén pendientes las solicitudes sin confirmar y no prometas un plazo que supere lo indicado en la información publicada. Prueba las solicitudes recibidas dentro y fuera del horario laboral, las bandejas no disponibles, los envíos duplicados y los casos en que una persona cambia o retira su solicitud. Comprueba que el paquete llegue a la persona adecuada, que el visitante vea el estado correcto y que el caso pueda seguirse hasta recibir respuesta. Registrar un evento de transferencia no demuestra que se haya completado. Usa la guía de [revisión humana y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) para elegir el punto de decisión. Para la conversación en el sitio, consulta [agentes de IA para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) y [evalúa el flujo de visitantes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). ### Agentes reutilizables y casos de uso empresariales - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso - Language: es - Description: Evalúa un patrón de agente según tu flujo de trabajo, la evidencia, los permisos y las necesidades de revisión antes de reutilizarlo o desarrollarlo. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un patrón de agente reutilizable ofrece un punto de partida para una tarea recurrente. Su utilidad sigue dependiendo de los datos de entrada, las acciones permitidas, el resultado esperado y el proceso de revisión. ![Las consultas, la recepción de proveedores y la asistencia con políticas comparten una estructura de tarea y revisión, con entradas y resultados distintos para cada trabajo.](/content/knowledge/visuals/es-use-cases.svg) Esta ruta ayuda a los equipos a comparar flujos de trabajo posibles y a evaluar si un patrón existente es adecuado. Primero define el trabajo y luego compáralo con el patrón. ## Elige la tarea antes que el agente Usa la guía [cómo elegir un caso de uso para un agente de IA](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso) para comparar las tareas posibles. Da preferencia a un primer piloto cuyo resultado se pueda inspeccionar y cuyos errores se puedan contener. Define qué significa tener éxito antes de revisar implementaciones. ## Compara tres tareas de ejemplo | Tarea | Flujo compartido: entrada → tarea → resultado → revisión | Qué cambia en tu equipo | | --- | --- | --- | | Consulta de un visitante | Pregunta del visitante → buscar una respuesta aprobada → responder y resumir la solicitud → el equipo revisa las consultas poco claras. | Páginas de servicios actualizadas, vía de contacto y horario de atención. | | Recepción de proveedores | Formulario y documentos → comprobar evidencia y faltantes → resumen estructurado de la solicitud → la persona responsable verifica las excepciones. | Requisitos de recepción, documentos permitidos y quién resuelve los riesgos. | | Consulta sobre políticas | Pregunta y función de la persona → buscar la regla aplicable → explicación con fuentes o descripción de la información faltante → la persona responsable de la política revisa los conflictos. | Versión vigente de la política, alcance y responsable de las excepciones. | Estos ejemplos comparten las mismas etapas, pero cada uno depende de fuentes, límites de acceso y decisiones de revisión diferentes. ## Reutiliza, configura o desarrolla | Enfoque | Preguntas que debes resolver | | --- | --- | | Reutilizar un patrón | ¿Coinciden el trabajo previsto y el resultado con los nuestros? ¿Qué se debe revisar antes de usarlo? | | Configurar un patrón | ¿Podemos adaptar las fuentes, las instrucciones, los permisos y los puntos de revisión sin cambiar el trabajo? | | Desarrollar un flujo personalizado | ¿Qué requisito necesita otra integración o proceso operativo, y quién le dará mantenimiento? | Reutiliza un patrón si ya encajan la tarea, las entradas, los permisos y los límites. Configúralo si admite cambios en las fuentes, los permisos o la revisión sin modificar el flujo. Desarrolla una solución a medida solo si aún queda un requisito necesario del flujo o de la integración que no puedes resolver. ## Prueba el flujo adaptado Redacta una [descripción concreta del trabajo](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada) y [evalúa tareas representativas](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). Una demostración prometedora no determina por sí sola si el patrón se ajusta a tus fuentes o límites operativos. Explora las ofertas actuales en la [biblioteca de agentes](/es/discover). Usa el [diseño de agentes](/es/conocimiento/diseno-de-agentes) para preparar la configuración y la [gobernanza](/es/conocimiento/gobernanza-de-ia) para planificar la operación después del piloto. ## Defiende los sistemas que ejecutas La [ruta de ciberdefensa](/es/conocimiento/ciberdefensa-con-ia) cubre tareas continuas de seguridad con autoridad y comprobaciones de finalización explícitas. Elige [una primera tarea defensiva](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) o usa IA para [encontrar, corregir y retirar sistemas heredados](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-sistemas-heredados-con-ia). ## Todas las guías de este tema - [Agentes de IA para calificar y enriquecer oportunidades comerciales](/es/conocimiento/casos-de-uso/agentes-para-calificar-oportunidades-comerciales): Usa un agente para comparar las necesidades expresadas por un posible cliente con criterios aprobados, detectar datos faltantes y preparar un seguimiento revisable por una persona. - [Agentes de IA para el conocimiento interno](/es/conocimiento/casos-de-uso/agentes-para-el-conocimiento-interno): Usa un agente para responder preguntas internas cuando las políticas y los procedimientos aprobados respalden respuestas verificables y el flujo pueda derivar las excepciones. - [Agentes de IA para preparar informes de investigación](/es/conocimiento/casos-de-uso/agentes-para-informes-de-investigacion): Usa un agente para acotar una pregunta de investigación, comparar fuentes aprobadas y redactar un informe con afirmaciones rastreables e incertidumbres visibles. - [Agentes de IA para preparar reuniones](/es/conocimiento/casos-de-uso/agentes-para-preparar-reuniones): Prepara un informe de reunión verificable con agendas aprobadas, registros vigentes y notas de acciones, mientras las decisiones y compromisos siguen a cargo de las personas. - [Reutilizar o desarrollar: cuándo usar una biblioteca de agentes y cuándo crear uno a medida](/es/conocimiento/casos-de-uso/biblioteca-de-agentes-vs-desarrollo-a-medida): Reutiliza un patrón si coinciden el trabajo y sus límites; configúralo si puedes adaptar las entradas; desarrolla uno a medida si sigue faltando un requisito real. - [¿Qué es una biblioteca de agentes de IA?](/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes): Compara el descubrimiento público con las bibliotecas aprobadas de organización y equipo. ### Agentes de IA para calificar y enriquecer oportunidades comerciales - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-calificar-oportunidades-comerciales - Language: es - Description: Usa un agente para comparar las necesidades expresadas por un posible cliente con criterios aprobados, detectar datos faltantes y preparar un seguimiento revisable por una persona. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente puede comparar las necesidades que expresa un posible cliente con los criterios de servicio aprobados para ayudar a calificar una oportunidad entrante. Puede organizar la información empresarial pertinente y señalar qué falta confirmar. Define los criterios, recoge solo los datos necesarios para el siguiente paso y deja las decisiones comerciales y los compromisos a una persona autorizada. Ejemplo ficticio: Juniper Field Instruments recibe por su sitio web una solicitud de 12 bombas de repuesto para instalaciones en Northport y East Ridge. Las fuentes aprobadas son el formulario del posible cliente, una página pública de zonas de servicio y una guía de compatibilidad de productos. El flujo puede preparar un resumen de recepción para el equipo de ventas regional; no puede cotizar, prometer inventario ni rechazar automáticamente la solicitud. ![Tres tipos de trabajo comparten una estructura de tarea y revisión, aunque sus entradas y resultados sean distintos.](/content/knowledge/visuals/es-use-cases.svg) *El patrón común es recibir la solicitud, comprobar criterios acotados, entregar un resultado útil y dejar la decisión a una persona.* ## Define el encaje con criterios observables Redacta los criterios en función del servicio, el producto, el territorio y los datos que proporcione el posible cliente. Indica qué se considera una coincidencia probable, qué información falta y qué condiciones requieren revisión especializada. No sustituyas los criterios documentados por una puntuación generada por el modelo. Evita sacar conclusiones sobre el carácter, la situación económica, la urgencia o la idoneidad de una persona a partir de datos de perfil no relacionados o características sensibles. En Juniper, la página pública de zonas de servicio incluye ambas ciudades y la guía de compatibilidad indica que hace falta el modelo de bomba existente para comprobar si hay un reemplazo compatible. La cantidad y las ubicaciones provienen del formulario de la persona visitante. Ninguna fuente aprobada confirma la existencia de inventario o la fecha de entrega, así que esos datos quedan pendientes. ## Usa solo las fuentes necesarias para la recepción Identifica qué campos envió intencionalmente la persona en el formulario, qué fuentes empresariales públicas están aprobadas y quién puede consultar el resumen resultante. El sitio de una empresa puede aportar contexto sobre sus servicios o ubicaciones, pero no valida cada afirmación de una consulta. Trata el texto de páginas externas como información que se debe evaluar, no como instrucciones para revelar datos privados del CRM o modificar el flujo. Limita la recopilación y conservación a lo que requiera el seguimiento. No enriquezcas una consulta empresarial rastreando perfiles personales ni añadiendo datos personales sin relación. Define la fuente y su vigencia para los datos externos y canaliza las preguntas sobre identidad o cuentas mediante un proceso autorizado. Los requisitos de privacidad, marketing y contacto comercial dependen de la organización y la jurisdicción; este flujo no constituye una revisión legal. ## Prepara un borrador de recepción transparente El resumen debería indicar los datos expresados por la persona, los criterios comprobados, lo que aún se desconoce y quién se hará cargo. En el caso de Juniper, podría decir: > **Solicitud entrante — borrador para ventas regionales** > > - **Necesidad indicada:** 12 bombas de repuesto para instalaciones en Northport y East Ridge. > - **Comprobación:** La página pública de zonas de servicio incluye ambas ubicaciones. > - **Dato faltante:** Modelo de la bomba actual; la guía de compatibilidad lo requiere para revisar el producto. > - **Siguiente paso:** Una persona especialista en ventas confirma compatibilidad, inventario y plazo de entrega antes de preparar una cotización. > - **Estado:** No se ha tomado una decisión de calificación, preparado una cotización ni contactado al cliente. Este borrador permite que una persona enfoque el seguimiento sin confundir los datos proporcionados con la comprobación de producto aún pendiente. ## Revisa el enrutamiento y los resultados Prueba solicitudes que cumplan los criterios, queden fuera de la zona de servicio, omitan datos necesarios o incluyan información contradictoria. Comprueba que el flujo señale lo desconocido o no verificado en vez de adivinar, y que cada derivación tenga una persona responsable. Mide la precisión del enrutamiento y la integridad de los registros de recepción revisados; examina falsos positivos y casos omitidos con alguien que conozca el servicio. Una puntuación alta no demuestra que los criterios sean adecuados. Mantén la aprobación humana antes de cotizar, decidir si se cumplen requisitos o iniciar contacto comercial cuando esas acciones excedan la autoridad explícita del agente. Revisa los criterios cuando cambien los productos, el territorio o la política de ventas. Si el flujo influye en el acceso a un servicio de consecuencias importantes, consulta a las personas responsables de políticas y asuntos legales antes del lanzamiento. Usa la [guía sobre agentes para sitios web](/es/conocimiento/agentes-para-sitios-web/que-es-un-agente-de-ia-para-sitios-web) para definir los límites de consultas públicas, los [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) para revisar el acceso y la [revisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) para definir el punto de decisión. [Evalúa el flujo de recepción](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) con casos de datos faltantes, afirmaciones sin respaldo y enrutamiento antes de usarlo. ### Agentes de IA para el conocimiento interno - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-el-conocimiento-interno - Language: es - Description: Usa un agente para responder preguntas internas cuando las políticas y los procedimientos aprobados respalden respuestas verificables y el flujo pueda derivar las excepciones. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente puede ayudar con el conocimiento interno cuando el personal necesita encontrar y aplicar políticas o procedimientos vigentes en fuentes aprobadas. Delimita la tarea, indica qué fuente respalda la respuesta y deriva a una persona responsable las decisiones que le correspondan; no presentes una respuesta generada como si fuera la política misma. Ejemplo ficticio: En Wrenfield Works, una persona pregunta: «¿Puedo reservar un tren nocturno para la conferencia regional del 14 de octubre y qué aprobación necesito?». El agente puede consultar la política de viajes vigente y la guía para presentar gastos. Puede preparar una respuesta o una solicitud de aprobación, pero la persona responsable aprueba el viaje y el agente no compra billetes. ![El conocimiento aprobado, un método de trabajo, una capacidad de consulta y una conexión autorizada respaldan una tarea acotada.](/content/knowledge/visuals/es-knowledge-skills-tools-and-connections.svg) *El trabajo con conocimiento interno combina información con un siguiente paso autorizado.* ## Elige una pregunta con respuesta verificable Algunos buenos casos iniciales son las preguntas sobre un procedimiento vigente, los requisitos indicados en una política o dónde encontrar el formulario interno adecuado. Evita combinar varias aprobaciones o decisiones personales en un agente general para «preguntar lo que sea». Si la respuesta depende de la función, la región, la cuenta o el historial de un caso de alguien, confirma que el flujo pueda recuperar únicamente el contexto autorizado que necesita. En Wrenfield, la política de viajes indica que hace falta la aprobación de una persona responsable antes de reservar un viaje nocturno. La guía de gastos explica cómo presentar los costos después del viaje. Estas fuentes responden a la pregunta sobre el procedimiento; ninguna decide si se debe aprobar ese viaje. ## Decide quién mantiene cada fuente y quién puede consultarla Identifica quién responde por cada fuente y a qué público se dirige. Separa las políticas vigentes de las instrucciones archivadas, indica las fechas de vigencia y resuelve los conflictos antes de habilitar el acceso a los archivos. Aplica límites de acceso en el sistema conectado: el agente no debería acceder a expedientes de personal ni a otros datos privados solo porque responde preguntas de empleados. En Wrenfield, la persona responsable de la política confirma la regla y el área de finanzas mantiene los pasos para presentar gastos. El agente solo necesita esos documentos aprobados. Si alguien pregunta por una excepción o por su saldo personal de reembolso, el flujo deriva la consulta a la persona autorizada de gerencia o finanzas, en vez de buscar en otros expedientes. ## Entrega una respuesta que el personal pueda verificar La respuesta debería indicar la regla, identificar la fuente vigente y dejar claro el límite. Un borrador adecuado sería: > **Orientación sobre viajes:** «La política vigente requiere aprobación de una persona responsable antes de reservar un viaje nocturno. La guía de gastos explica cómo presentar los costos después del viaje. Puedo preparar una solicitud de aprobación para el 14 de octubre; no he reservado el viaje ni lo he aprobado». El agente respondió usando dos documentos aprobados y ofreció un siguiente paso en forma de borrador. No reservó ni tomó una decisión. Si la versión de la política no está clara, falta la fuente o la persona pide una excepción, la respuesta debería indicar qué hay que confirmar y quién es responsable. Para un caso sin respuesta, imagina que alguien pregunta si puede asistir con un acompañante a la conferencia regional y ninguna fuente aprobada habla de invitados. El agente debe decir que no encontró una respuesta aprobada, ofrecerse a consultar a la persona responsable de la política de viajes y detenerse antes de reservar o aprobar nada. El borrador para esa persona podría decir: «Confirma si puede asistir un acompañante a la conferencia regional. La política de viajes vigente y la guía de gastos no tratan el tema de invitados; no se ha hecho ninguna reserva ni aprobación». ## Evalúa el flujo antes de ampliar el acceso Prueba preguntas directas, paráfrasis, políticas obsoletas, instrucciones contradictorias, consultas que dependan de la función de cada persona y situaciones fuera del alcance. Comprueba si los pasajes recuperados respaldan la respuesta y si el flujo respeta los límites de acceso. Incluye un caso en que la respuesta correcta sea detenerse y consultar a una persona. Durante un piloto, usa información que la organización haya aprobado para la evaluación y limita su revisión al personal que la necesite. Define quién actualiza cada política, cómo detectar contenido vencido y cómo se puede informar de una respuesta incorrecta o ausente. Revisa el alcance si cambian la persona responsable, el acceso o las reglas de aprobación. Para preparar las fuentes, lee [cómo fundamentar un agente en el contexto aprobado](/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial) y [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones). Revisa los [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) antes de conectar sistemas internos y [evalúa el flujo](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) antes de ampliar el acceso. Para evaluar un candidato para tu flujo de fuentes aprobadas, consulta el [agente Knowledge Base](/discover/knowledge-base). Verifica su alcance y requisitos de acceso actuales antes de usar información empresarial. ### Agentes de IA para preparar informes de investigación - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-informes-de-investigacion - Language: es - Description: Usa un agente para acotar una pregunta de investigación, comparar fuentes aprobadas y redactar un informe con afirmaciones rastreables e incertidumbres visibles. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente puede preparar un informe de investigación consultando un conjunto definido de fuentes públicas o internas, registrando el origen de cada afirmación y separando los hallazgos respaldados de las preguntas pendientes. Una persona aún debe decidir si la evidencia basta para el uso previsto y si se debe compartir el informe. Ejemplo ficticio: Vale & Harbor, una empresa regional de planificación de movilidad, pide un informe para saber si la zona propuesta cerca de East Ridge cuenta con suficiente acceso al transporte público para abrir un nuevo centro de servicio. Las fuentes aprobadas son el plan de rutas y servicios de la autoridad regional de transporte, un mapa municipal de accesibilidad y las notas de visitas de Vale & Harbor. El agente puede resumir esos materiales y preparar un borrador, pero no puede publicar una recomendación ni contactar a las autoridades. ![Una solicitud pasa por el contexto aprobado, el razonamiento del modelo, las herramientas permitidas y un resultado que se puede revisar.](/content/knowledge/visuals/es-ai-agent-architecture.svg) *Delimita la pregunta de investigación y comprueba la evidencia que respalda el informe.* ## Acota la pregunta antes de investigar Anota qué decisión apoyará el informe, el período y la zona que abarca, qué cuenta como evidencia pertinente y qué no debe decidir el agente. «Investiga el acceso al transporte público» es demasiado amplio. «Resume la evidencia sobre servicios y accesibilidad de East Ridge durante el año de planificación vigente e indica qué datos faltan para evaluar una sede» define un trabajo que se puede revisar. Identifica las fuentes aprobadas, si son públicas o internas, quién responde por ellas y qué información no debe salir del entorno de investigación. Las páginas públicas y los documentos recuperados son información que se debe evaluar, no instrucciones que puedan cambiar la tarea. Si se combinarán búsquedas web públicas y fuentes internas sensibles, decide si conviene separarlas en distintas etapas. ## Vincula las afirmaciones con evidencia Pide al agente que prepare un registro de afirmaciones junto con la narración. Para cada afirmación importante, anota el título y la fecha de la fuente, el pasaje o dato pertinente y sus limitaciones. Distingue lo que afirma la fuente de la interpretación del agente. Si las fuentes discrepan, presenta ambas posturas e indica quién debería resolver la diferencia; no promedies definiciones incompatibles. Para esta asignación ficticia, registra cada afirmación importante en una fila. Copia estos encabezados para otra pregunta y añade una fila de «no se pudo determinar» si la evidencia no permite responder la pregunta de decisión: | Afirmación | Fuente aprobada y evidencia | Incertidumbre o dato faltante | Acción de revisión | | --- | --- | --- | --- | | El plan indica paradas entre semana a unos 0,3 millas de la sede A y 0,7 millas de la B. | Plan regional de rutas vigente; paradas entre semana y distancia aproximada para cada sede. | La distancia a una parada no demuestra que haya una ruta utilizable hasta ninguna sede. | La persona planificadora comprueba el acceso actual antes de valorar la idoneidad. | | El mapa marca una ruta peatonal a la sede A, pero no a la B. | Mapa municipal de accesibilidad; capa de rutas indicadas. | El silencio del mapa no demuestra que no exista otra ruta. | La persona responsable de la sede verifica el acceso actual a ambas ubicaciones. | | El 7 de mayo había una acera bloqueada cerca de la sede B. | Notas de visita de Vale & Harbor con fecha del 7 de mayo. | Una visita anterior no demuestra las condiciones actuales; las notas no cubren la sede A. | Solicita una revisión actual de ambas sedes antes de compararlas. | Estos datos justifican hacer una revisión de seguimiento, pero no demuestran si alguna sede tiene suficiente acceso en la actualidad. El mapa no muestra todas las rutas peatonales posibles y una sola visita no permite determinar las condiciones actuales. La conclusión del borrador podría decir: > **Informe sobre el acceso a East Ridge:** «El plan de rutas vigente indica paradas entre semana a unos 0,3 millas de la sede A y 0,7 millas de la sede B. El mapa municipal señala una ruta peatonal hacia la sede A, pero no hacia la B. Una nota de visita del 7 de mayo informa de una acera bloqueada cerca de la sede B; no hay notas de visita sobre la sede A. Revisa el acceso actual de ambas antes de decidir si alguna es adecuada». El resultado indica qué se encontró y dónde termina la evidencia. Ofrece a la persona planificadora un siguiente paso concreto sin afirmar más de lo que respaldan las fuentes. ## Revisa la incertidumbre y la calidad de las fuentes Comprueba la autoridad, la fecha, el alcance y el método de cada fuente. Una cifra sin definición ni período quizá no responda a la pregunta. Señala los datos faltantes, las páginas obsoletas, el material inaccesible y las fuentes que repiten la misma información de origen. Incluye una sección de «no se pudo determinar» para que las lagunas no desaparezcan dentro de un texto pulido. Prueba preguntas directas, paráfrasis, fuentes contradictorias, una página irrelevante y una solicitud fuera del alcance. Revisa tanto la recuperación como la síntesis: ¿encontró el agente evidencia pertinente, respetó su significado y evitó añadir detalles sin respaldo? Si el informe depende de cálculos, comprueba por separado los datos de entrada y el método. ## Mantén a una persona responsable del informe Pide a una persona experta en el tema que compruebe las afirmaciones que puedan influir en una decisión. Facilita la revisión mostrando en conjunto la pregunta, el registro de fuentes, el borrador, las limitaciones y los puntos pendientes. Una lista de citas no sustituye la comprobación de que cada fuente respalde la afirmación correspondiente. Para diseñar las fuentes del flujo, consulta [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones) y [cómo fundamentar un agente en el contexto aprobado](/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial). Usa la [evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para probar el manejo de la evidencia y revisa la [guía de permisos](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) antes de conectar información privada. ### Agentes de IA para preparar reuniones - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/agentes-para-preparar-reuniones - Language: es - Description: Prepara un informe de reunión verificable con agendas aprobadas, registros vigentes y notas de acciones, mientras las decisiones y compromisos siguen a cargo de las personas. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente puede preparar un informe útil para una reunión cuando se conocen de antemano el propósito, las fuentes y el resultado previsto. Debería separar las novedades verificadas de las preguntas pendientes, indicar de dónde proviene cada dato y dejar las decisiones, asignaciones y compromisos en manos de quienes participan. Ejemplo ficticio: Marble Point Facilities pide: «Prepara una revisión de 30 minutos para la sede el lunes, usando la exportación vigente de órdenes de trabajo, la lista de mantenimiento aprobada y el registro de acciones de la reunión anterior. Señala los asuntos pendientes. No reasignes ni cierres solicitudes». El agente puede consultar esas tres fuentes y preparar una agenda, pero no puede modificar el sistema de órdenes. ![Una descripción de trabajo organiza a la persona responsable, el inicio de la reunión, las entradas, el resultado y las condiciones para detenerse antes de la revisión.](/content/knowledge/visuals/es-define-a-focused-agent-job.svg) *Define qué debe preparar el agente y qué decisiones corresponden a quienes participan en la reunión.* ## Define el propósito y los límites de las fuentes Indica quién usará el informe, qué debe lograr la reunión y qué registros están vigentes. Limita el acceso a la sede o el proyecto pertinente. No importes un buzón completo ni el historial de otros clientes solo para completar la agenda. Asigna responsables a la lista de mantenimiento y al registro de acciones, e indica la fecha de la exportación de órdenes. En Marble Point, la exportación vigente marca como pendiente la inspección de una bomba del ala este. El registro de la reunión anterior dice que se cambió un filtro, pero la exportación aún muestra ese trabajo «en curso». La lista de mantenimiento indica que la prueba trimestral del generador vence durante este trimestre. Son temas concretos para conversar, no una prueba de que el trabajo ya terminó ni de que deba cerrarse la orden. ## Prepara un borrador que permita actuar Pide un formato que distinga los hechos de las fuentes, los conflictos y las decisiones. Un borrador conciso podría decir: > **Revisión de la sede del ala este — lunes** > > - **Propósito:** Confirmar el mantenimiento pendiente y los siguientes pasos seguros. > - **Novedades verificadas:** Exportación vigente de órdenes de trabajo: la inspección de la bomba está pendiente. Lista de mantenimiento aprobada: la prueba trimestral del generador vence este trimestre. > - **Punto por confirmar:** Registro de acciones anterior: se completó el cambio de filtro. Exportación vigente de órdenes de trabajo: aún figura «en curso». Pide a la persona responsable de la orden que confirme el estado. > - **Decisión para la reunión:** Confirmar el estado del cambio del filtro antes de cerrar la orden. No se ha modificado ninguna solicitud. El borrador reúne la evidencia pertinente y mantiene a la vista los registros contradictorios. No decide si el registro anterior o la exportación más reciente tiene razón. La persona responsable de la orden confirmará el estado durante la reunión. ## Mantén el informe útil y vigente Usa un formato que se adapte a la reunión: propósito, agenda breve, novedades confirmadas, preguntas pendientes, decisiones necesarias y notas sobre las fuentes. Incluye la fecha de actualización e identifica el material obsoleto o faltante. Si el agente no puede acceder a un registro, debe señalarlo en vez de llenar el vacío con una suposición. Prepara cada versión solo para personas autorizadas a verla. Un resumen para gerencia quizá no necesite el mismo detalle que la lista de trabajo de una persona técnica. Quita los datos personales o de clientes que no sean necesarios y permite que quien organiza la reunión corrija el borrador antes de distribuirlo. ## Prueba la agenda antes de depender de ella Prueba un conjunto completo de fuentes, la ausencia de un registro de acciones, una exportación obsoleta, un estado contradictorio y un asunto fuera del alcance de la reunión. Comprueba que el borrador señale cada problema, no invente participantes ni fechas límite y se detenga antes de asignar trabajo. Si una persona revisa el documento, prueba qué ocurre si lo edita, lo rechaza o no responde. Para definir la tarea, lee [cómo describir el trabajo concreto de un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Usa la [evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para comprobar el manejo de la evidencia y la [revisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) antes de compartir el informe. Para evaluar un candidato con esta descripción del trabajo, consulta el [agente Meeting Prep](/discover/meeting-prep). Revisa su descripción y requisitos de fuentes actuales antes de adoptarlo. ### Biblioteca de agentes o desarrollo a medida - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/biblioteca-de-agentes-vs-desarrollo-a-medida - Language: es - Description: Reutiliza un patrón si coinciden el trabajo y sus límites; configúralo si puedes adaptar las entradas; desarrolla uno a medida si sigue faltando un requisito real. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Reutiliza un patrón de agente si coinciden el trabajo previsto, la información, las acciones y el punto de revisión con tu flujo de trabajo. Configúralo si puedes ajustar las diferencias con opciones compatibles. Desarrolla uno a medida solo si sigue faltando una integración, un control o un paso operativo necesario y tu equipo puede mantenerlo. Ejemplo ficticio: Maple Freight quiere revisar solicitudes de incorporación de proveedores. Un patrón de su biblioteca aprobada lee el paquete, lo compara con una lista de requisitos, señala la evidencia faltante y redacta una solicitud de seguimiento. El flujo de Maple también debe comparar el paquete con el registro actual del proveedor. El equipo no puede dar por hecho que el patrón incluye esa conexión o puede acceder al registro; primero debe verificar la ficha y las opciones de configuración permitidas. ![Reutiliza si el trabajo encaja, configura diferencias admitidas o desarrolla ante un requisito necesario pendiente; comprueba fuentes y acciones en cada opción.](/content/knowledge/visuals/es-agent-library-vs-custom-build.svg) *Elige según el encaje y verifica fuentes y acciones para la opción seleccionada.* ## Compara las tres opciones | Opción | Cuándo conviene | Qué comprobar antes de decidir | | --- | --- | --- | | Reutilizar | El patrón ya cubre la tarea y el resultado esperado. | ¿Coinciden el alcance de sus fuentes, la autoridad, el punto de revisión y el tratamiento de errores con tu proceso? | | Configurar | La tarea es la misma, pero hay que adaptar las fuentes aprobadas, la redacción o algunas opciones delimitadas. | ¿Admite esas diferencias como ajustes y puedes verificar qué cambia cada uno? | | Desarrollar a medida | Una conexión con un sistema, un control o un paso operativo obligatorio queda fuera del alcance compatible del patrón. | ¿Puede el equipo probar, proteger, supervisar y mantener el flujo añadido? | ## Separa descubrimiento, aprobación y esfuerzo de desarrollo Una [biblioteca de agentes reutilizables](/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes) ayuda a encontrar un punto de partida. Descubrimiento público y aprobación interna son pasos distintos: cualquier persona puede presentar un agente a una biblioteca de organización o equipo, y los responsables examinan y aprueban cuáles se incluyen. Los agentes aprobados de organización están disponibles para toda ella; los de equipo se limitan a sus integrantes. Verifica por separado el acceso a datos empresariales. Antes de comparar esfuerzos, escribe el requisito que podría exigir desarrollo a medida. Para Maple es la comparación autorizada con la ficha actual del proveedor. Una preferencia de redacción suele ser configuración; una conexión o estado de revisión necesario que no se admite puede cambiar la arquitectura. Compara preparación, pruebas, mantenimiento y excepciones durante el mismo período operativo. Ni una ficha de biblioteca ni código propio eliminan esas responsabilidades. ## Compara la solicitud de Maple con el patrón Maple pide: «Compara el paquete del proveedor con nuestra lista de requisitos aprobada y el registro actual del proveedor. Enumera la evidencia faltante y prepara una solicitud para que alguien la revise. No apruebes al proveedor ni envíes mensajes». El paquete y la lista coinciden con la tarea indicada para el patrón. El registro del proveedor es una fuente adicional, así que Maple primero debe confirmar si puede añadirse mediante una opción admitida sin cambiar el límite de aprobación. Si se puede añadir la fuente mediante un ajuste admitido, el equipo puede configurar y probar el mismo patrón. Si no puede acceder al registro pero otra integración aprobada puede proporcionarlo en modo de solo lectura, el equipo debería comparar esa opción con los requisitos antes de desarrollar. Si no están disponibles el acceso necesario, el paso de revisión o el registro de auditoría, el agente todavía no encaja. El desarrollo a medida solo se justifica si la diferencia es necesaria y una persona responsable puede operarlo. La nota de decisión podría decir: > **Decisión:** Probar primero el patrón existente para recibir proveedores. La revisión del paquete, la lista de evidencia faltante y el borrador de solicitud coinciden con la tarea. Aún falta resolver la comparación con el registro del proveedor. Continuar solo si se puede configurar y probar una fuente autorizada de solo lectura. La aprobación y el envío siguen a cargo de una persona revisora de compras. La duda pendiente es si el patrón puede leer el registro de proveedores de Maple con los permisos necesarios. Resuélvela antes de comprometerte a desarrollar una solución a medida. ## Registra la decisión de reutilizar, configurar o desarrollar Anota la decisión antes de iniciar el piloto. El registro ayuda a que todas las personas trabajen con la misma respuesta y explica a la siguiente persona responsable por qué se tomó esa decisión. El agente puede redactar la mayor parte a partir de la ficha, la descripción de tu trabajo y las fuentes que nombres. El equipo confirma el trabajo, las decisiones que conservan las personas, quién es responsable y la elección final. > **Registro de decisión para reutilizar, configurar o desarrollar (en blanco)** > > - Trabajo y cómo es un buen resultado: ___ > - Agente candidato y fecha de consulta: ___ > - Información que necesita y quién es responsable de cada fuente: ___ > - Conexiones que el agente aún no tiene: ___ > - Qué puede hacer el agente y qué decide una persona: ___ > - Casos de prueba (normal, información faltante, información contradictoria, fuente no disponible): ___ > - Persona responsable de problemas, cambios, costos y retirada: ___ > - Decisión (reutilizar, configurar o desarrollar): ___ > - Qué debe confirmarse antes de continuar: ___ El registro completo de Maple queda así: > **Registro de decisión para reutilizar, configurar o desarrollar: Maple Freight (ficticio)** > > - **Trabajo y cómo es un buen resultado:** Revisar cada paquete de proveedores, enumerar la evidencia faltante y redactar una solicitud para el proveedor. El agente no aprueba proveedores ni envía mensajes. > - **Agente candidato y fecha de consulta:** El agente existente para incorporación de proveedores, contrastado con su ficha vigente. > - **Información que necesita:** El paquete enviado y la lista de requisitos aprobada, ambos a cargo de compras. El acceso al registro de proveedores sigue sin resolverse. > - **Conexiones que el agente aún no tiene:** Acceso de solo lectura al registro actual de proveedores. > - **Qué puede hacer el agente y qué decide una persona:** El agente compara, enumera y redacta. Una persona revisora de compras aprueba proveedores y envía cada solicitud. > - **Casos de prueba:** Un paquete completo, un certificado faltante, fechas contradictorias y un registro de proveedores al que no se puede acceder. > - **Persona responsable:** La persona responsable del proceso de compras, que nombra a quien lo opera día a día antes del piloto. > - **Decisión:** Configurar, siempre que el registro de proveedores pueda añadirse sin dar al agente nuevas acciones. De lo contrario, detenerse y calcular el costo del desarrollo a medida. > - **Qué debe confirmarse antes de continuar:** Que exista una conexión compatible de solo lectura al registro de proveedores y que supere las cuatro pruebas. La última línea importa tanto como la decisión. Cuando compares opciones, hazlo para la misma carga de trabajo y el mismo período. Incluye pruebas, intentos repetidos, excepciones y mantenimiento, no solo la configuración. ## Comprueba el encaje operativo, no solo la demostración Para cada opción, compara la solicitud real, el resultado aceptable, las fuentes aprobadas, las acciones permitidas, la decisión humana, la vía de excepción y la persona responsable. Revisa cómo gestiona los datos incompletos y los registros contradictorios. Prueba casos representativos, incluidas solicitudes fuera de alcance y fuentes no disponibles. Una demostración pulida no muestra si el agente encaja con tu propia información o tus permisos. Calcula también el trabajo de mantenimiento: actualizaciones de fuentes, credenciales de conexión, tiempo de revisión, cambios de versión, gestión de errores y retirada. Reutilizar puede reducir trabajo de diseño repetido, pero no elimina la necesidad de validar el flujo. El desarrollo a medida añade decisiones que el equipo deberá documentar y mantener. Explora la [biblioteca de agentes](/es/discover), redacta una [descripción concreta del trabajo](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada) y [evalúa el flujo adaptado](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). Para conocer conceptos de configuración de AgentShelf, consulta la [descripción del harness del agente](/es/platform/agent-harness). ### Bibliotecas de agentes de IA: cómo elegir y reutilizar - Route: https://agentshelf.ai/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes - Language: es - Description: Encuentra agentes reutilizables, compara bibliotecas, frameworks y colecciones de prompts, y comprueba el encaje antes de aprobar un agente para tu equipo. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Una biblioteca de agentes de IA reúne agentes que las personas pueden encontrar, evaluar y reutilizar para trabajos definidos. Una entrada útil explica tarea, entradas y salidas, límites operativos y responsabilidad de mantenimiento. Reutilizar empieza por comprobar el encaje, sin suponer que un agente publicado tiene acceso a tus sistemas. ![El descubrimiento público lleva a comprobar el encaje; las propuestas internas pasan por aprobación de responsables antes de su disponibilidad por organización o equipo.](/content/knowledge/visuals/es-ai-agent-library.svg) *Descubrir un candidato y aprobarlo para uso interno son decisiones distintas.* ¿Quieres ver patrones disponibles? [Explora la biblioteca de agentes de AgentShelf](/es/discover) y comprueba si un candidato encaja con tu trabajo. ## Distingue descubrimiento público y reutilización interna Un catálogo público permite descubrir agentes para tareas habituales. Una biblioteca interna establece cuáles ha aprobado una organización o equipo para disponibilidad dentro de su alcance. Responden a preguntas diferentes: «¿Qué podría servir?» y «¿Qué pertenece a nuestra colección aprobada?». La [biblioteca pública de AgentShelf](/es/discover) es un punto de partida. Las bibliotecas de organización y equipo siguen un proceso separado: cualquier persona puede presentar un agente; los responsables de la organización o equipo examinan propuestas y aprueban cuáles se incluyen. Los agentes aprobados de organización están disponibles para toda ella. Los de equipo solo están disponibles para sus integrantes. La pertenencia a la biblioteca describe la disponibilidad del agente. Revisa por separado el acceso a fuentes y sistemas conectados. Encontrar un agente no significa que pueda leer todos los registros que necesita tu tarea. ## Identifica qué tipo de biblioteca estás consultando «Biblioteca» puede referirse a tres cosas distintas, y cada una deja a tu equipo un trabajo diferente. | Punto de partida | Qué obtienes | Qué sigue haciendo tu equipo | | --- | --- | --- | | Biblioteca de agentes | Agentes listos para usar, cada uno creado para un trabajo concreto. | Elegir el trabajo, conectar tu información, probar los resultados y nombrar a una persona responsable. | | Framework de desarrollo | Bloques que el personal de ingeniería usa para crear agentes. | Diseñar, crear, conectar y operar el agente. | | Colección de prompts | Instrucciones y ejemplos para pegar en una herramienta de IA. | Aportar todo lo demás: el modelo, tu información, las herramientas, los permisos y las pruebas. | Las líneas pueden mezclarse. Un agente de biblioteca puede estar creado sobre un framework y todos los agentes contienen instrucciones. Lo importante es cuánto del trabajo ya está hecho cuando empiezas. ## Evalúa primero la biblioteca y luego el agente Una buena biblioteca te indica, en cada ficha, qué trabajo hace el agente, quién lo mantiene, qué información necesita y dónde informar de un problema. Si las fichas dejan abiertas esas preguntas, el tamaño de la colección no ayuda. Cuando tengas un candidato, pruébalo primero con una muestra pequeña de tu propio trabajo. Estas dos fichas públicas muestran cómo cambia la pregunta sobre el encaje según el trabajo: - [Account & Prospect Researcher](/es/discover/account-prospect-researcher) prepara informes de cuentas con fecha y mapas de las personas involucradas. Comprueba que sus fuentes coincidan con las que tu equipo de ventas considera fiables. Un informe bien investigado te informa sobre una cuenta, pero no te dice que esté lista para comprar. - [Discovery & Meeting Copilot](/es/discover/discovery-meeting-copilot) prepara reuniones, recoge lo que se dijo y redacta seguimientos. Comprueba qué notas puedes darle y quién revisa cada seguimiento. Redactar un seguimiento y enviarlo son pasos distintos, y tú decides quién da el segundo. Las fichas cambian con el tiempo, así que revisa la descripción vigente antes de cada nuevo uso. ## Busca un trabajo enfocado «Preparar un informe de reunión con notas aprobadas» es más fácil de evaluar que «gestionar nuestras operaciones». Identifica solicitud, fuentes, resultado, acciones y decisión humana. Aclara requisitos antes de probar trabajo real. | Comprobación | Pregunta que debes responder | | --- | --- | | Tarea | ¿Hace el mismo trabajo que necesitas? | | Entradas | ¿Puedes aportar información autorizada por medios compatibles? | | Resultado | ¿Puede una persona evaluarlo con un criterio claro? | | Autoridad | ¿Coinciden las acciones con tu proceso? | | Operación | ¿Quién gestiona fallos, cambios y retirada? | Un registro interno puede recoger estas respuestas aunque la ficha pública no las incluya. Mantenlo con la persona responsable del flujo para que futuros usuarios entiendan el uso aprobado. ## Decide cuánto está listo el agente Un agente listo para usar ya trae definido el trabajo: qué hacer, en qué orden y cómo es un buen resultado. Tu organización aporta lo demás: su información, sus términos, los sistemas que conecta y las decisiones que toman las personas. Un agente que prepara una nota para una reunión con notas que tú le das puede funcionar desde el primer día. Un agente que actualiza los registros de tus clientes necesita una conexión con ese sistema y tu aprobación para cada tipo de cambio. Eso te deja tres caminos: - **Reutilízalo** cuando el trabajo ya encaja. Pruébalo con tu trabajo y adóptalo. - **Configúralo** cuando las opciones disponibles cubran la diferencia. Ajústalo, pruébalo y adóptalo. - **Crea uno propio** cuando falte una conexión o un control que necesitas y la diferencia justifique el costo continuo de mantener un desarrollo a medida. El [registro de decisión para reutilizar, configurar o desarrollar](/es/conocimiento/casos-de-uso/biblioteca-de-agentes-vs-desarrollo-a-medida#registra-la-decision-de-reutilizar-configurar-o-desarrollar) te guía en la elección y te da una plantilla para conservarla. ## Sigue una decisión ficticia Harbor Studio quiere preparar de forma repetible reuniones de revisión de proyectos. Su coordinadora descubre un candidato que resume notas y redacta una agenda. El resultado encaja, pero aún debe confirmar cómo aportará notas aprobadas y quién revisará el informe. Descubrir un candidato no completa su evaluación. La coordinadora prueba un proyecto ficticio con notas completas, una actualización ausente y fechas contradictorias. Un informe aceptable presenta hechos conocidos, señala la actualización faltante y deja el conflicto a quien dirige la reunión. El agente no debe elegir una fecha ni distribuir el informe antes de la revisión. La coordinadora presenta el agente a la biblioteca del equipo con la descripción del trabajo, pruebas, límites de fuentes y una persona encargada del mantenimiento. El responsable examina la propuesta y decide si se incluye. La aprobación lo hace disponible para integrantes del equipo; la disponibilidad organizativa es una decisión de alcance separada. ## Mantén útil la reutilización cuando cambie el trabajo Reutilizar reduce diseño repetido, pero la responsabilidad operativa permanece. Revisa el agente cuando cambien fuentes, tarea, acciones o audiencia. Define cómo comunicar resultados inadecuados. Un agente útil para una versión del proceso puede dejar de encajar tras una actualización de políticas. Antes de adoptar un agente: - Describe trabajo y resultado aceptable en una frase. - Comprueba fuentes y acciones frente a tus reglas de acceso. - Prueba solicitudes normales, incompletas y fuera de alcance. - Asigna una persona responsable de correcciones y cambios. - Registra audiencia y punto de revisión humana. Consulta [biblioteca o desarrollo a medida](/es/conocimiento/casos-de-uso/biblioteca-de-agentes-vs-desarrollo-a-medida) para decidir entre reutilizar, configurar o desarrollar. Lee [cómo compartir agentes entre equipos](/es/conocimiento/gobernanza-de-ia/compartir-agentes-entre-equipos) para el proceso de aprobación. Los candidatos públicos actuales permanecen en la [biblioteca de agentes](/es/discover). ### IA para la ciberdefensa - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia - Language: es - Description: Usa agentes de IA para investigar la exposición, priorizar y preparar correcciones, contener credenciales expuestas y mantener la cobertura defensiva activa las 24 horas. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Los atacantes ya usan IA para explorar sistemas a cualquier hora. Los agentes de IA permiten que tu equipo defienda al mismo ritmo. Un agente defensivo vigila avisos e inventarios, investiga lo que encuentra, ordena la exposición por prioridad, prepara la corrección, ejecuta los pasos que aprobaste de antemano y comprueba que el resultado se mantiene. Tu equipo de seguridad dedica su tiempo a las pocas decisiones que requieren criterio humano, en vez de recopilar, cotejar y dar seguimiento a todo lo demás. ![Un agente de IA investiga la exposición, prioriza acciones con responsables y verifica el resultado, con controles de permisos independientes](/content/knowledge/visuals/es-cyber-defense.svg) *El agente lleva el ciclo desde el hallazgo hasta el resultado verificado. Los controles de permisos están en los sistemas conectados, no en el modelo.* ## Elige la tarea que necesitas hoy - **Necesitas tu primer agente defensivo.** Empieza por [agentes de IA para la defensa](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia). Indícale al agente qué exposición debe reducir. El agente redacta su propia ficha de tarea a partir de tu inventario y tus políticas para que la apruebes, y después ejecuta un piloto pequeño que puedes revisar por muestreo. - **Tienes sistemas olvidados que siguen funcionando.** Usa [IA para encontrar, corregir y retirar sistemas heredados](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-sistemas-heredados-con-ia). El agente concilia repositorios, despliegues, tareas programadas y credenciales vigentes; después prioriza y prepara el trabajo de corrección, sustitución o retiro. - **Dependes de software o servicios con acceso sensible.** Revisa la [seguridad de la cadena de suministro de software con IA](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software). El agente comprueba cada versión frente a su origen esperado y determina a qué podría acceder cada componente si se viera comprometido. - **Un proveedor informa que tus claves podrían estar expuestas.** Sigue la [respuesta a claves de API de IA expuestas](/es/conocimiento/ciberdefensa-con-ia/claves-api-de-ia-expuestas). El agente rastrea todos los consumidores, prepara los reemplazos, verifica la recuperación aplicación por aplicación y sigue vigilando el uso. - **Un agente ya trabaja durante la noche.** Revisa la [operación defensiva continua](/es/conocimiento/ciberdefensa-con-ia/operar-agentes-defensivos-de-ia). Aprende a confirmar qué cubrió el agente, qué corrigió y qué sigue necesitando a una persona. Para un primer piloto, lee la guía introductoria, elige el flujo que corresponda a tu exposición y usa después la guía de operación antes de ampliar la cobertura. Un incidente urgente con credenciales necesita contención ahora conforme a tu política de incidentes; no debe esperar a un piloto de agentes. ## Deja que el agente lleve el trabajo y reserva las decisiones para las personas La mayor parte del trabajo defensivo es investigación y seguimiento: comparar versiones con avisos, rastrear qué sistemas usan una credencial, redactar una corrección, repetir una comprobación después del cambio y perseguir un escalamiento sin respuesta. Gran parte del trabajo previo es administrativo, y un agente también puede encargarse de él: crear y actualizar el inventario, encontrar un responsable para cada sistema, redactar fichas de tarea y reglas de respuesta, llevar los registros y preparar la revisión operativa. Tu operador da la dirección, el agente hace el trabajo de forma continua y conserva un registro completo mientras avanza. Las personas siguen siendo responsables de una lista breve de decisiones: qué puede hacer el agente, cambios en producción fuera de una política aprobada, decisiones de contención durante un incidente y aceptar que una exposición se ha cerrado. Cada guía nombra esas decisiones, muestra qué prepara el agente para ellas y qué hace por su cuenta. Cada guía también incluye un ejemplo ficticio desarrollado y el formato de registro que lleva el agente. El agente mantiene visibles los datos desconocidos: un activo que no pudo comprobar sigue sin verificar, y una aplicación que no se ha ejecutado desde un cambio de clave sigue sin confirmar. ## Define la autoridad del agente antes de que actúe Da al agente una identidad dedicada, permisos acotados, límites de gasto y un control de detención, todo aplicado por los sistemas conectados y no por instrucciones al modelo. Dentro de esa autoridad actúa sin esperar. Todo lo que quede fuera se convierte en una solicitud preparada para una persona responsable. Antes de depender de ese límite, haz que el agente intente una acción denegada además de las permitidas y confirma que los sistemas la bloquearon. La [ruta de gobernanza](/es/conocimiento/gobernanza-de-ia) explica el modelo general de responsabilidad y revisión. Usa [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y la [lista de revisión de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes) para revisar el propio agente defensivo. La [integración de agentes](/es/conocimiento/integracion-de-agentes) explica cómo conectarlos con los sistemas que aportan evidencia y ejecutan acciones. > **En AgentShelf** > > Estos son flujos que un equipo configura con contexto y herramientas aprobados, una persona responsable y controles en los sistemas conectados. Consulta [límites de confianza](/es/platform/trust-boundaries) y [gobernanza y controles de costos](/es/platform/governance-cost-controls), o [solicita agentes](/es/request-agents) para conversar sobre la primera tarea defensiva. ### Agentes de IA para la defensa: qué hacen y por dónde empezar - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia - Language: es - Description: Elige una primera tarea defensiva para un agente de IA, define la autoridad con la que actúa y comprueba que termina el trabajo con evidencia verificable. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un agente defensivo de IA realiza las tareas rutinarias de seguridad las 24 horas. Lee avisos nuevos, comprueba tu inventario, investiga lo que no puede confirmar, prepara y prueba correcciones, aplica las que aprobaste de antemano y verifica el resultado. Los atacantes ya usan IA para explorar sistemas a cualquier hora, y una defensa que solo funciona en horario laboral deja el resto del día expuesto. Tu equipo decide qué puede hacer el agente antes de que empiece. Los sistemas conectados aplican esa autoridad, incluidos los permisos, los límites de gasto y un control de detención. Cuando un paso queda fuera de ella, el agente entrega a una persona responsable una decisión preparada, no una alerta sin procesar. ![Flujo ilustrativo desde un aviso urgente hasta su comparación con el inventario y una cola de acciones con responsables; los elementos sin verificar se escalan](/content/knowledge/visuals/es-defensive-ai-agents.svg) *El agente convierte un aviso en trabajo terminado, preparado y escalado, para que las personas solo reciban lo que necesitan atender. Todos los nombres de activos, identificadores, versiones, horas y resultados de esta guía son ficticios.* ## Define la tarea antes de elegir las herramientas Indícale al agente qué exposición debe reducir y cómo luce un resultado terminado. El agente convierte esa indicación en una ficha de tarea: lee tu inventario, tus políticas vigentes y los avisos recientes para proponer el alcance de activos, las fuentes y las acciones, y tú apruebas o ajustas el borrador. Los escáneres, inventarios y comprobaciones programadas siguen aportando hechos. El agente conecta esa evidencia, investiga las brechas y lleva el trabajo adelante. La guía para [definir una tarea acotada](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada) cubre el contexto, las acciones y la derivación. Una ficha defensiva también necesita el alcance de los activos, las acciones que el agente puede realizar por su cuenta y las decisiones que debe llevar a una persona. Esas dos últimas las defines tú; el agente solo puede proponerlas. ## Empieza por una de seis tareas defensivas Elige un flujo para configurar o construir. En cada uno, el agente realiza la investigación y el seguimiento: - **Vigilancia de correcciones:** el agente compara cada aviso con tus despliegues, ordena los activos afectados por prioridad, prueba la corrección y la aplica donde la política lo permite. - **Rotación de claves:** el agente encuentra cada aplicación que usa una credencial, prepara el reemplazo y confirma que cada una hizo la transición. - **Comprobación de actualizaciones:** el agente compara cada versión nueva con su origen y versión aprobados, y retiene cualquier cambio inesperado. - **Vigilancia de gasto:** el agente investiga los picos de uso hasta llegar a la clave, cuenta de usuario y carga de trabajo responsables. - **Descubrimiento de sistemas olvidados:** el agente concilia registros de repositorios, despliegues y accesos, y ordena por prioridad los sistemas que nadie tiene asignados. - **Clasificación de incidentes:** el agente reúne registros y alertas en una sola cronología, redacta la actualización y asigna el seguimiento. Si el personal adoptó herramientas no aprobadas, empieza por la [gobernanza de IA no aprobada](/es/conocimiento/gobernanza-de-ia/gestion-del-uso-de-ia-no-aprobado). ## Elige la primera tarea por su exposición y utilidad Pide primero al agente que analice las opciones. Puede informar qué sistemas accesibles contienen acceso sensible, qué fuentes puede leer de forma fiable y cuántos hallazgos abiertos atendería cada tarea. Después tú valoras cuánto le costaría al negocio una exposición sin resolver y qué acciones te sientes cómodo aprobando de antemano. Es fácil celebrar otras mil vulnerabilidades encontradas. El valor está en saber cuáles diez corregir primero, corregirlas y demostrar que las correcciones funcionaron. Un agente puede hacer las tres cosas cuando la tarea está acotada y los resultados pueden comprobarse contra registros de confianza. [Elegir un caso de uso](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso) ofrece el método de selección más amplio. ## Sigue un aviso a través del flujo A las 02:10, la ejecución `fic-0210` recoge el aviso `ADV-FIC-104`, que señala las versiones 4.2.0 a 4.2.3 de un componente de servidor. El agente comprueba cuatro despliegues aprobados y lleva cada uno hasta el punto más avanzado que permite su autoridad: - **`wiki-int`** está afectado, pero es solo interno. Está cubierto por la política de correcciones preaprobada del equipo, así que el agente lo corrige y verifica el resultado. - **`portal-prod`** está afectado y atiende a clientes. El agente prueba la corrección en el entorno de pruebas y la programa para la aprobación de su responsable. - **`billing-api`** no está afectado. - **`reports-02`** no se puede comprobar. El agente intenta una segunda fuente aprobada y después escala el caso con su diagnóstico. > **Ficha de tarea defensiva: vigilancia de correcciones (ilustrativa)** > > - **Exposición:** Despliegues afectados por un aviso urgente. > - **Inicio:** Nuevo aviso de una fuente aprobada. > - **Alcance de activos:** Despliegues aprobados del componente indicado. > - **Fuentes aprobadas:** Fuente de avisos, inventario de despliegues, manifiestos de paquetes y registros de accesibilidad. > - **Identidad de herramienta:** Identidad de servicio dedicada para estas lecturas y acciones. > - **Acciones que el agente realiza por su cuenta:** Comparar versiones, ordenar activos por prioridad, probar correcciones en el entorno de pruebas, abrir y actualizar elementos de corrección y aplicar correcciones a sistemas internos durante la ventana de mantenimiento aprobada. Después de cada cambio, vuelve a comprobar la versión desplegada. > - **Decisiones que lleva a una persona:** Cambios en producción para sistemas orientados al cliente, además de cualquier apagado, reinicio o cambio fuera de la ventana. > - **Límite aplicado:** El sistema de despliegue permite operaciones de corrección solo en hosts con la etiqueta `internal` durante la ventana, y deniega operaciones de detención y reinicio. > - **Responsable de decidir:** Responsable de plataforma de cada activo. > - **Condición de escalamiento:** Una consulta que falla en todas las fuentes aprobadas, evidencia contradictoria o un cambio solicitado fuera de la política. > - **Finalización:** Cada activo está corregido y verificado, confirmado como no afectado, en espera de una decisión preparada o escalado con un diagnóstico. > **Cola de acciones de la ejecución `fic-0210` (ilustrativa)** > > - **`wiki-int`:** Versión 4.2.2, comprobada a las 02:12. Es solo interno, por lo que aplica la política preaprobada. El agente lo corrige en la ventana de las 02:30 y vuelve a leer la versión 4.2.4 a las 02:41. Exposición: cerrada, con evidencia adjunta. > - **`portal-prod`:** Versión 4.2.1, comprobada a las 02:13. Es accesible desde internet y las sesiones y datos de clientes están en riesgo: prioridad 1. El agente aplica la corrección del proveedor en el entorno de pruebas y supera la suite de regresión a las 02:34. Abre `REM-881` con el aviso, la versión, la evidencia de accesibilidad y los resultados de las pruebas, y propone la ventana de las 06:00. En espera de: aprobación del responsable del portal. > - **`billing-api`:** Versión 4.3.0, comprobada a las 02:14, fuera del rango afectado. No afectado; no requiere acción. > - **`reports-02`:** La consulta al inventario vence dos veces a las 02:15. El agente lee en su lugar el manifiesto de paquetes del último registro de despliegue, pero ese registro tiene 40 días. Marca el activo como sin verificar y lo escala al operador de plataforma con ambos fallos y la fecha del registro desactualizado. No cuenta como cubierto. A las 06:00, el responsable del portal aprueba `REM-881`. El agente despliega la corrección, vuelve a leer la versión 4.2.4 a las 06:09, repite la comprobación de accesibilidad y cierra el elemento. El responsable revisó un cambio preparado en lugar de investigar cuatro sistemas durante la noche. El agente redacta una ficha con este formato para cada tarea nueva, y tú la apruebas. Usa la versión en blanco para definir lo que esperas que complete: > **Ficha de tarea defensiva (en blanco)** > > - Exposición: ___ > - Inicio: ___ > - Alcance de activos: ___ > - Fuentes aprobadas: ___ > - Identidad de herramienta: ___ > - Acciones que el agente realiza por su cuenta: ___ > - Decisiones que lleva a una persona: ___ > - Límite aplicado (sistemas que lo aplican): ___ > - Responsable de decidir: ___ > - Condición de escalamiento: ___ > - Finalización: ___ ## Decide qué puede hacer el agente Esta es la parte que queda en manos de las personas. Da al agente una identidad dedicada que puedas limitar y revocar. Después decide qué acciones realiza por su cuenta y cuáles prepara para una persona. Plasma esa división en los sistemas mismos, no solo en las instrucciones del agente. Luego el agente puede ejecutar las pruebas de límites en ambos lados. En una prueba de límites después de `fic-0210`, una persona revisora pide al flujo que detenga `portal-prod` usando la identidad del agente. El sistema de despliegue devuelve una denegación de permisos y el despliegue no cambia. El agente registra la denegación y crea el escalamiento `ESC-104` a las 02:20 con la solicitud adjunta. El acceso al inventario más allá del componente asignado todavía no se ha probado, así que la ampliación espera esa prueba. El agente documenta cada prueba con la política prevista, la conducta observada y el alcance sin probar por separado, siguiendo la [lista de revisión de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes). Usa [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y [revisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) para diseñar la aplicación de controles y el escalamiento. ## Prueba el resultado antes de ampliar la cobertura La ejecución y la prueba de límites ficticias producen estos resultados: | Caso | Esperado | Observado | Resultado | |---|---|---|---| | `wiki-int` afectado y preaprobado | Corregido en la ventana, versión verificada | Versión 4.2.4 leída a las 02:41 | Cumple; cerrado | | `portal-prod` afectado y orientado al cliente | Corrección probada, cambio preparado, sin despliegue no aprobado | `REM-881` con resultados de pruebas; desplegado tras la aprobación | Cumple; cerrado a las 06:09 | | `billing-api` no afectado | Resultado registrado con evidencia | Comprobación de versión, 02:14 | Cumple | | `reports-02` no disponible | Segunda fuente probada, sin verificar, escalado | Registro desactualizado marcado; operador asignado | Cumple | | Detener `portal-prod` | Denegación del sistema, escalamiento y ningún cambio | Permiso denegado; `ESC-104`; sin cambios | Cumple | Considera fallida cualquier conclusión sin respaldo, afirmación de cobertura falsa o cambio en producción fuera de la política. Pide al agente que compare sus resultados con tus escáneres y comprobaciones existentes e informe dónde se solapan y qué omitió cada uno. [Evaluar un agente](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) separa las puntuaciones de resultado, proceso, límites y recuperación. Para el piloto, deja que el agente ejecute una ficha con un inventario pequeño y revisa a mano una muestra de sus conclusiones. Después dirige al agente hacia [sistemas heredados](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-sistemas-heredados-con-ia) o [software y servicios de confianza](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software). > **En AgentShelf** > > Configura un flujo defensivo con contexto y herramientas aprobados, una persona responsable y límites aplicados en los sistemas conectados. Consulta la [plataforma](/es/platform) y los [límites de confianza](/es/platform/trust-boundaries), o [solicita agentes](/es/request-agents) para conversar sobre una primera tarea defensiva. ### Cómo responder a claves de API de IA expuestas - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/claves-api-de-ia-expuestas - Language: es - Description: Usa un agente de IA para rastrear cada consumidor de una clave expuesta, preparar la contención, migrar las aplicaciones a un reemplazo y verificar la recuperación con un registro de respuesta completo. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Cuando un proveedor avisa que las claves de API guardadas en su servicio podrían haberse expuesto, asume que otra persona puede usarlas hasta que el emisor las revoque. Borrar la copia guardada por el proveedor no revoca nada. Sigue las instrucciones vigentes para incidentes del emisor. Un agente puede encargarse de gran parte de esta respuesta. Rastrea cada aplicación y tarea que usa la clave, comprueba a qué puede acceder y vigila el uso en el proveedor. También prepara el reemplazo, migra a los consumidores y confirma que cada uno se recuperó. La persona responsable de la respuesta toma la decisión de contención. El agente se asegura de que esa decisión sea rápida, informada y se ejecute por completo. Todos los avisos, identificadores, horarios y resultados de esta guía son ficticios. Los registros contienen solo referencias de claves, nunca valores secretos. ## Deja que el agente establezca la credencial afectada En cuanto llegue el aviso, el agente abre un registro de respuesta. Registra el aviso, la cuenta del proveedor, el identificador de clave, el período de exposición declarado y la persona responsable de la respuesta, y mantiene separados los hechos confirmados, las afirmaciones del proveedor y las preguntas abiertas a medida que cambia la investigación. Una clave de proveedor, una credencial exclusiva de puerta de enlace y un inicio de sesión de aplicación tienen emisores y rutas de revocación distintos. El agente abre un registro por credencial para que cada revocación y recuperación se cierre con su propia evidencia. ## Deja que el agente rastree el acceso y los sistemas dependientes El agente busca en los registros de configuración y despliegue aprobados cada aplicación, tarea, paso de construcción e integración que use la clave. Eso incluye consumidores indirectos que la leen de un almacén compartido. En este ejemplo encuentra dos: `app-prod` y la tarea programada `nightly-report`. Nadie trabaja directamente con una tarea nocturna, por lo que es fácil omitirla; y ese es precisamente el consumidor que falla en silencio tras una rotación apresurada. El agente confirma después con el emisor el alcance concedido de la clave y los recursos accesibles. Algunas claves solo permiten solicitudes de modelos; otras acceden a archivos almacenados o recursos de cuenta. Busca en los registros del proveedor y de la aplicación credenciales o sesiones creadas mediante el acceso expuesto y abre un elemento de contención para cada una que encuentre. Todo lo que no pueda confirmar queda marcado como sin verificar, con una persona responsable. El agente trabaja con referencias de configuración y metadatos. Los valores secretos quedan fuera de sus entradas y salidas. La [seguridad de la cadena de suministro de software con IA](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software) explica cómo mantener este inventario actualizado antes de que un incidente imponga la pregunta. ## Decide la contención y luego deja que el agente la ejecute La rotación rutinaria y el compromiso sospechado siguen rutas distintas. Los pasos siguientes son un modelo operativo; las instrucciones del emisor y el incidente determinan la secuencia exacta. **La rotación rutinaria** es un reemplazo programado sin exposición sospechada. El agente puede ejecutarla de principio a fin conforme a una política preaprobada. Crea un reemplazo restringido, actualiza y verifica cada consumidor y luego revoca la clave antigua en el emisor. **El compromiso sospechado** requiere contención rápida, incluso sin uso indebido visible. Los registros de uso tardíos o vacíos no descartan una clave posiblemente filtrada. La persona responsable de la respuesta elige entre dos opciones: - Revocar o deshabilitar la clave de inmediato y aceptar que algunos consumidores se interrumpirán. - Hacer un reemplazo controlado con un solapamiento breve, cuando las instrucciones del emisor lo permitan. El trabajo del agente es lograr que esa decisión sea rápida y esté bien informada. No espera a contar con un inventario completo de consumidores antes de pedirla. Antes de distribuir cualquier reemplazo, el agente determina dónde ocurrió el compromiso. Comprueba el almacén de secretos y los registros de construcción y despliegue, y documenta lo que revisó. Distribuye claves nuevas solo por un almacén y una ruta de despliegue de confianza, nunca de vuelta a la configuración del proveedor hasta que la persona responsable acepte la evidencia de contención del proveedor. Si tu propio host o entorno de construcción pudiera estar comprometido, sigue primero las instrucciones de limpieza o reconstrucción del aviso. La falta de evidencia de intrusión no demuestra por sí sola que un entorno esté limpio. En este ejemplo, el agente encuentra durante la noche un uso de aproximadamente tres veces el nivel habitual, sin actividad coincidente de ninguno de los consumidores. Para las 09:20 ha preparado dos elementos: la clave de reemplazo `key-prod-015` en el almacén de secretos revisado por el equipo y la solicitud de aprobación `APR-1042`. La solicitud nombra ambos consumidores y lo que interrumpiría la revocación inmediata, además del tiempo de recuperación esperado. La persona responsable aprueba la revocación inmediata a las 09:47. La revocación es una acción condicionada a aprobación. La identidad del agente puede revocar la clave en el emisor solo después de que la persona responsable apruebe `APR-1042`, y el emisor aplica esa regla. La [revisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) y la [derivación entre agentes y sistemas](/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas) explican la confirmación de recepción y el escalamiento cuando una aprobación tarda en llegar. ![Respuesta ilustrativa que muestra la contención en el emisor, el reemplazo en un entorno de confianza y la verificación de cada consumidor, con uno aún pendiente](/content/knowledge/visuals/es-exposed-ai-api-keys.svg) *La revocación por sí sola no completa la respuesta. La recuperación permanece abierta hasta confirmar el último consumidor con su reemplazo.* ## Deja que el agente vigile el uso en el proveedor El agente revisa el uso y la facturación del proveedor durante el período de exposición y continúa comprobándolos después. Asigna las solicitudes sin explicación para investigarlas y registra las brechas en los datos, cuándo deberían estar disponibles los registros completos y cuándo volverá a comprobarlos. La evidencia de la puerta de enlace cubre solo el tráfico que pasa por ella. Una clave de proveedor robada puede eludir tanto la puerta de enlace como su presupuesto, por lo que el agente consulta el uso en el propio proveedor y aplica restricciones y alertas del lado del proveedor cuando existen. La [gestión de presupuestos de LLM](/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm) explica la cobertura de rutas de solicitudes admitidas. ## Deja que el agente verifique cada consumidor y la credencial antigua El agente conserva como evidencia la confirmación de revocación del emisor. Después confirma que cada consumidor se ejecuta con el reemplazo, incluidas las tareas programadas. Una tarea que no se ha ejecutado desde el cambio permanece sin verificar hasta que el agente comprueba su siguiente ejecución. > **Registro de respuesta a credenciales (ilustrativo)** > > - **Exposición:** Aviso `SUP-2026-014`, día 0 a las 09:12. Proveedor: cuenta de producción A. Clave `key-prod-014`, solo solicitudes de modelos, sin acceso administrativo en el registro del emisor; puede generar uso facturable. El proveedor indica que la exposición duró desde dos días antes del día 0 hasta el aviso; se registra como una afirmación del proveedor. Consumidores encontrados por el agente: `app-prod`, `nightly-report`. No se encontraron credenciales ni sesiones relacionadas hasta las 11:00; comprobación completa programada. Responsable: responsable de respuesta R. > - **Contención:** El agente señaló uso sin explicación a tres veces el nivel habitual y envió `APR-1042` a las 09:20 con el impacto de cada opción. La persona responsable eligió la revocación inmediata a las 09:47. El agente revocó la clave a las 09:49 y el emisor confirmó la revocación a las 09:50. El agente revisó el almacén de secretos y los registros de construcción y despliegue sin hallar evidencia de intrusión; se registra el alcance de la revisión. El reemplazo se distribuyó solo por esa ruta. La configuración del proveedor se excluyó hasta contar con su evidencia de contención, y la copia del proveedor se eliminó después como tarea de limpieza. > - **Recuperación:** `app-prod` cambió a `key-prod-015` a las 09:56 y las comprobaciones del agente se aprobaron. El agente actualizó la configuración de `nightly-report` a las 10:05, pero el programador no permite ejecuciones bajo demanda, así que la tarea sigue sin verificar hasta su próxima ejecución a las 01:30. El uso está parcialmente revisado; se esperan registros completos el día 1 y la comprobación se programó. Estado: recuperación incompleta; el agente comprueba la ejecución de las 01:30 y los registros de uso del día 1. El agente lleva un registro con este formato por credencial y asigna una persona responsable a cada dato desconocido. Usa la versión en blanco para definir lo que esperas que informe: > **Registro de respuesta a credenciales (en blanco)** > > - **Exposición:** Aviso y hora ___ · Cuenta de proveedor e ID de clave ___ · Alcance concedido y recursos ___ · Período y origen de la exposición ___ · Consumidores ___ · Credenciales o sesiones relacionadas ___ · Responsable ___ > - **Contención:** Rotación rutinaria o compromiso sospechado ___ · Decisión, motivo, responsable y hora ___ · Cualquier solapamiento (plazo, restricciones, responsable de respuesta) ___ · Comprobaciones del entorno de confianza y ruta de distribución ___ · Aprobación ___ · Hora de revocación y evidencia del emisor ___ > - **Recuperación:** Cada consumidor (ID de reemplazo, aplicado a las, verificación) ___ · Período de uso, brechas y nueva comprobación ___ · Trabajo sin resolver ___ · Estado ___ ## Mantén el registro de respuesta hasta completar el trabajo El agente sigue cada paso como preparado, aprobado, ejecutado y verificado. Cierra el registro solo cuando todos los consumidores estén verificados, la revisión final de uso haya terminado y todo acceso derivado tenga una decisión. Los elementos abiertos reciben una fecha de seguimiento, y el agente los mantiene en movimiento. Antes de que llegue el próximo aviso, haz que el agente construya y mantenga una lista del emisor, la persona responsable de respuesta, los consumidores, la ruta de revocación y la ruta de reemplazo de confianza de cada clave. Así, la primera hora de un incidente se convierte en una decisión en vez de una búsqueda. > **En AgentShelf** > > Configura un agente para rastrear consumidores, preparar y ejecutar pasos aprobados y mantener el registro. Las personas responsables o las políticas preaprobadas autorizan la revocación. Los presupuestos de AgentShelf cubren rutas admitidas, no el uso directo de una clave robada. Consulta [gobernanza y controles de costos](/es/platform/governance-cost-controls), o [solicita agentes](/es/request-agents) para conversar sobre la respuesta a credenciales. ### Cómo operar agentes defensivos de IA las 24 horas - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/operar-agentes-defensivos-de-ia - Language: es - Description: Mantén a un agente de IA defensivo trabajando durante la noche, confirma qué cubrió y corrigió, detecta las comprobaciones que omitió y asegúrate de que los pocos elementos que necesitan una persona la reciban. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un agente defensivo cubre el turno de noche. Por la mañana debería haber comprobado cada activo pendiente, corregido lo que la política permite, recuperado sus propias comprobaciones fallidas cuando puede y dado seguimiento a cualquier escalamiento sin respuesta. El trabajo del operador es confirmar que lo hizo, y eso debería tomar minutos, no toda la mañana. El operador también atiende la breve lista de elementos que realmente necesitan una persona. Esta guía sigue durante una noche la tarea de vigilancia de correcciones de [agentes de IA para la defensa](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia). Todos los identificadores, recuentos, horas y resultados de esta guía son ficticios. ## Define qué significa cobertura continua para esta tarea Pide al agente que proponga el plan de cobertura: qué activos están pendientes, qué fuentes lee, con qué frecuencia comprueba y qué vigencia debe tener la evidencia. Basa la propuesta en el inventario, los hallazgos anteriores y la rapidez con la que tu equipo puede actuar. El operador aprueba el plan y nombra a quien opera la tarea. Las comprobaciones cada hora solo ayudan si el agente puede actuar sobre los hallazgos o contactar a alguien que pueda hacerlo. Cuando el agente informa «nueve de diez comprobados», ese recuento abarca los activos conocidos que estaban pendientes en el período. Un activo que falta en el inventario queda por completo fuera de ese recuento, por lo que la integridad del inventario necesita su propia comprobación, que el agente también puede ejecutar. ## Vigila al agente además de los sistemas que comprueba El agente registra cada lectura exitosa, fallo, resultado vencido y señal ausente para cada fuente y activo. Un programador que informa éxito todavía puede dejar la cobertura incompleta, por lo que el propio registro del agente es el que cuenta. Un monitor independiente vigila al agente desde fuera. Comprueba que cada ejecución haya comenzado, terminado y entregado su registro, y eleva los fallos de fuentes y los escalamientos sin respuesta. Mantén ese monitor y los registros que protege fuera del alcance del agente para que no pueda desactivarlos ni reescribirlos. En el ejemplo, el monitor `mon-01` informa dos fallos de consulta a las 03:12 y 03:13. La [observabilidad de agentes de IA](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes) abarca los registros disponibles y la telemetría incompleta. Los registros ausentes dejan la cobertura como desconocida, nunca como asumida. ![Ciclo operativo ilustrativo que muestra activos pendientes, comprobados, desconocidos y escalados, observado por un monitor independiente](/content/knowledge/visuals/es-operate-defensive-ai-agents.svg) *El monitor está fuera del agente, de modo que un fallo silencioso sigue apareciendo como una brecha, no como un aprobado.* ## Deja que el agente se recupere de sus propios fallos Da al agente reglas claras sobre qué hacer cuando falla una comprobación y déjalo actuar conforme a ellas sin esperar. Los reintentos limitados son seguros para las lecturas. Si una acción anterior quizá ya tuvo efecto, el agente confirma su resultado antes de repetirla. [Fallos y recuperación de agentes de IA](/es/conocimiento/gobernanza-de-ia/fallos-de-agentes-y-recuperacion) abarca las decisiones de reintento, corrección, detención y derivación. En el ejemplo, después de que fallen sus reintentos, el agente cambia `assets-09` a una segunda fuente aprobada y obtiene una versión vigente a las 03:40. `reports-02` no tiene una segunda fuente, por lo que el agente lo marca como sin verificar y envía el escalamiento `ESC-210` al operador de guardia a las 04:12. El agente redacta las reglas para casos más difíciles a partir de tu política de incidentes: fallo persistente de una fuente, pérdida de permisos, evidencia contradictoria y solicitudes fuera de su autoridad. El operador las aprueba. Dos decisiones quedan en manos de las personas: quién puede pausar la tarea y el plazo para un segundo contacto, de modo que el agente dé seguimiento a un escalamiento sin respuesta en vez de esperar en silencio. El agente puede comprobar que la pausa funciona. ## Deja que el agente convierta hallazgos en trabajo con responsable El agente relaciona la evidencia de identidad, despliegue, construcción y aplicación en una sola investigación cuando los registros sustentan la conexión, y conserva cada fuente y hora. Asigna a cada hallazgo una identidad estable para que una repetición actualice el elemento existente en vez de abrir uno nuevo. También sigue cada etapa por separado: nuevo, repetido, atendido, asignado, confirmado y verificado como resuelto. El agente no puede cerrar un escalamiento que creó. Solo la persona que lo recibe puede confirmar su recepción, y el sistema de tickets aplica esa regla. La [derivación entre agentes y sistemas](/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas) explica los estados de finalización del lado receptor. ## Mide la cobertura y los resultados útiles El agente elabora por su cuenta la revisión operativa. Incluye los activos pendientes con evidencia vigente, los desconocidos, los hallazgos aceptados y rechazados, el trabajo que completó sin una persona, la corrección verificada, el costo operativo y el tiempo del operador. El operador lee la revisión y decide qué cambiar. El tiempo del operador debería disminuir a medida que el agente asume más trabajo. El agente también ejecuta casos de repetición de forma programada para detectar omisiones. Estas pruebas de repetición usan entradas controladas y son independientes de la ejecución nocturna. En `R-03`, la exportación del alcance deja fuera deliberadamente `reports-02`, mientras que el inventario esperado aún lo incluye: | Caso de repetición | Esperado | Observado | Resultado | |---|---|---|---| | `R-01`: afectado, dentro del alcance | Elemento con responsable y evidencia | Elemento abierto con evidencia | Cumple | | `R-02`: no afectado, dentro del alcance | Aprobado con evidencia de versión | Aprobado registrado con evidencia | Cumple | | `R-03`: `reports-02` se omite de la exportación y se mantiene en el inventario esperado | Marcar el activo pendiente ausente como sin verificar | Ninguna entrada ni alerta de omisión | Falla; el agente prepara una comprobación de conciliación de inventario, la persona responsable de la exportación la aprueba y el caso se repite | La ejecución nocturna sí intentó consultar `reports-02`. La repetición plantea otra pregunta: ¿notaría el flujo si un activo desapareciera de su entrada? Conserva ambos resultados y no combines sus recuentos de cobertura. El agente también toma una muestra de sus propios cierres. De 48 elementos cerrados en los siete días anteriores, vuelve a comprobar 12 frente a las versiones desplegadas vigentes. Uno carecía de evidencia de la versión desplegada, por lo que el agente lo reabrió. Informa siempre juntos la población, la muestra, el período y el resultado. > **Registro operativo de agente defensivo: día 0, de 00:00 a 06:00 (ilustrativo)** > > - **Cobertura:** > - Tarea `patch-watch v12`; el alcance es de 10 activos conocidos pendientes, comprobados cada hora, con evidencia de menos de 2 horas de antigüedad. El monitor `mon-01` vio que las 6 ejecuciones comenzaron, terminaron y escribieron registros. > - Ocho activos tienen lecturas vigentes de inventario y versión entre 05:40 y 05:47. > - `assets-09` falló a las 03:13 y de nuevo después de dos reintentos. El agente cambió de fuente y se recuperó a las 03:40. > - `reports-02` tuvo su último éxito a las 02:58 y quedó vencido a las 04:58. Todas las comprobaciones desde las 03:12 han fallado y no existe una segunda fuente. > - A las 06:00: 9 vigentes, 1 sin verificar. > - **Hallazgos y acciones:** Sin hallazgos nuevos. Repetición `FIND-311` en `crm-sync`: el agente renovó la evidencia de versión a las 05:42, actualizó `REM-905` y vinculó el despliegue `dep-5521` y la evidencia de identidad en `INV-88`. Acciones completadas por el agente: un cambio de fuente, una actualización de elemento y una reapertura de muestra de cierres. > - **Respuesta:** El agente envió `ESC-210` por `reports-02` a las 04:12. Seguía sin confirmación a las 06:00, por lo que el agente envió el segundo contacto según lo programado a las 06:30 y el operador de guardia O. confirmó la recepción a las 06:34. No se necesitó corrección durante la noche. Trabajo abierto: restablecer la consulta de `reports-02`. El agente escribe un registro con este formato al final de cada período. Usa la versión en blanco para definir lo que esperas que informe: > **Registro operativo de agente defensivo (en blanco)** > > - **Cobertura:** Tarea y configuración ___ · Período ___ · Alcance pendiente ___ · Cadencia y vigencia ___ · Monitor independiente ___ · Última lectura exitosa por fuente y activo ___ · Recuperado por el agente ___ · Vigentes ___ · Sin verificar (activo, fallo, hora, responsable) ___ > - **Hallazgos y acciones:** IDs y estados nuevos y repetidos ___ · Evidencia vinculada ___ · Acciones completadas por el agente ___ · Resultados de repetición separados ___ · Muestra de cierres, población, período y resultado ___ > - **Respuesta:** IDs de escalamiento, horas de envío y confirmación ___ · Seguimientos enviados ___ · Operador ___ · Trabajo verificado ___ · Trabajo abierto y responsables ___ Resumen de operación (ilustrativo; las ventanas de repetición y muestreo son independientes de la ejecución nocturna): | Medida | Resultado | |---|---| | Cobertura nocturna | 9 de 10 vigentes; 1 sin verificar | | Recuperado por el agente | 1 de 2 consultas fallidas | | Hallazgos | 1 repetido confirmado; 0 rechazados | | Respuesta | `ESC-210` confirmado a las 06:34 tras el seguimiento del agente | | Muestra de cierres, últimos 7 días | 12 de 48 comprobados de nuevo; 1 reabierto | | Repetición independiente | `R-03` falló; corrección preparada por el agente y aprobada | | Costo y esfuerzo | Costo de ejecución registrado; 8 minutos de operador | ## Revisa los cambios antes de ampliar el alcance Antes de cualquier cambio, el agente compara conclusiones, omisiones, uso de recursos y tiempo del operador con la referencia anterior. Cuando cambian modelos, herramientas, fuentes, permisos o activos, repite el flujo completo y las subtareas afectadas e informa la diferencia para su aprobación. Consulta [gestión de cambios de agentes](/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes) y la [lista de gobernanza](/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza). Cierra cualquier brecha de cobertura o respuesta antes de aprobar más alcance para el agente. > **En AgentShelf** > > Comprueba qué registros de actividad, errores, uso y costo ofrecen tus rutas admitidas; la cobertura depende de la configuración. Combina los registros disponibles con supervisión independiente y una persona responsable que responda. Consulta [gobernanza y controles de costos](/es/platform/governance-cost-controls), o [solicita agentes](/es/request-agents) para conversar sobre operación defensiva. ### Seguridad de la cadena de suministro de software con IA - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software - Language: es - Description: Usa un agente de IA para comprobar cada lanzamiento frente a su origen esperado, mapear a qué puede acceder cada componente de confianza y retener cambios inesperados antes de que lleguen a producción. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) El mayor riesgo de seguridad quizá no sea el código que escribe tu equipo. Puede estar en el código y los servicios a los que tu equipo confía credenciales, datos y autoridad para actualizar, y la adopción de IA ha sumado muchos: puertas de enlace, proveedores de modelos, conectores y servidores de herramientas. Todos publican actualizaciones, y revisar manualmente cada lanzamiento no da abasto. Un agente de IA puede hacer esa comprobación de forma continua. Mapea de qué dependes, compara cada lanzamiento nuevo con su origen y construcción esperados, determina a qué podría acceder cada componente si se viera comprometido y detiene un lanzamiento que no coincide antes de que llegue a producción. Las personas responsables de los componentes toman las decisiones de confianza que el agente no puede tomar. Todos los nombres de componentes, identificadores, versiones, horas y hallazgos de esta guía son ficticios. Las referencias de credenciales no contienen valores secretos. ## Deja que el agente mapee en qué confía el flujo Dirige el agente a los manifiestos de paquetes, registros de imágenes, configuración de despliegue y registros de proveedores. Enumera paquetes, imágenes, puertas de enlace, conectores, habilidades de agentes, servidores de herramientas, servicios alojados y proveedores de modelos. Para cada uno, registra quién puede ver datos, guardar credenciales, publicar actualizaciones o cambiar el comportamiento de forma remota. Incluye a los proveedores que almacenan tus secretos, aunque ninguno de sus programas se ejecute en tus servidores. Cada componente necesita una persona responsable de negocio. El agente propone una a partir del historial de cambios, los registros de despliegue y la facturación, y le pide a la persona probable que lo confirme. La [lista de revisión de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes) abarca una evaluación más amplia de agentes; esta guía cubre las dependencias que los rodean. ## Deja que el agente rastree cada lanzamiento hasta el artefacto que ejecutas Para cada actualización, el agente sigue la cadena desde el repositorio de origen hasta la construcción, el publicador, el artefacto descargado y el despliegue. Registra el origen, el publicador, la versión y resumen criptográfico desplegado aprobados. Las etiquetas pueden apuntar a bytes distintos con el tiempo, así que el agente fija su comparación a los resúmenes. Inspeccionar el origen e identificar el artefacto desplegado responden preguntas diferentes, y el agente registra ambas. ![Cadena ilustrativa desde el origen y el lanzamiento hasta el artefacto desplegado y el acceso concedido, con un punto de retención para cambios inesperados](/content/knowledge/visuals/es-ai-supply-chain-security.svg) *La comprobación se ejecuta antes de conceder acceso a producción, de modo que un lanzamiento que no coincide se detiene en el punto de retención.* ## Comprueba la procedencia y entiende sus límites Cuando tus herramientas lo admitan, el agente verifica firmas y certificaciones de construcción frente a identidades aprobadas y compara huellas de artefactos. Fija los despliegues a resúmenes criptográficos en vez de etiquetas que pueden cambiar. Una huella coincidente identifica bytes. No demuestra que se hayan construido a partir del origen aprobado, y una firma válida puede provenir de un proceso ascendente comprometido. Por eso el agente comprueba conjuntamente la identidad firmante, el origen y la evidencia de construcción. La falta de procedencia se registra como una brecha abierta, nunca como un aprobado. ## Deja que el agente mapee a qué puede acceder cada componente Para cada componente, el agente registra identificadores de credenciales, datos que puede leer, acciones permitidas, cuentas conectadas y sistemas accesibles. Responde la pregunta que haría un atacante: ¿qué podría leer, cambiar, enviar o desbloquear este componente si se viera comprometido? Después prepara cómo limitar o revocar cada concesión y cuánto tardaría. Una puerta de enlace puede guardar claves de proveedores y leer el tráfico de solicitudes. Un conector puede escribir en registros empresariales. Un acceso amplio puede hacer que un componente conocido sea más prioritario incluso cuando sus comprobaciones de procedencia se aprueban. Usa [revisión de herramientas y acceso a datos](/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos) y [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) para comprobaciones por operación. La [comparación entre puerta de enlace LLM y plataforma de agentes de IA](/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes) separa el enrutamiento y el alcance de credenciales de la ejecución del agente. ## Retén el cambio inesperado y luego investígalo La puerta de enlace candidata 2.8.0 llega a las 11:02. Su huella coincide con el lanzamiento publicado, pero su registro de lanzamiento nombra `gateway-releases-mirror` en vez del origen aprobado `gateway-releases`. La canalización de despliegue promueve un lanzamiento solo después de que se aprueba la comprobación de verificación del agente, por lo que el fallo del agente retiene la ejecución `pipe-7731` a las 11:04. Producción sigue en 2.7.4. El agente no puede promover un lanzamiento ni anular la regla; solo puede negarse a aprobarlo. El agente investiga entonces la retención: - La certificación de construcción del espejo nombra una identidad de constructor que no figura en la lista aprobada. - El origen aprobado todavía no tiene un lanzamiento 2.8.0. - El candidato solicita un permiso nuevo: acceso saliente a un host que no está en la lista. Pone en cuarentena al candidato y envía a la persona responsable de la plataforma un hallazgo con la evidencia adjunta. La persona responsable tiene una sola pregunta que responder: ¿es el espejo un origen legítimo? El agente ya ha determinado por qué el lanzamiento no debería ejecutarse hasta recibir esa respuesta. El agente también propone las demás condiciones de retención a partir de tu historial de lanzamientos y, una vez que la persona responsable las aprueba, las aplica igual cada vez: un publicador inesperado, una identidad firmante ausente o diferente, un resumen que no coincide o permisos nuevos. > **Ficha de confianza: revisión del lanzamiento de puerta de enlace (ilustrativa)** > > - **Procedencia:** Componente `gw-prod`, que enruta solicitudes de modelos de agentes internos. Responsable: equipo de plataforma. Origen aprobado `gateway-releases`; publicador registrado en la política de lanzamientos. Candidato 2.8.0, resumen `sha256:9f2c…41aa`, recibido a las 11:02. Desplegado 2.7.4, resumen `sha256:51b0…07d3`, sin cambios a las 11:06. La huella coincide; el origen es un espejo no aprobado; la identidad de constructor no se reconoce; no hay lanzamiento coincidente en el origen aprobado. Resúmenes abreviados para mostrarlos. > - **Acceso:** Referencias de credenciales `cred-gw-p1`, `cred-gw-p2`, `cred-gw-p3`. Lee tráfico de solicitudes y guarda claves de proveedores; no escribe en registros empresariales. El candidato agrega acceso saliente a un host no listado. Consecuencia del compromiso: exposición de credenciales e interceptación de solicitudes. > - **Qué hizo el agente:** Falló su comprobación de verificación, que retuvo `pipe-7731` a las 11:04. Puso al candidato en cuarentena, investigó el espejo y envió un hallazgo a la persona responsable con evidencia. > - **Decisión para la persona responsable:** Si `gateway-releases-mirror` es un origen legítimo. Hasta entonces el candidato permanece en cuarentena. > **Ficha de confianza: acceso de proveedor alojado (ilustrativa)** > > - **Procedencia:** Host contratado `host-sup-a`, que ejecuta `app-internal-01` y `app-internal-02`. Responsable: equipo de plataforma. El proveedor administra el despliegue. El agente comprobó la configuración exportada `cfg-118` el 2026-10-20 y revisó 90 días de avisos de cambios del proveedor; ninguno informó cambios en el almacenamiento de secretos. Estos registros no verifican de forma independiente el proceso de construcción del proveedor. > - **Acceso:** Referencias `secret-app01-db`, `secret-app01-api`, `secret-app02-api`. El proveedor almacena los secretos y los inyecta durante la ejecución. Alcance: la base de datos y las cuentas de proveedor que esos secretos desbloquean. > - **Qué hizo el agente:** Mapeó los tres secretos a sus emisores y consumidores. Ensayó el reemplazo desde el emisor de `secret-app02-api` en el entorno de preparación; el reemplazo tardó 12 minutos de principio a fin. > - **Decisión para la persona responsable:** Ninguna por ahora. Prioridad alta por el alcance; el agente repite la revisión cuando el proveedor envíe su próximo aviso de cambio. El agente lleva una ficha con este formato por componente. Usa la versión en blanco para definir lo que esperas que informe: > **Ficha de confianza de software y proveedores (en blanco)** > > - **Procedencia:** Componente ___ · Uso de negocio ___ · Responsable ___ · Origen y publicador aprobados ___ · Versión y resumen candidatos ___ · Versión y resumen desplegados, comprobados a las ___ · Evidencia de firma, certificación y huella ___ > - **Acceso:** IDs de credenciales ___ · Alcance de datos y acciones ___ · Sistemas accesibles ___ · Consecuencia del compromiso ___ · Cómo limitar o revocar ___ > - **Qué hizo el agente:** Comprobaciones ejecutadas ___ · Discrepancias encontradas ___ · Retenciones y el sistema que las aplica ___ · Resultados de la investigación ___ > - **Decisión para la persona responsable:** Pregunta ___ · Prioridad y fundamento ___ · Aún sin verificar ___ · Estado ___ ## Prepárate para el compromiso y la recuperación Para los componentes importantes, el agente mantiene registrados la persona responsable de respuesta, los consumidores dependientes y la fuente de orientación vigente para la corrección. Si un proveedor anuncia un compromiso, el agente conserva la identidad y los registros del artefacto, retiene lanzamientos posteriores y obtiene el aviso específico. Luego gestiona cada credencial expuesta mediante la contención en el emisor y la recuperación del consumidor. Quitar un paquete por sí solo no establece la recuperación, porque los cambios persistentes pueden requerir limpieza adicional o una reconstrucción. Empieza con una puerta de enlace o un conector y haz que el agente lo mapee desde el origen y el proveedor hasta el artefacto y el acceso. [Agentes defensivos de IA](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) muestra cómo configurar la comprobación de actualizaciones como una tarea comprobable. > **En AgentShelf** > > Configura un agente para recopilar evidencia de lanzamientos, investigar discrepancias e informar a la persona responsable del componente. Tus sistemas de despliegue deben aplicar la retención. Consulta [límites de confianza](/es/platform/trust-boundaries), o [solicita agentes](/es/request-agents) para conversar sobre un flujo de revisión de proveedores. ### Usa IA para encontrar, corregir y retirar sistemas heredados - Route: https://agentshelf.ai/es/conocimiento/ciberdefensa-con-ia/seguridad-de-sistemas-heredados-con-ia - Language: es - Description: Deja que un agente de IA encuentre sistemas olvidados que siguen funcionando, priorice lo que necesita atención, prepare la corrección y verifique cada decisión de actualizar, sustituir o retirar. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un sistema olvidado puede seguir atendiendo a clientes y conservando credenciales que funcionan mucho después de que su repositorio se archivó. Encontrar estos sistemas antes requería semanas de cotejos manuales, y ese es precisamente el trabajo que un agente de IA hace bien. El agente concilia registros de repositorios, despliegues, dependencias y accesos, determina qué sistemas importan, prepara la corrección o migración y retira lo que ya no se necesita. Tu equipo decide hasta dónde debe llegar cada reparación. Todos los nombres de activos, identificadores, fechas y hallazgos de esta guía son ficticios. ## Conecta el repositorio con el sistema en ejecución Ningún registro cuenta toda la historia: - Un repositorio muestra el código fuente y el historial de mantenimiento. - Un despliegue muestra qué se ejecuta realmente. - Una tarea programada muestra trabajo que ocurre sin que nadie lo supervise. - Una credencial concede un acceso que puede sobrevivir a los otros tres. Archivar el código fuente no detiene un despliegue ni revoca una credencial. El agente enlaza estos registros para cada sistema. Un sistema solo cuenta como retirado cuando el despliegue, el programador de tareas y el emisor de credenciales lo confirman. Todo lo que el agente no pueda relacionar se mantiene en la lista con un responsable y un siguiente paso. ![Relación ilustrativa entre un repositorio archivado, un despliegue activo y accesos vigentes que lleva a una decisión de actualizar, sustituir o retirar](/content/knowledge/visuals/es-ai-legacy-system-security.svg) *Un repositorio archivado todavía puede tener detrás un despliegue activo y accesos vigentes. El agente sigue los tres hasta una sola decisión.* ## Deja que el agente reúna el inventario Da al agente acceso de lectura a los metadatos de repositorios, los despliegues y tareas programadas, los manifiestos de dependencias y los metadatos de credenciales, y pídele el inventario. El agente lo crea y lo mantiene por su cuenta. Fecha cada dato, registra su fuente y mantiene visibles los despliegues sin relación y los responsables desconocidos, en vez de descartarlos. No incluyas nunca los valores secretos en las entradas ni en los registros del agente. Trabaja con identificadores de credenciales, responsables y fechas, y confirma los permisos efectivos con el servicio emisor o la política de IAM, porque la descripción de un gestor de secretos puede estar incompleta. Consulta la guía para [revisar herramientas y acceso a datos](/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos). El agente trata los comentarios del código fuente, las dependencias y los archivos recuperados como entradas no confiables. Analiza el código sin ejecutarlo cuando es posible. Cuando una comprobación debe ejecutar código, lo hace en un entorno aislado y con una identidad acotada. ## Deja que el agente encuentre la exposición que requiere atención El agente busca combinaciones peligrosas: un servicio vulnerable que acepta tráfico de internet, datos sensibles a los que puede acceder su proceso o credenciales que abren otros sistemas. Trata cada posible ruta de ataque como una hipótesis y después la comprueba: - ¿La versión desplegada coincide con el aviso? - ¿El código vulnerable es accesible? - ¿Qué permiten realmente las credenciales? Un entorno de ejecución sin soporte no demuestra por sí solo una explotación, y un análisis limpio solo cubre lo que el escáner alcanzó y reconoció. El agente registra ambos límites. ## Prioriza qué corregir, sustituir o retirar El agente ordena los sistemas por uso de negocio, accesibilidad, acceso sensible, dependencias y consecuencias, y propone uno de tres resultados: - **Corregir** un sistema necesario que tiene una corrección con soporte. - **Sustituir** uno que no puede mantenerse de forma segura. - **Retirar** uno cuya necesidad de negocio terminó. Compara un portal público para clientes con un prototipo interno archivado. Ambos repositorios han estado inactivos durante más de un año, pero el portal todavía atiende a clientes y exporta datos cada noche. El agente le da prioridad y realiza la investigación que, de otro modo, tendría que hacer el responsable. > **Registro de exposición y decisión: `portal-prod-03` (ilustrativo)** > > - **Identidad:** Repositorio `portal-web`, archivado en 2024-06, último cambio en 2024-05. Despliegue activo y accesible desde internet, último despliegue en 2025-11. Uso de negocio: inicios de sesión y páginas de cuentas de clientes. La tarea `nightly-export` se ejecuta a diario a las 01:30 hacia un almacén de informes. > - **Lo que confirmó el agente (2026-10-20):** > - El inicio de sesión público es accesible. > - El entorno de ejecución pertenece a una línea de versiones fuera del soporte regular. La última corrección del proveedor para esa línea no cubre el aviso `ADV-PRT-22`, que afecta la versión desplegada. > - En el entorno de pruebas, la ruta vulnerable es accesible sin iniciar sesión. > - Los registros del emisor muestran que `cred-portal-app-01` puede leer la tabla de clientes. > - `cred-export-02` escribe en el almacén de informes y un consumidor, `bi-dash`, lee ese almacén. > - El responsable anterior salió en 2025-03. > - **Lo que preparó el agente:** > - Una rama de migración que lleva el portal a un entorno de ejecución con soporte, con actualizaciones de dependencias y pruebas superadas en el entorno de pruebas. > - Una regla temporal que bloquea la ruta vulnerable en el perímetro. > - Un plan de migración para `nightly-export` que mantiene funcionando `bi-dash`. > - **Decisión para el responsable:** Aprobar ahora la regla de perímetro y elegir después entre sustituir el portal con la rama preparada o retirarlo junto con el responsable de negocio. Responsable provisional: líder de plataforma, propuesto por el agente a partir del historial de despliegues y confirmado el 2026-10-20. Estado: abierto, decisión preparada. > **Registro de exposición y decisión: `prototype-07` (ilustrativo)** > > - **Identidad:** Repositorio archivado; uso de negocio terminado, confirmado con la persona responsable de producto el 2026-10-19. > - **Lo que confirmó el agente (2026-10-20):** La comprobación de despliegue `DEP-707` y la comprobación del programador `JOB-707` no encuentran despliegues ni tareas activos en las cuentas revisadas. Ningún consumidor ha leído la credencial `cred-proto-07` en 90 días. > - **Lo que hizo el agente:** La credencial cumple todas las condiciones de la política de retiro preaprobada, así que el agente la revoca en el emisor y obtiene el comprobante `REV-707` (2026-10-20). Después enlaza ese comprobante en el catálogo de secretos y archiva el registro del activo. > - **Resultado:** Retiro verificado para las cuentas revisadas mediante evidencia de despliegue, tareas y emisor. No requiere acción de una persona. El agente lleva un registro con este formato para cada sistema que encuentra. Usa la versión en blanco para definir lo que esperas que informe: > **Registro de exposición y decisión (en blanco)** > > - **Identidad:** Activo ___ · Estado del repositorio y última actividad ___ · Estado del despliegue y último despliegue ___ · Entorno de ejecución y dependencias ___ · Tareas programadas ___ · Uso de negocio ___ > - **Lo que confirmó el agente:** Accesibilidad ___ · Identificadores de credenciales (nunca valores) ___ · Permisos del emisor o IAM ___ · Ruta de ataque probada ___ · Incertidumbre restante ___ · Fuentes y fechas ___ > - **Lo que preparó o hizo el agente:** Corrección, migración o control temporal ___ · Acciones realizadas conforme a la política ___ · Evidencia ___ > - **Decisión para el responsable:** Corregir, sustituir o retirar ___ · Responsable ___ · Alcance revisado ___ · Estado ___ ## Deja que el agente realice el trabajo elegido La IA reduce el costo de la reparación en sí. El agente puede explicar código desconocido, mapear dependencias, redactar la corrección o migración, escribir pruebas y ejecutarlas en el entorno de pruebas. Aplica ese esfuerzo al principio de la lista priorizada, no a lo que sea más fácil de corregir. Decide de antemano qué cambios realiza el agente por su cuenta; el agente puede redactar esa política a partir de la lista priorizada, pero la aprueba una persona. El emisor y los sistemas de despliegue la aplican. En el ejemplo, la identidad del agente puede revocar una credencial solo cuando está etiquetada para retiro y no tiene consumidores recientes. Por eso el agente pudo retirar `prototype-07` por su cuenta, mientras que `cred-export-02` espera la migración de `bi-dash` y la decisión de una persona responsable. Si una credencial podría estar comprometida, conténla ahora conforme a tu política de incidentes en lugar de esperar a la limpieza. Los cambios del propio agente siguen la [gestión de cambios](/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes). ## Cierra la exposición con evidencia Después de cada cambio, el agente vuelve a comprobar el resultado desplegado y su efecto sobre la exposición. Para un retiro, conserva juntas la evidencia del despliegue, el programador de tareas y el emisor. Eliminar una entrada de un gestor de secretos no demuestra la revocación, así que el agente consulta al emisor. Los responsables faltantes o las dependencias desconocidas siguen abiertos, y el agente da seguimiento hasta que alguien responda. Dirige al agente a una aplicación y haz que concilie los registros de ese sistema de principio a fin. Si todavía no existe una ficha de tarea, empieza por [agentes de IA para la defensa](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) y usa la [lista de gobernanza](/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza) para definir la responsabilidad del programa y las fechas de revisión. > **En AgentShelf** > > Configura un agente para reunir registros aprobados, preparar reparaciones y dar seguimiento a los elementos sin resolver. Las reparaciones y los retiros en producción aún necesitan pruebas y la autoridad que aplican tus sistemas. Consulta [gobernanza y controles de costos](/es/platform/governance-cost-controls), o [solicita agentes](/es/request-agents) para conversar sobre la limpieza. ### Conocimiento, herramientas y conexiones - Route: https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas - Language: es - Description: Decide qué fuentes, métodos, capacidades y conexiones empresariales necesita un agente de IA para realizar una tarea concreta. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un buen diseño distingue lo que el agente debería saber de lo que debería poder hacer. Un documento de políticas puede aportar información para una respuesta; una herramienta puede solicitar o realizar una acción. Dar acceso a una cosa no define las reglas de la otra. ![Documentos, instrucciones, acciones y sistemas conectados a una misma tarea.](/content/knowledge/visuals/es-knowledge-tools.svg) Esta ruta está dirigida a los equipos que eligen los recursos de un flujo de trabajo con agentes, incluidas las personas responsables de las fuentes y de los sistemas conectados. ## Empieza por distinguir cada recurso El conocimiento aporta información útil para la tarea; las habilidades orientan un método reutilizable; las herramientas ofrecen acciones definidas; y las conexiones dan a las herramientas una vía hacia sistemas externos. Trata el acceso a la información y la autoridad para actuar como decisiones separadas. Lee [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones) para consultar una guía comparativa detallada y revisa los [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) antes de habilitar una capacidad. ## Prepara un inventario de recursos Enumera los documentos, las instrucciones reutilizables, las acciones disponibles y los sistemas conectados que necesita la tarea. Para cada uno, anota: - **Su propósito:** qué parte de la tarea respalda. - **Quién responde por su exactitud o disponibilidad.** - **Sus límites de acceso:** quién puede ver la información y si una capacidad puede leer, crear un borrador o cambiar un registro externo. - **Cómo detectarás** una fuente obsoleta, una solicitud fallida o un resultado incompleto. - **Cómo retirarás el acceso** si cambia la tarea o la persona responsable. Por ejemplo, un asistente para consultas de servicio podría necesitar descripciones aprobadas de los servicios y una forma de recoger la pregunta de un visitante. Eso no requiere automáticamente acceso a notas comerciales internas ni permiso para modificar registros de clientes. Evalúa cada capacidad adicional frente a la [descripción concreta del trabajo](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). ## Evalúa también los recursos Incluye en el piloto documentos contradictorios, conexiones no disponibles y acciones denegadas. Define una respuesta útil para cada fallo, como pedir una aclaración, señalar la información que falta o transferir la tarea a una persona. Consulta la [guía de evaluación](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para conocer el proceso del piloto, el [glosario](/es/conocimiento/glosario) para repasar la terminología y la [descripción de conocimiento y herramientas de AgentShelf](/es/platform/knowledge-tools-automation) para obtener detalles del producto. ## Todas las guías de este tema - [Conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones): El conocimiento aporta información, las habilidades guían el trabajo, las herramientas realizan acciones y las conexiones les dan acceso a otros sistemas. - [Cómo fundamentar un agente de IA en el contexto empresarial aprobado](/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial): Asigna al agente una tarea acotada, fuentes vigentes con responsables identificados y una respuesta probada ante evidencia faltante o contradictoria. - [Conecta un agente de IA con los sistemas de negocio](/es/conocimiento/conocimiento-y-herramientas/conectar-agentes-con-sistemas-de-negocio): Elige una integración distinguiendo el protocolo, la conexión, la identidad y los permisos; un protocolo por sí solo no concede acceso a un sistema de negocio. ### Conecta un agente de IA con los sistemas de negocio - Route: https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/conectar-agentes-con-sistemas-de-negocio - Language: es - Description: Elige una integración distinguiendo el protocolo, la conexión, la identidad y los permisos; un protocolo por sí solo no concede acceso a un sistema de negocio. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Conecta un agente con un sistema de negocio solo después de definir qué datos y acciones necesita la tarea. Una API define cómo intercambian solicitudes los sistemas; MCP estandariza la conexión de aplicaciones de IA con servidores que ofrecen contexto y herramientas; los permisos deciden qué usuario o agente puede utilizar una operación. Estas decisiones se complementan, pero no son intercambiables. ![Documentos, instrucciones, acciones y sistemas conectados a una tarea acotada.](/content/knowledge/visuals/es-knowledge-tools.svg) *Las fuentes, las instrucciones, las acciones y los sistemas respaldan una tarea acotada.* ## Distingue el protocolo, la conexión y el permiso Cada capa responde a una pregunta distinta: | Capa | Qué define | Qué no decide | | --- | --- | --- | | API | Qué solicitud y respuesta acepta un sistema de negocio. | Si ese usuario o agente debe tener permiso para realizar la solicitud. | | MCP | Cómo se conecta una aplicación de IA con un servidor que ofrece recursos, instrucciones o herramientas. | Si los datos o acciones del servidor están autorizados para un flujo de trabajo concreto. | | Política del agente | Qué capacidades públicas, herramientas y límites expone actualmente un agente externo. | Si el agente puede utilizar cualquier API o servidor MCP. | MCP puede facilitar el descubrimiento y uso de la interfaz de un servidor entre aplicaciones compatibles. El protocolo no hace cumplir por sí solo los permisos de negocio de tu organización; cada implementación debe aplicar sus propios controles de acceso y consentimiento. La documentación actual del SDK de agentes externos indica que las integraciones consultan la política pública y las capacidades negociadas del agente. No documenta un conector MCP general, así que no des por sentado que añadir un servidor MCP lo habilita en este SDK. Una conexión es la ruta configurada entre un flujo de trabajo de agente y un sistema. Incluye a la persona responsable, una identidad, la operación expuesta y las reglas que aplica el sistema. Una consulta de solo lectura y un punto de acceso para actualizar datos pueden usar la misma API, pero tienen consecuencias distintas y deberían contar con autorizaciones separadas. ## Analiza una solicitud acotada Considera un centro de servicio que recibe esta solicitud: «Consulta el estado de inspección del activo A-104». El sistema de registro contiene una entrada de inspección marcada como completada el 25 de septiembre. La primera tarea consiste en devolver ese registro; no hace falta modificar la inspección ni programar mantenimiento. Comprueba el límite de identidad y permisos en cada paso: 1. **Verifica a quien hace la solicitud.** Autentica a la persona mediante el inicio de sesión habitual de la aplicación; no te bases solo en una identidad enviada desde el navegador. Quien administra el centro de servicio decide qué personas pueden consultar el estado. 2. **Nombra la fuente y a su responsable.** El sistema de mantenimiento es la fuente del estado de inspección y su responsable confirma qué operación aprobada puede leerlo. 3. **Identifica la identidad de conexión.** Registra qué identidad de usuario o servicio hará la llamada al sistema y confirma su acceso real con quien administra ese sistema. 4. **Limita los permisos del sistema.** Para esta solicitud, permite leer el estado de inspección de los activos autorizados. Mantén fuera de esta conexión las actualizaciones y la programación de mantenimiento, salvo aprobación independiente. 5. **Comprueba la capacidad del agente.** En un agente externo, consulta su política pública vigente y los detalles de sus herramientas de dominio antes de mostrar una acción. Confirma la clase de efecto secundario de la operación y si requiere aprobación; el nombre de un protocolo por sí solo no concede acceso. 6. **Verifica el resultado y cuándo detenerse.** Devuelve el estado y la fecha registrados. Remite a la persona responsable un registro faltante o contradictorio en vez de deducir el resultado. > **Consulta completada (ejemplo ilustrativo)**\ > **Solicitud:** Consultar el estado de inspección del activo A-104.\ > **Identidad solicitante:** Una persona del centro de servicio con sesión iniciada y autorizada por quien administra el equipo.\ > **Identidad de conexión:** Una identidad de integración aprobada y de solo lectura puede consultar el estado de inspección.\ > **Capacidad del agente:** La política vigente expone la consulta; la interfaz no muestra una acción de actualización.\ > **Resultado de la fuente:** Inspección marcada como completada el 25 de septiembre.\ > **Acción permitida:** Leer el estado; no modificar el registro.\ > **Respuesta:** «La última inspección figura como completada el 25 de septiembre». Este ejemplo supone que la consulta de solo lectura ya está autorizada en el sistema. No implica que el SDK proporcione esta operación ni que MCP conceda acceso a los datos de mantenimiento. ## Prueba los límites antes de ampliar el acceso Prueba una solicitud permitida, otra de una persona sin acceso, una ficha faltante y un registro con fechas contradictorias. Confirma que los casos denegados o inciertos no revelen datos ajenos. Si una operación cambia un registro, identifica quién la aprueba y qué evidencia confirma que el cambio se completó. Para entender las diferencias básicas, consulta [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones). Revisa [permisos y límites de los agentes de IA](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y luego la guía del SDK sobre [políticas y capacidades](/docs/es/policy-and-capabilities) para conocer las capacidades que un agente expone realmente. ### Conocimiento, habilidades, herramientas y conexiones - Route: https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones - Language: es - Description: El conocimiento aporta información, las habilidades guían el trabajo, las herramientas realizan acciones y las conexiones les dan acceso a otros sistemas. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) El conocimiento aporta hechos, una habilidad describe un procedimiento, una herramienta realiza una operación concreta y una conexión ofrece una vía autorizada a un sistema. Estas piezas trabajan juntas, pero cumplen funciones distintas. Northstar Supplies envía un expediente de incorporación de proveedores. El equipo de Compras solicita una revisión con la lista vigente para incorporar proveedores y la ficha actual del proveedor, que señale cualquier evidencia faltante y prepare un borrador de solicitud de documentos para revisión. En este ejemplo ficticio, la lista exige un certificado de seguro vigente, pero el expediente no lo incluye. Una persona debe revisar y enviar la solicitud; el agente no aprueba al proveedor. ## Sigue una solicitud a través de las cuatro partes - **Conocimiento:** La lista vigente para incorporar proveedores indica que se necesita un certificado de seguro vigente. El equipo de Compras es responsable de mantenerla actualizada. - **Habilidad:** El procedimiento compara el expediente de incorporación y la ficha actual del proveedor con la lista; identifica la evidencia faltante, redacta una solicitud y se detiene para que una persona la revise. Por sí solo, no concede acceso. - **Herramienta:** Una consulta de solo lectura del registro del proveedor obtiene los datos vigentes para compararlos. No puede aprobar al proveedor ni enviar una solicitud. - **Conexión:** Una conexión autorizada y de solo lectura permite que la consulta acceda al sistema de registros de proveedores. Su acceso se limita a los permisos concedidos por el equipo de Compras. Resultado ilustrativo de los registros ficticios de Northstar Supplies: > **Borrador de revisión: Northstar Supplies** > > - **Hallazgo:** Falta un certificado de seguro vigente en el expediente de incorporación. > - **Solicitud en borrador:** «Envíe un certificado de seguro vigente para que el equipo de Compras pueda continuar con la revisión». > - **Estado:** El proveedor no está aprobado; una persona debe revisar y enviar la solicitud. Si no se puede leer la ficha o el expediente del proveedor, o si las fuentes se contradicen, el agente debe indicar qué no pudo verificar y dejar la decisión en manos del equipo de Compras. ![El conocimiento, las habilidades, las herramientas y las conexiones respaldan una tarea de incorporación de proveedores, en lugar de formar una secuencia de pasos.](/content/knowledge/visuals/es-knowledge-skills-tools-and-connections.svg) *Política, procedimiento, consulta y acceso autorizado.* ## Elige solo lo que necesita la tarea Empieza con una tarea pequeña y elige los recursos necesarios para producir un resultado útil: | Si la tarea necesita... | Elige... | Comprueba antes de usarlo | | --- | --- | --- | | Hechos o registros aprobados | Conocimiento | Nombra la fuente y a su responsable; confirma el alcance y la vigencia. | | Un método repetible y condiciones para detenerse | Una habilidad | Explicita los pasos y qué hacer si falta evidencia o hay contradicciones. | | Una operación concreta, como una consulta o una actualización | Una herramienta | Define la acción permitida, sus efectos secundarios y si requiere aprobación. | | Una vía hacia otro sistema | Una conexión | Confirma la identidad que accede y los permisos reales concedidos por quien administra el sistema. | Más documentos no siempre hacen que el conocimiento sea más útil, y una instrucción que pide actuar con cuidado no sustituye a un permiso del sistema. Prueba qué ocurre con datos faltantes, desactualizados e inesperados. Cuando sea posible, comparte solo la información necesaria entre los pasos y usa campos estructurados; estas prácticas reducen algunos riesgos, pero no garantizan que el resultado sea correcto. Para obtener contexto específico del producto, consulta el [resumen sobre conocimiento, herramientas y automatización](/es/platform/knowledge-tools-automation). Continúa con [revisión humana y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes), [permisos y límites de los agentes de IA](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y [evaluación de agentes de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). ### Fundamenta un agente de IA con contexto empresarial aprobado - Route: https://agentshelf.ai/es/conocimiento/conocimiento-y-herramientas/fundamentar-agentes-con-contexto-empresarial - Language: es - Description: Asigna al agente una tarea acotada, fuentes vigentes con responsables identificados y una respuesta probada ante evidencia faltante o contradictoria. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Fundamenta un agente de IA definiendo la respuesta que debe producir, dándole un conjunto reducido de fuentes vigentes con responsables claros y probando cómo gestiona las lagunas y los desacuerdos. La recuperación puede relacionar una respuesta con la información proporcionada; no demuestra que las fuentes estén completas ni que la respuesta sea correcta. Ejemplo ficticio: Cedarline Property Services pide: «Indica a nuestra persona responsable de mantenimiento si el estándar de servicio aprobado incluye visitas fuera del horario habitual para la sede de Brookfield. Prepara una respuesta breve. No prometas una hora de visita». El resultado solicitado es un borrador con fuentes, no una reserva. ![Conocimiento, un método reutilizable, herramientas y conexiones respaldan una misma tarea.](/content/knowledge/visuals/es-knowledge-skills-tools-and-connections.svg) *El diagrama distingue los tipos de recursos que respaldan una respuesta fundamentada.* ## Define qué debe responder el agente Convierte la solicitud en una pregunta que se pueda comprobar: ¿el estándar de servicio vigente incluye visitas fuera del horario habitual y el calendario de Brookfield señala alguna excepción? Indica qué cuenta como respuesta, qué puede hacer el agente y dónde debe detenerse. En este ejemplo, puede leer los documentos de servicio aprobados y redactar una respuesta. No puede inventar disponibilidad, programar una visita ni cambiar la política. Este límite es importante porque «usa nuestro conocimiento» es una instrucción demasiado amplia. Un equipo puede tener muchos documentos con distintos públicos, fechas y niveles de autoridad. Dar acceso a todos los archivos dificulta saber cuál respalda la respuesta y si corresponde usarlo. ## Elige fuentes que se puedan mantener En Cedarline, el conjunto ficticio de fuentes aprobadas es deliberadamente pequeño: | Fuente aprobada | Responsable | Autoridad y alcance | Evidencia de vigencia | Motivo para revisarla | | --- | --- | --- | --- | --- | | Estándar de servicio fuera del horario habitual | Responsable de operaciones | Define las reglas generales: permite visitas fuera de horario por incidentes urgentes; los trabajos habituales se programan en horario laboral. | Vigente desde el 1 de julio de 2026; confirma que siga siendo la versión aprobada. | Un cambio de política o el vencimiento de la fecha de revisión del responsable. | | Calendario de la sede de Brookfield | Coordinación regional | Indica excepciones específicas de la sede; en este ejemplo no incluye ninguna para Brookfield. | Revisado en septiembre de 2026; confirma que no haya un calendario aprobado más reciente. | Un cambio en el calendario o la sede, o la fecha de su próxima revisión. | El estándar rige el servicio; el calendario puede limitar su disponibilidad en una sede concreta. Ninguna de las dos fuentes autoriza una cita específica. Una página pública o un archivo privado no es oficial solo porque aparezca en una búsqueda. Anota el público y la versión de cada fuente, decide cuál de las fuentes aprobadas prevalece si discrepan y separa el material vigente de copias archivadas y borradores. ## Facilita la revisión de los fragmentos recuperados Organiza la información de modo que una consulta pueda devolver un fragmento pertinente con la identidad de su fuente. Según el sistema, pueden servir los encabezados claros, los documentos centrados en un tema, los metadatos de sede o fecha de vigencia y los filtros que limitan el alcance de la búsqueda. Son opciones de diseño; no todas las plataformas de agentes las ofrecen. Pide al agente que conserve suficientes datos de la fuente para que una persona pueda comprobar la afirmación: el nombre y la fecha del documento, su sección o un pasaje directo, si la interfaz lo permite. Separa la fuente de la redacción generada. Si la búsqueda no devuelve un pasaje útil, la respuesta debería indicar qué no pudo confirmar y pedir ayuda o dirigir la consulta a la persona responsable de la fuente. ## Prueba preguntas reales y situaciones de fallo Prepara preguntas representativas antes de poner el flujo en marcha. Incluye una pregunta directa, una paráfrasis, una sede ambigua, una fuente obsoleta, documentos contradictorios y una pregunta fuera del alcance aprobado. Para cada caso, indica la respuesta esperada o la reacción segura y la evidencia que debería respaldarla. Una búsqueda exitosa en un ejemplo no demuestra un buen desempeño en todo el conjunto. En Cedarline, el conjunto de prueba debería incluir Brookfield y otra sede con horarios distintos. Incluye un caso con un calendario archivado y otro que solicite una hora exacta de llegada. Según las fuentes indicadas, el borrador resultante sería: > **Respuesta para la persona responsable de mantenimiento:** «El estándar de servicio permite visitas fuera del horario habitual por incidentes urgentes. Los trabajos habituales se programan en horario laboral y el calendario de Brookfield no incluye excepciones adicionales. No se ha confirmado una hora de visita». El agente comparó el estándar vigente con el calendario de la sede y redactó una respuesta acotada. No reservó ni envió a nadie. Comprueba que los pasajes citados respalden cada oración. ## Define cómo actuar ante cambios y desacuerdos Identifica quién actualiza cada fuente y qué situación activa una revisión: un cambio de política, una sede nueva, una fecha de revisión vencida o preguntas recurrentes que las fuentes no puedan responder. Define qué hacer si hay un conflicto. El agente debería señalarlo y dirigirlo a una persona responsable; no debería resolver una cuestión de política adivinando o mezclando versiones. Empieza por [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones) y después revisa los [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). Usa la [evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para probar las búsquedas y respuestas a medida que cambia el conjunto de fuentes. ### Diseño de agentes y flujos de trabajo - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes - Language: es - Description: Elige un caso de uso acotado, define el trabajo del agente y diseña la revisión humana antes de iniciar un piloto. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Empieza el diseño de un agente por el trabajo que quieres mejorar. Define a quién ayuda, qué datos puede utilizar, qué resultado debe producir y qué decisiones siguen correspondiendo a las personas. ![Una solicitud amplia se convierte en una descripción concreta con el inicio, los datos de entrada, la tarea, el resultado y la transferencia.](/content/knowledge/visuals/es-agent-design.svg) Si estás a cargo del proceso o desarrollas el agente, usa estas guías para preparar una prueba piloto. Describe la tarea con suficiente precisión para que otra persona pueda comprobar si el agente la completó. ## Define el trabajo en tres pasos 1. [Elige un caso de uso útil](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso). Compara las tareas candidatas por su utilidad, la evidencia disponible, su reversibilidad y el esfuerzo necesario para evaluar los resultados. 2. [Define el trabajo concreto del agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Especifica el inicio, los datos de entrada, la tarea, el resultado, la transferencia, los límites y las condiciones para darla por terminada. 3. [Diseña aprobaciones y transferencias](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes). Decide qué requiere revisión humana, qué información recibe quien revisa y qué ocurre mientras se espera la revisión. ## Facilita la inspección del resultado Para preparar un informe de una reunión semanal de proyecto, define un trabajo que se pueda probar: - **Inicio:** La persona responsable del proyecto solicita la preparación para la próxima reunión. - **Datos aprobados:** La agenda vigente, el registro del proyecto y las notas aprobadas de reuniones anteriores. - **Borrador:** Un resumen de la agenda, preguntas pendientes y enlaces a las fuentes de las afirmaciones comprobables. - **Criterio de éxito:** Cada afirmación comprobable cuenta con una fuente enlazada que la respalda; las suposiciones quedan marcadas para revisión. - **Criterio de detención:** Si falta la agenda o las fuentes discrepan, el agente señala el faltante o el conflicto, deriva la consulta a la persona responsable del proyecto y espera una aclaración, sin elegir una versión ni inferir un compromiso. Usa el caso habitual y el caso de detención como ejemplos de evaluación distintos. La guía para [definir el trabajo concreto del agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada) amplía estos campos; la [guía de evaluación](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) ayuda a probarlos. ## Pasa del diseño al piloto Usa la guía de [conocimiento, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas) para decidir qué necesita el flujo de trabajo. Después, sigue la [guía de evaluación antes de producción](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para probar el diseño. Para conocer los conceptos de configuración de AgentShelf, consulta la página sobre el [harness del agente](/es/platform/agent-harness). ## Todas las guías de este tema - [Cómo elegir un caso de uso para un agente de IA](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso): Elige un trabajo con una persona responsable, pasos variables, información aprobada, un resultado revisable y una señal útil de éxito. - [Define un trabajo acotado para un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada): Una definición útil del trabajo de un agente nombra el desencadenante, la persona usuaria, el resultado, el contexto aprobado, las acciones permitidas, las condiciones para detenerse y la derivación a una persona. - [Revisión humana para agentes de IA](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes): La revisión humana aporta más valor en puntos de decisión claros, donde una aprobación, una corrección o un escalamiento pueden cambiar el resultado. - [Diseña traspasos de trabajo entre agentes y sistemas](/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas): Mantén pendiente un traspaso entre sistemas hasta que el sistema receptor confirme la solicitud e indique qué ocurrió después. - [Usa salidas estructuradas para que los resultados del agente se puedan revisar](/es/conocimiento/diseno-de-agentes/resultados-estructurados): Define los campos obligatorios, los valores permitidos, las referencias de evidencia y las condiciones de revisión; luego valida la estructura y los hechos. ### Define un trabajo acotado para un agente - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada - Language: es - Description: Una definición útil del trabajo de un agente nombra el desencadenante, la persona usuaria, el resultado, el contexto aprobado, las acciones permitidas, las condiciones para detenerse y la derivación a una persona. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) La definición del trabajo de un agente especifica a quién ayuda el sistema, qué resultado prepara, qué información y acciones tiene permitidas y cuándo interviene una persona. Convierte un objetivo amplio en un trabajo que se puede revisar y probar. ![Campos de una definición de trabajo, con iconos para persona responsable, usuario, desencadenante, objetivo, entradas, acciones, resultado y condición de parada, que conducen a un borrador y una revisión humana.](/content/knowledge/visuals/es-define-a-focused-agent-job.svg) *Definición ilustrativa del trabajo de incorporación de Northstar.* ## Define el resultado con un ejemplo **Solicitud de ejemplo:** «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». En este ejemplo ficticio de compras, la persona revisora necesita un resumen de integridad. El agente puede consultar el expediente presentado, la lista vigente para incorporar proveedores y la ficha actual del proveedor. La lista exige un certificado de seguro vigente que no aparece en el expediente. Describe brevemente el trabajo: > Cuando llegue el expediente de incorporación de Northstar Supplies, ayuda a quien lo revisa en compras a comprobar si está completo. Usa el expediente presentado, la lista de incorporación vigente y la ficha actual del proveedor para identificar información faltante o contradictoria. Redacta una solicitud cuando haga falta y deriva el caso antes de que se envíe un mensaje o se tome una decisión sobre el proveedor. El borrador resultante podría decir: > **Northstar Supplies — revisión de incorporación (borrador)** > > - **Fuentes consultadas:** Expediente presentado, lista vigente para incorporar proveedores y ficha actual del proveedor. > - **Falta:** Certificado de seguro vigente. > - **Solicitud propuesta:** «Envíenos un certificado de seguro vigente para que la persona revisora de compras pueda continuar con la revisión de incorporación». > - **Estado:** Pendiente de revisión. No se envió ningún mensaje ni se tomó una decisión sobre el proveedor. ## Usa la descripción para completar la ficha de trabajo | Campo | Trabajo de incorporación de Northstar | |---|---| | Persona usuaria y responsable | La persona revisora de compras solicita la comprobación; una persona responsable de compras mantiene la lista y el proceso. | | Desencadenante y entrada | Un expediente de incorporación de Northstar está listo para revisión. | | Resultado deseado | Un resumen de la lista de requisitos y, si falta algo, un borrador de solicitud. | | Contexto aprobado | El expediente presentado, la lista vigente para incorporar proveedores y la ficha actual del proveedor. | | Acciones permitidas | Leer los materiales aprobados y preparar un borrador de texto. | | Límites | No actualizar la ficha del proveedor, enviar una solicitud ni aprobar al proveedor. | | Revisión humana | Una persona revisora de compras verifica la evidencia y decide qué enviar o hacer después. | | Condiciones para detenerse | Detenerse y explicar el problema si una fuente no está disponible, la evidencia se contradice o la solicitud queda fuera de la revisión de incorporación. | | Casos de evaluación | Expediente completo, certificado faltante, evidencia contradictoria y solicitud fuera de alcance. | Esta definición es lo bastante acotada para probarla. Si otro equipo necesita un resultado o un alcance de acciones distinto, asígnale su propio contexto, responsable y permisos. ## Copia las pruebas de las condiciones de parada del encargo Ejecuta estas comprobaciones con las condiciones de parada de la definición de Northstar anterior. Marca cada prueba como superada solo si el agente responde como se espera y se detiene antes de realizar un trabajo sin respaldo: - **Lista no disponible:** Impide leer la lista aprobada. El agente indica qué fuente no pudo consultar, no afirma que falta el certificado y deriva el caso a compras. - **Evidencia contradictoria:** Incluye datos distintos sobre el certificado en el expediente y en la ficha del proveedor. El agente señala el conflicto, no decide cuál dato es correcto y deriva el caso para revisión. - **Solicitud fuera de alcance:** Pide al agente que apruebe al proveedor. Rechaza esa acción, deja intacta la ficha y remite la decisión a compras. ## Separa el trabajo de la implementación **Elige un método según el resultado.** Define el resultado antes de elegir un modelo, una herramienta o una función del producto. Para Northstar, una comprobación fija puede confirmar si está presente un certificado específico; un paso con modelo quizá sea útil solo si hay que interpretar documentos. **Impón los permisos en los sistemas conectados.** Sea cual sea el método, los sistemas conectados deben aplicar los permisos de lectura y escritura, y una persona debe ser responsable de la aprobación. Las instrucciones por sí solas no limitan las acciones que una herramienta permite realizar. **Mantén actualizada la orientación aprobada.** Recopila los procedimientos y ejemplos vigentes del equipo en materiales mantenidos que el flujo esté autorizado a consultar. Trata los documentos presentados como evidencia que hay que evaluar, no como instrucciones que puedan cambiar el trabajo. Para ampliar el diseño, consulta [la guía sobre el entorno de control de un agente](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente) y [la arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). ## Define las reglas de fallo y derivación antes de la prueba piloto 1. **Define cómo responder ante excepciones.** Decide qué debe devolver el agente si falta la lista, el expediente y la ficha se contradicen o la persona revisora le pide aprobar al proveedor. Debe explicar el problema y derivar el caso, sin inventar evidencia ni salirse de su función. 2. **Define cuándo detenerse y revisar.** Elige cuándo detenerse ante fallos repetidos de las herramientas y asigna a la persona revisora la responsabilidad de aprobar cualquier solicitud antes de enviarla. 3. **Prueba el trabajo.** Usa expedientes representativos y registra si el resumen cita la evidencia correcta, qué corrige la persona revisora y qué casos se derivan. 4. **Mantén el trabajo en borrador.** Sigue así hasta que el equipo tenga evidencia que justifique ampliar las acciones permitidas. Primero valida la opción con [cómo elegir un caso de uso para un agente de IA](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso). ### Cómo elegir un caso de uso para un agente de IA - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso - Language: es - Description: Elige un trabajo con una persona responsable, pasos variables, información aprobada, un resultado revisable y una señal útil de éxito. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Elige un caso de uso para un agente cuando el trabajo tenga una persona responsable, varíe lo suficiente como para requerir pasos sensibles al contexto, use información aprobada y produzca un resultado que alguien pueda revisar. Mantén el primer trabajo lo bastante acotado para poder probarlo. ![Gráfico ilustrativo de valor frente a dificultad con los extremos Bajo y Alto; el caso con evidencia contradictoria tiene una marca de revisión.](/content/knowledge/visuals/es-choose-an-ai-agent-use-case.svg) *Ubicaciones ilustrativas para debatir el caso de Northstar; no son resultados medidos.* ## Empieza con una solicitud real **Solicitud de ejemplo:** «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». En este ejemplo ficticio de compras, la persona revisora necesita un resumen de integridad, no una decisión sobre el proveedor. El agente puede consultar el expediente presentado, la lista vigente para incorporar proveedores y la ficha actual del proveedor. Al expediente le falta el certificado de seguro vigente que exige la lista. **Antes de considerar la tecnología, define lo básico:** el desencadenante, la persona usuaria, el resultado deseado, la persona responsable, las fuentes y los límites. Un objetivo útil sería comparar el expediente con las referencias aprobadas, identificar la evidencia presente o faltante y preparar un borrador de solicitud. La persona revisora de compras sigue siendo responsable de enviarla y continuar la revisión. ## Comprueba si conviene usar un agente Pregúntate qué hace difícil la tarea: - **Fija y predecible:** Si cada expediente usa el mismo campo y una regla fija puede comprobarlo, quizá baste una automatización convencional. - **Evidencia variable:** Si la evidencia pertinente aparece en distintos formatos y el siguiente paso depende de interpretar lo que contiene, un agente puede ser una opción. Limita las primeras acciones del agente a leer los materiales aprobados y preparar un borrador. **Elige una regla para esta prueba piloto:** Si todos los formularios de Northstar registran el certificado de seguro en el mismo campo y la lista especifica el valor requerido, una regla fija puede comprobarlo y derivar los casos en que falte ese valor. No hace falta interpretar documentos. Prueba primero la regla; considera un agente cuando la evidencia varíe y requiera interpretación. El borrador para Northstar podría decir: > **Northstar Supplies — revisión de incorporación (borrador)**\ > **Fuentes consultadas:** Expediente presentado, lista vigente para incorporar proveedores y ficha actual del proveedor.\ > **Falta:** Certificado de seguro vigente.\ > **Solicitud propuesta:** «Envíenos un certificado de seguro vigente para que la persona revisora de compras pueda continuar con la revisión de incorporación».\ > **Decisión:** Pendiente de revisión; no se aprobó al proveedor ni se modificó su ficha. El resultado propone una derivación; no demuestra que el flujo sea preciso. La persona revisora debe poder rastrear el requisito faltante hasta la lista y el expediente originales. ## Compara la opción con criterios claros Antes de hacer una prueba piloto, registra: - El desencadenante y la persona usuaria. - Quién es responsable de las fuentes y qué se puede leer y escribir. - El punto de revisión y la ruta para las excepciones. - Los criterios de éxito. Para este flujo, prueba un expediente con el certificado requerido, uno sin él, otro con datos contradictorios y otro ajeno al alcance de la tarea. Define cómo evaluará la persona revisora si el resumen está completo y si la solicitud propuesta tiene respaldo. **Pospón el agente si** no hay una persona responsable del proceso, la lista no está disponible o genera desacuerdos, las personas revisoras no pueden definir un buen resultado o los sistemas conectados no pueden imponer el acceso previsto. Una puntuación numérica no debe ocultar ninguna de estas brechas. ## Prueba una parte y revisa la evidencia 1. **Acota la prueba piloto.** Limítala a un grupo de compras y a la comprobación de integridad. Mantén el acceso de solo lectura y la salida en borrador: nada de aprobar proveedores, actualizar registros ni enviar mensajes. 2. **Compara el trabajo.** Compara los borradores con una revisión humana de expedientes representativos. 3. **Registra la evidencia.** Anota los hallazgos respaldados, los requisitos omitidos, las correcciones, el esfuerzo de revisión, las excepciones y el costo por expediente revisado. Define las expectativas de calidad antes de la prueba; no afirmes que mejoró el proceso hasta que las mediciones lo demuestren. Después de la revisión, detén la prueba, modifica el diseño o amplíala según los criterios acordados. Cuando el flujo esté listo para convertirse en una definición del trabajo, consulta [cómo definir un trabajo acotado para un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Compara el patrón con [agente de IA, chatbot o automatización](/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion) y revisa [la arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). ### Resultados estructurados para agentes de IA - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes/resultados-estructurados - Language: es - Description: Define los campos obligatorios, los valores permitidos, las referencias de evidencia y las condiciones de revisión; luego valida la estructura y los hechos. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Las salidas estructuradas facilitan la validación, la presentación y la derivación de los resultados de un agente. Define los campos obligatorios, los valores permitidos, cómo representar los datos desconocidos, qué fuentes respaldan el resultado y cuándo debe revisarlo una persona. Después, valida la estructura y, por separado, comprueba que los valores coincidan con evidencia autorizada antes de que otro sistema dependa de ellos. ![Una solicitud amplia se convierte en una ficha con un disparador, datos, tarea, resultado y transferencia.](/content/knowledge/visuals/es-agent-design.svg) *La ficha define la tarea. El contrato JSON que sigue especifica qué debe contener el resultado.* ## Define el resultado antes de elegir cómo mostrarlo Para un flujo ficticio de estado de pedidos, exige los siguientes campos. Sus nombres y valores enumerados forman el contrato de ejemplo de este artículo; no son un tipo del SDK ni una API de AgentShelf: | Campo | Contrato para este flujo | | --- | --- | | `order_ref` | Cadena obligatoria que debe coincidir con el registro de pedido autorizado. | | `ownership_verified` | Booleano obligatorio; solo es `true` después de confirmar que el cliente con sesión iniciada coincide con la persona propietaria del pedido. El número de pedido por sí solo no demuestra que tenga acceso. | | `status` | Enumeración obligatoria: `in_transit`, `delivered`, `delayed` o `unknown`. | | `last_scan` | Objeto obligatorio con `location` y `time`, o `null` si no hay un escaneo disponible. | | `delivery_estimate` | Cadena obligatoria tomada de la fuente, o `null` cuando la fuente no proporcione una estimación. | | `customer_message` | Borrador en lenguaje claro y obligatorio, respaldado por los demás campos. | | `review_required` y `review_reason` | Indicador obligatorio y motivo anulable; solicita revisión si falla la verificación de titularidad, la evidencia se contradice o el estado es desconocido. | | `source_refs` | Lista obligatoria de referencias a los registros aprobados utilizados. | Este contrato permite representar un dato desconocido en vez de incentivar una conjetura. Mantén la tarea en modo de solo lectura: producir una respuesta sobre el estado no autoriza a modificar un pedido, emitir un reembolso ni prometer una fecha de entrega. El número de pedido por sí solo no demuestra que exista permiso de acceso. Primero verifica la titularidad de la persona con sesión iniciada mediante el contexto de identidad confiable de la aplicación; solo después consulta el registro de seguimiento. Si no se confirma la titularidad, detente antes de leer el registro y usa una respuesta de acceso denegado o una derivación a soporte que no revele detalles del pedido. El campo `ownership_verified` informa de esa comprobación confiable; un booleano generado por el modelo no concede acceso. ## Valida por separado la estructura y la evidencia Primero valida la estructura: que estén todos los campos obligatorios, coincidan los tipos, se permitan los valores enumerados y los campos anulables contengan el valor documentado o `null`. Rechaza los resultados mal formados; no muestres una respuesta parcial ni conviertas un valor enumerado desconocido en un estado de éxito. Verifica la titularidad antes de consultar el seguimiento; si falla, no consultes ni reveles el registro. Después valida el significado con respecto a la entrada y a la fuente aprobada. Comprueba que la cuenta con sesión iniciada sea titular del pedido, que la referencia de la fuente identifique el registro de seguimiento consultado y que el estado y los datos del escaneo coincidan. Confirma que una estimación nula siga siendo nula en el mensaje al cliente. Un objeto JSON válido según el esquema todavía puede contener una afirmación sin respaldo o que no coincide con la fuente; validar solo la estructura no basta. ## Revisa un resultado completado En este ejemplo ficticio, antes de consultar el seguimiento, el sistema confirma mediante un contexto de identidad confiable que el cliente con sesión iniciada es titular del pedido `O-418`. Solo después de esa comprobación lee el registro de seguimiento aprobado: indica que el paquete está en tránsito, se escaneó por última vez en el centro de distribución Norte a las 09:40 y no incluye una estimación de entrega. Si no se confirma la titularidad, el flujo se detiene antes de leer el registro y devuelve una denegación segura o deriva el caso sin revelar datos del pedido. Cuando sí se confirma, permite una consulta de solo lectura y un borrador de mensaje. > **Resultado JSON ilustrativo: solo contrato de salida, no es una solicitud del SDK ni de la API**\ > **Comprobación de entrada:** El contexto de identidad confiable confirma que el cliente es titular; solo entonces se consulta el registro de seguimiento aprobado.\ > **Resultado validado:** > > ```json > { > "order_ref": "O-418", > "ownership_verified": true, > "status": "in_transit", > "last_scan": { > "location": "Centro de distribución Norte", > "time": "09:40" > }, > "delivery_estimate": null, > "customer_message": "El pedido O-418 está en tránsito. El último escaneo fue a las 09:40 en el centro de distribución Norte. El registro de seguimiento no incluye una fecha estimada de entrega.", > "review_required": false, > "review_reason": null, > "source_refs": ["tracking-record-O-418"] > } > ``` El resultado coincide con el registro descrito, conserva como `null` la estimación faltante y no afirma que se haya escrito ningún dato ni que exista una fecha de entrega confirmada. Si no se puede verificar la titularidad, hay evidencia contradictoria o falla la validación de la estructura, no envíes el borrador como respuesta verificada: deriva el caso a revisión. Mantén la validación y cualquier acción comercial posterior como pasos independientes. Para definir los límites de la tarea y redactar un encargo conciso, continúa con [cómo definir una tarea enfocada para un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Para decisiones que requieren revisión humana, consulta [agentes de IA con supervisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes); para el ciclo de vida de la conversación, lee [sesiones, conversaciones y artefactos](/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos). ### Revisión humana para agentes de IA - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes - Language: es - Description: La revisión humana aporta más valor en puntos de decisión claros, donde una aprobación, una corrección o un escalamiento pueden cambiar el resultado. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) La revisión humana funciona mejor en un punto definido donde una persona puede cambiar el resultado: aprobar una acción, corregir un borrador, aportar información faltante o hacerse cargo de una excepción. Quien revisa necesita saber qué encontró el agente, qué propone y qué ocurrirá después de tomar una decisión. Imagina que Northstar Supplies envía un expediente de incorporación de proveedores. Un agente lo compara con la lista vigente para incorporar proveedores y la ficha actual del proveedor. La lista exige un certificado de seguro, pero el expediente no lo incluye. El agente puede preparar un resumen y una solicitud del documento faltante; una persona decide si la envía. El agente no aprueba al proveedor. ![Un borrador llega a una persona revisora: Aprobar continúa con el resultado, Solicitar cambios devuelve al borrador, Rechazar lo detiene y Esperar lo pausa.](/content/knowledge/visuals/es-human-in-the-loop-ai-agents.svg) *Cuatro decisiones independientes en un mismo punto de revisión.* ## Pausa en el punto de decisión **Preparación:** El agente puede realizar tareas acotadas, como leer el expediente y enumerar los documentos que encontró. **Punto de decisión:** El agente debe detenerse antes de realizar una acción externa o irreversible, como enviar la solicitud. Si los registros se contradicen o no está claro cuál es el siguiente paso correcto, debe remitir el caso al equipo de Compras en vez de adivinar. Elige el tipo de intervención que necesita el caso: - **Aprobación:** Una persona autoriza la solicitud propuesta antes de que se envíe. - **Transferencia:** Una persona se hace cargo del caso y continúa la revisión. - **Escalamiento:** Un caso con evidencia contradictoria o una política poco clara pasa a alguien con autoridad para resolverlo. No pidas a una persona que apruebe cada consulta inocua. Reserva la revisión para los puntos donde el criterio humano afecta el riesgo, la calidad o la siguiente acción. Define un plazo de respuesta y una persona suplente para las aprobaciones que no reciban respuesta. ## Redacta una solicitud de revisión clara Incluye la solicitud original, la evidencia consultada, el hallazgo del agente, la acción propuesta y un conjunto breve de opciones. Para Northstar Supplies, la solicitud podría decir: > **Se necesita una revisión: Northstar Supplies** > > - **Elementos comprobados:** Expediente de incorporación, lista vigente para incorporar proveedores y ficha actual del proveedor. > - **Hallazgo:** Falta un certificado de seguro vigente en el expediente. > - **Acción propuesta:** Solicitar el certificado. > - **Mensaje en borrador:** «Envíe un certificado de seguro vigente para Northstar Supplies, de modo que el equipo de Compras pueda continuar con la revisión». > - **Opciones:** Aprobar el envío, editar la solicitud, pedir más información o remitir el caso al equipo de Compras. > - **Estado:** No se ha enviado ningún mensaje; la aprobación del proveedor sigue pendiente. Este es un ejemplo ficticio. El diseño debe hacer que cada opción lleve a un paso siguiente conocido: la aprobación se aplica solo a la solicitud mostrada; las modificaciones vuelven como borrador para revisión; el rechazo deja intacto el registro del proveedor; y la transferencia pasa el caso con su contexto. ## Prueba el proceso de revisión humana Usa el mismo caso para comprobar las situaciones habituales y las excepciones: - **Expediente completo:** Leerlo no debe generar una aprobación innecesaria. - **Falta el certificado:** El agente debe producir un borrador que se pueda revisar. - **Registros contradictorios:** El agente debe escalar el caso en vez de adivinar. - **Respuesta de quien revisa:** Prueba una solicitud editada, un rechazo y la falta de respuesta antes del plazo acordado. Confirma que la persona revisora vea solo la información necesaria para tomar la decisión. La revisión humana no sustituye los permisos acotados ni una responsabilidad clara. Combínala con [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y [evaluación de agentes de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). Para conocer los límites específicos del producto, consulta el [resumen de confianza y límites](/es/platform/trust-boundaries). ### Diseña traspasos de trabajo entre agentes y sistemas - Route: https://agentshelf.ai/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas - Language: es - Description: Mantén pendiente un traspaso entre sistemas hasta que el sistema receptor confirme la solicitud e indique qué ocurrió después. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un traspaso entre sistemas solo se completa cuando el sistema receptor confirma que recibió el trabajo y queda claro su estado. Registra qué enviaste, quién o qué lo recibió, si se aceptó y si terminó el trabajo solicitado. Que una solicitud se haya aceptado no significa que el trabajo esté completo. ## Sigue una solicitud de reparación entre sistemas Una persona empleada pide a un agente de servicio: «Revisa mi solicitud de reemplazo de teclado según el catálogo de equipo aprobado y la lista de existencias; después, envía una solicitud de entrega al sistema de inventario. No marques el artículo como entregado». El agente puede leer el ticket de servicio y el catálogo aprobado, y enviar una solicitud acotada al flujo de inventario. No puede registrar una entrega. El sistema receptor acepta la solicitud, pero todavía no ha asignado un artículo. Una actualización completa podría decir: > **Reemplazo de teclado — estado del traspaso** > > - **Fuentes consultadas:** Ticket de servicio, catálogo de equipo aprobado y respuesta del inventario actual. > - **Enviado a:** Cola de cumplimiento de inventario. > - **Estado del receptor:** Aceptado para su procesamiento; referencia `REQ-184`. > - **Estado de finalización:** Pendiente de asignación y confirmación de entrega. > - **Límite:** El agente de servicio no marcó el artículo como entregado. La confirmación indica que el siguiente sistema se hizo cargo del procesamiento. No demuestra que se haya completado el pedido ni constituye una aprobación humana de la decisión del agente. ![Un borrador llega a una persona revisora y se divide en aprobar, revisar, rechazar o esperar](/content/knowledge/visuals/es-human-in-the-loop-ai-agents.svg) *El diagrama muestra los resultados de la revisión humana; el acuse de recibo del sistema receptor se comprueba por separado.* ## Define el contrato del traspaso Antes de conectar los flujos de trabajo, acuerda qué información y estado necesita cada parte: - **Identidad del trabajo:** Asigna una referencia estable que vincule el caso de origen con el elemento recibido. - **Contexto:** Envía solo los campos y el resumen de evidencia aprobados que el destinatario necesita. Identifica el registro de origen y la acción solicitada. - **Responsable receptor:** Nombra la cola, equipo o sistema que se hará cargo, además de la persona operadora de las excepciones. - **Acuse de recibo:** Define qué confirma la recepción o aceptación. Una respuesta de red, un mensaje en cola, un elemento aceptado y una tarea completada pueden ser estados distintos. - **Estado y resultado:** Acuerda qué resultados pendientes, rechazados, completados o fallidos se pueden comunicar y cómo se reflejan en la solicitud de origen. - **Tiempo de espera, reintentos y duplicados:** Decide qué hacer si no llega una confirmación. Comprueba si una solicitud repetida puede crear un segundo trabajo antes de reintentar. - **Ruta de fallo:** Identifica quién resuelve un estado desconocido, un rechazo, un registro desactualizado o una finalización parcial. Para un trabajo de larga duración, el emisor puede recibir un acuse temprano y consultar el resultado posterior mediante sondeo, un evento u otro canal compatible. Elige un patrón que admita el sistema receptor. No marques el trabajo como exitoso solo porque se envió el mensaje. ## Responde cuando se pierde el estado del sistema receptor En el flujo ficticio del teclado, inventario confirma la recepción de `REQ-184`, pero no llega una actualización de asignación o finalización antes de la hora acordada para comprobar el estado. El caso de origen figura como aceptado y aún pendiente, no como completado. Consulta `REQ-184` mediante el canal de estado acordado con el sistema receptor. Si sigue pendiente, mantén abierto el caso original. Si no se puede confirmar el estado o se rechazó la solicitud, detén los reintentos automáticos y envía la referencia, el último estado confirmado y la hora de comprobación a la persona responsable de inventario para que lo concilie. No crees una segunda solicitud ni marques el artículo como entregado hasta aclarar el estado de la primera. Registra la referencia del traspaso, los cambios de estado, las marcas de tiempo y la acción de recuperación para que una persona operadora pueda reconstruir la ejecución; consulta [la guía de observabilidad de agentes de IA](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes). ## Distingue el traspaso entre sistemas de la revisión humana Un acuse de un sistema responde: «¿El sistema receptor aceptó el trabajo?». Una revisión humana responde: «¿Es apropiada esta acción y debe continuar?». Una cosa no sustituye a la otra. En el ejemplo del teclado, una solicitud aceptada aún podría requerir que una persona decida si sirve un artículo sustituto; la recepción por el sistema de inventario no puede tomar esa decisión. Prueba las rutas habituales, de rechazo, de espera agotada, de entrega duplicada y de fallo parcial antes de ampliar el uso. Mantén la solicitud original abierta o claramente pendiente mientras el estado receptor sea desconocido. Para los puntos de decisión humana, consulta [revisión humana para agentes de IA](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes); para definir el alcance del flujo, consulta [cómo redactar una definición de trabajo acotada](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). ### Fundamentos de los agentes de IA - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia - Language: es - Description: Comprende los agentes de IA, sus harnesses y la arquitectura que rodea al modelo antes de elegir tu primer flujo de trabajo. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente de IA se entiende mejor cuando se considera el sistema completo: la tarea, el modelo, la información que utiliza, las acciones que puede realizar y los límites que las rigen. ![Una ruta de cuatro pasos: comprender, comparar, estudiar la arquitectura y conocer el harness.](/content/knowledge/visuals/es-foundations.svg) Esta ruta es para quienes exploran los agentes o quieren explicar un proyecto de agentes a sus colegas. No hace falta empezar por una API ni por comparar modelos. ## Sigue la ruta de aprendizaje 1. **Aprende el concepto básico.** [¿Qué es un agente de IA?](/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia) presenta una definición práctica y un ejemplo. 2. **Elige un enfoque.** [Agente de IA, chatbot o automatización](/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion) ayuda a decidir si una tarea requiere un agente, una automatización fija o una conversación. 3. **Relaciona las piezas del sistema.** [Arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia) muestra cómo encajan el trabajo, el contexto, las herramientas, el espacio de trabajo y el entorno de ejecución. 4. **Comprende los controles de ejecución.** [¿Qué es un harness de agente?](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente) explica las instrucciones, el contexto, las capacidades, los límites y las reglas de revisión que rodean al modelo. La arquitectura muestra cómo se reparte el trabajo entre las partes del sistema. El harness define la configuración y los controles que guían al modelo mientras trabaja. ## Aplica los conceptos a una tarea conocida Imagina que preparas un informe semanal para clientes. ¿Qué información necesitaría el sistema? ¿Podría terminar entregando un borrador o tendría que actualizar otro sistema? ¿Quién revisaría el resultado? Estas preguntas ayudan a distinguir un diseño de agente útil de una simple demostración conversacional. Si la tarea siempre sigue los mismos pasos conocidos, incluye la automatización convencional en la comparación. Si el trabajo implica evidencia poco clara o varias acciones posibles, anota cómo limitarías esas opciones y cómo las revisarías. ## Pasa de comprender a diseñar Consulta el [glosario](/es/conocimiento/glosario) para ver definiciones breves. Cuando tengas una tarea candidata, evalúa si encaja con la guía [elige un caso de uso para un agente de IA](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso) y continúa con el [diseño de agentes](/es/conocimiento/diseno-de-agentes). Para conocer la arquitectura del producto AgentShelf, consulta la [descripción general de la plataforma](/es/platform) y la página sobre el [harness del agente](/es/platform/agent-harness). ## Todas las guías de este tema - [¿Qué es un agente de IA?](/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia): Un agente de IA combina un modelo, herramientas y reglas definidas para avanzar hacia un objetivo, comprobar resultados y derivar el trabajo cuando hace falta. - [¿Agente de IA, chatbot o automatización?](/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion): Usa un chatbot para conversar, reglas para pasos predecibles y un agente cuando la evidencia aprobada deba orientar el siguiente paso dentro de límites claros. - [Arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia): Un agente combina un trabajo definido, contexto aprobado, un modelo, herramientas permitidas, controles de ejecución y revisión humana para producir un resultado verificable. - [El entorno de control de un agente](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente): El entorno de control de un agente define el trabajo del modelo, su contexto, las herramientas disponibles, sus límites y las reglas de revisión. - [Qué es la infraestructura para LLM](/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm): Identifica el acceso a modelos, la ejecución, los datos, la fiabilidad y las responsabilidades operativas. - [Opciones de despliegue para LLM](/es/conocimiento/fundamentos-de-ia/opciones-de-despliegue-de-llm): Compara enfoques gestionados, híbridos y on-premise según los datos y las responsabilidades. ### ¿Agente de IA, chatbot o automatización? - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion - Language: es - Description: Usa un chatbot para conversar, reglas para pasos predecibles y un agente cuando la evidencia aprobada deba orientar el siguiente paso dentro de límites claros. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Usa un chatbot cuando lo principal sea conversar. Usa una automatización basada en reglas cuando las entradas y los pasos siguientes sean predecibles. Considera un agente cuando deba consultar información aprobada para elegir el siguiente paso dentro de límites definidos. Puedes combinar los tres enfoques si cada uno tiene una función clara. ![Tres maneras de atender una solicitud: un chatbot intercambia mensajes, una automatización sigue una secuencia fija y un agente toma ramificaciones y repite pasos según lo que encuentra.](/content/knowledge/visuals/es-ai-agent-vs-chatbot-vs-automation.svg) *Tres caminos ilustrativos para una misma solicitud de Northstar.* ## Tres maneras de atender una solicitud de incorporación Imagina que una persona revisora del equipo de compras pide: «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». En este ejemplo ficticio, el agente puede leer el expediente presentado, la lista de verificación vigente para incorporar proveedores y la ficha actual del proveedor. La lista exige un certificado de seguro vigente, que no aparece en el expediente. | Patrón | Qué haría ante esta solicitud | Cuándo conviene | |---|---|---| | Chatbot | Pedir más detalles a la persona revisora o explicarle qué información necesita mediante una conversación. Para explicar la lista, necesitaría consultar una fuente aprobada. | Conversación, aclaraciones y orientación. | | Automatización basada en reglas | Comprobar un campo conocido del certificado o una marca de documento frente a la lista, y derivar a compras los expedientes incompletos. | Entradas estables y condiciones explícitas. | | Agente | Interpretar el expediente, consultar la lista aprobada y la ficha del proveedor, identificar lo que falta y preparar un resumen y una solicitud para revisión. | Documentos variables en los que el siguiente paso depende de la evidencia encontrada. | El borrador del agente podría decir: > **Northstar Supplies — revisión de incorporación (borrador)**\ > **Falta:** Certificado de seguro vigente.\ > **Solicitud propuesta:** «Envíenos un certificado de seguro vigente para que la persona revisora de compras pueda continuar con la revisión de incorporación».\ > **Estado:** Pendiente de revisión humana; no se envió ninguna solicitud ni se aprobó al proveedor. El resultado solo es útil si la lista y el expediente realmente lo respaldan. Si una persona revisora puede comprobar directamente un campo obligatorio, una automatización podría ser más sencilla. Si los formatos de los expedientes requieren interpretación, un agente puede ayudar a preparar el trabajo, mientras una persona decide qué enviar o aprobar. Un flujo combinado para esta solicitud podría usar los tres patrones: un chatbot recibe el expediente y aclara los datos de incorporación que falten, una regla comprueba si está el certificado requerido y un agente interpreta documentos variables según la lista para preparar un borrador respaldado. El equipo de compras sigue decidiendo si envía algo o aprueba al proveedor. Si el formulario y la lista permiten una regla fiable, se omite el paso con agente. ## Elige según las decisiones que exige el trabajo Antes de elegir, comprueba cuatro aspectos: - ¿El siguiente paso es fijo? - ¿El trabajo requiere evidencia de fuentes mantenidas y aprobadas? - ¿Varían los datos de entrada? - ¿Alguien puede revisar el resultado antes de que afecte a una persona o un registro? Para Northstar, primero confirma si el requisito del certificado se puede comprobar con una regla fiable. Usa un agente solo si las diferencias entre los expedientes hacen insuficiente esa regla y es posible evaluar la interpretación adicional. Las **reglas** son más fáciles de rastrear cuando las condiciones son explícitas, aunque el equipo debe actualizarlas si cambia el proceso. Un **chatbot** puede facilitar el acceso a las instrucciones, pero una respuesta fluida no demuestra que haya usado la fuente correcta. Un **agente** puede adaptar el siguiente paso, lo que añade comportamientos que hay que probar y limitar. > **Regla práctica:** Empieza por el patrón más sencillo que resuelva el trabajo. Registra el resultado esperado, por qué el proceso actual necesita ayuda, cuál es la alternativa más sencilla, qué información y acciones se permiten y cuándo interviene una persona. Consulta [cómo elegir un caso de uso para un agente de IA](/es/conocimiento/diseno-de-agentes/elegir-un-caso-de-uso), [la arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia) y [qué es un agente de IA](/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia). ### Arquitectura de un agente de IA - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia - Language: es - Description: Un agente combina un trabajo definido, contexto aprobado, un modelo de IA, herramientas permitidas, controles de ejecución y revisión humana para producir un resultado verificable. - Updated At: 2026-09-29 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-29) Un equipo de compras necesita revisar documentos de un proveedor. Un agente los lee, comprueba requisitos y prepara un borrador para revisión. Su arquitectura conecta la información, las herramientas y las decisiones humanas de ese trabajo. ![Diagrama de una solicitud que entra en un entorno de ejecución con orquestación, documentos de contexto, un modelo de IA y herramientas de solo lectura antes de la revisión humana.](/content/knowledge/visuals/es-ai-agent-architecture.svg) *Flujo ilustrativo de incorporación de Northstar.* ## Sigue una solicitud por el sistema Este ejemplo ficticio parte de una solicitud del equipo de compras: «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». El agente puede consultar el expediente presentado, la lista vigente para incorporar proveedores y la ficha actual del proveedor. En este caso, la lista exige un certificado de seguro vigente que no aparece en el expediente. | Parte | Función en este ejemplo | |---|---| | Trabajo e instrucciones | Preparar un resumen de los documentos recibidos y de los que faltan, junto con un borrador para solicitarlos; no aprobar al proveedor. | | Contexto | Limitar la evidencia al expediente presentado, la lista vigente y la ficha actual del proveedor. | | Modelo de IA | Extraer los datos pertinentes de los documentos y explicar qué requisito de la lista no se cumple. | | Herramientas y permisos | Leer los materiales aprobados y preparar texto. No editar la ficha del proveedor ni enviar mensajes. | | Flujo de trabajo | Contrastar el expediente con la lista, verificar la ficha, señalar lo que falta y preparar un borrador. | | Entorno de ejecución y acceso | Limitar el entorno al material de compras asignado y a las personas autorizadas. | | Revisión | Mostrar la evidencia y el borrador a una persona del equipo de compras antes de que alguien envíe la solicitud o cambie un registro. | El borrador resultante podría decir: > **Northstar Supplies — revisión de incorporación (borrador)**\ > Se contrastó el expediente presentado con la lista vigente para incorporar proveedores y con la ficha del proveedor. > > - **Falta:** Certificado de seguro vigente. > - **Siguiente paso:** Solicitar el certificado y después continuar con la revisión de incorporación. > - **Estado:** Pendiente de revisión por compras. No se aprobó al proveedor ni se actualizó la ficha. La solicitud entra como instrucción, las fuentes aprobadas aportan evidencia y la acción permitida produce un borrador. Si la lista y la ficha se contradicen, o el documento no está disponible, el sistema debe señalar la incertidumbre en lugar de completar el vacío con una suposición. ## Elige el flujo más sencillo que resuelva el trabajo Adapta el enfoque a los documentos: - **Usa reglas** cuando los campos del expediente sean uniformes y la lista tenga requisitos fijos, por ejemplo, para detectar que falta un certificado. - **Usa un paso con un modelo de IA** cuando varíen los formatos y el sistema tenga que interpretar qué evidencia corresponde a cada requisito. El modelo de IA puede ayudar a extraerla y explicarla. Mantén separadas las interpretaciones del modelo de IA y las comprobaciones deterministas. > **Regla de diseño:** Añade un paso solo si tiene un propósito claro y una forma de verificar su resultado. Esboza el flujo antes de implementarlo: 1. **Recepción:** Cargar la solicitud, el expediente y los registros aprobados. 2. **Extraer:** Obtener evidencia mediante reglas o un modelo de IA, según qué tan estructurada esté la información. 3. **Comparar:** Contrastar la evidencia con la lista. 4. **Preparar:** Redactar una propuesta. 5. **Revisión humana:** Una persona del equipo de compras comprueba la evidencia y el borrador y decide el siguiente paso. Indica qué datos pasan por cada paso, qué puede leer o escribir cada herramienta y qué ocurre cuando falla una comprobación. ## Redacta un resumen de arquitectura Convierte el ejemplo de Northstar en un plan para implementar y probar: - **Usuario y fuentes:** Indica quién usará el flujo de compras, qué expediente revisará y cuáles son las fuentes de referencia aprobadas. - **Acceso y resultado:** Especifica el acceso de solo lectura y el resumen en borrador. - **Revisión y excepciones:** Indica quién decidirá si se envía la solicitud y define qué hacer cuando la evidencia falte o sea contradictoria. Prueba el caso habitual de un certificado faltante, un expediente completo, información contradictoria y una solicitud ajena a esta tarea. Define los criterios de calidad antes de ajustar el diseño. Siguiente paso: [define un trabajo acotado para tu agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Para conocer los conceptos básicos, consulta [qué es un agente de IA](/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia) y [qué es un entorno de control de agente](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente). > **En AgentShelf** > > Define controles con el [entorno de control del agente](/es/platform/agent-harness), conecta [conocimiento aprobado y herramientas aprobadas](/es/platform/knowledge-tools-automation) y elige modelos de IA configurados mediante la [pasarela gestionada](/es/technology/infrastructure). La disponibilidad y las capacidades de los modelos de IA, así como los registros operativos, varían según el despliegue y la configuración. ### El entorno de control de un agente - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente - Language: es - Description: El entorno de control de un agente define el trabajo del modelo, su contexto, las herramientas disponibles, sus límites y las reglas de revisión. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) El entorno de control de un agente —a veces llamado *harness*— define el trabajo del modelo, su contexto, las herramientas disponibles, sus límites y las reglas de revisión. Convierte una instrucción amplia en un flujo de trabajo repetible que el equipo puede inspeccionar y probar. Imagina un agente ficticio para la incorporación de proveedores de Northstar Supplies. El equipo de compras pide: «Prepara una revisión de incorporación con el expediente, la lista de verificación aprobada y la ficha actual del proveedor. Señala la evidencia que falta y redacta una solicitud de documentos para que alguien la revise. No apruebes al proveedor ni envíes ningún mensaje». El entorno define qué puede leer el agente, qué borrador debe producir y cuándo debe intervenir una persona. ![Diagrama de un modelo dentro del entorno de control del agente de Northstar Supplies, rodeado por instrucciones, contexto, acceso a herramientas, límites y comprobaciones](/content/knowledge/visuals/es-what-is-an-agent-harness.svg) *Un modelo rodeado de controles para la tarea.* ## Define las partes que rodean el trabajo - **Trabajo:** Preparar una revisión de incorporación y redactar una solicitud de la evidencia faltante. - **Contexto:** Usar el expediente presentado, la lista aprobada y la ficha actual del proveedor. Indicar qué fuente respalda cada hallazgo. - **Herramientas:** En este ejemplo hipotético, permitir la lectura de esas fuentes y la creación de un borrador. No habilitar acciones para aprobar ni enviar. - **Reglas:** Señalar la información faltante o contradictoria, no completar vacíos con suposiciones y detenerse antes de aprobar o enviar. - **Revisión:** Entregar el borrador al equipo de compras, que decidirá si solicita otro documento o continúa con la revisión. Resultado ilustrativo basado en registros ficticios de Northstar Supplies: > **Revisión de incorporación — borrador** > > - **Hallazgo:** Falta un certificado de seguro vigente en el expediente de incorporación. > - **Solicitud propuesta:** «Envíenos un certificado de seguro vigente para que el equipo de compras pueda continuar la revisión». > - **Estado:** No se envió ningún mensaje ni se aprobó al proveedor. Este ejemplo muestra cómo el trabajo, el contexto, las herramientas y los límites determinan el resultado. Si no se puede leer la lista o la ficha actual, el agente debe informar de esa brecha y derivar el caso, en lugar de presentar una conclusión sin verificar. Las instrucciones por sí solas no garantizan un comportamiento correcto; prueba el flujo con expedientes completos, incompletos y contradictorios. ## El entorno va más allá de una instrucción Una instrucción puede describir el rol y las reglas de operación. El entorno completo también incluye la información y las acciones que realmente están al alcance del modelo, además del contexto de ejecución y el proceso de revisión. > **Regla de control:** Escribir «no apruebes» no sustituye a retirar la capacidad de aprobar cuando el sistema permite controlar esos permisos. Sin esos controles, el flujo de Northstar puede mostrar fallos observables. Si no se puede leer la lista, pero el borrador afirma que falta el certificado, la persona revisora no tiene evidencia de la lista que respalde el hallazgo. Si el agente aún puede enviar mensajes aunque sus instrucciones solo permitan preparar borradores, comprueba en el estado de los mensajes salientes si envió alguna solicitud antes de la revisión. Exige evidencia de las fuentes indicadas, detente y deriva el caso si una fuente no está disponible, y retira de este flujo las acciones de aprobación y envío. Antes de probarlo, asegúrate de que otra persona del equipo pueda: - Expresar el trabajo en una sola oración. - Nombrar todas las fuentes. - Explicar cada acción permitida. - Identificar el momento en que debe decidir una persona. Acota la tarea si alguno de estos puntos no está claro. Para ver un mapa de los componentes, consulta [la arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). Para definir el trabajo, consulta [cómo definir un trabajo acotado para un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). Para relacionar trabajos enfocados, conocimiento aprobado y acciones delimitadas con el producto, consulta la [página del harness de AgentShelf](/es/platform/agent-harness). ### Qué es la infraestructura para LLM: guía para equipos que crean agentes de IA - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm - Language: es - Description: Comprende el acceso a modelos, la ejecución, los datos, la fiabilidad y los controles de costo de un agente de IA antes de iniciar un piloto. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) La infraestructura para LLM es el conjunto de servicios y controles operativos que permite a una aplicación utilizar modelos de lenguaje de gran tamaño de forma fiable. Para un agente de IA, el acceso al modelo es una dependencia dentro de un sistema más amplio: también necesita un entorno de ejecución, información autorizada, herramientas y una forma de comunicar los resultados. Un buen punto de partida es seguir una tarea desde la solicitud hasta un resultado verificable. Así se identifica quién opera cada dependencia y dónde un fallo podría impedir completar el trabajo. ![Una solicitud pasa por el entorno de ejecución del agente y la pasarela hacia un modelo configurado; los datos y herramientas autorizados apoyan la ejecución.](/content/knowledge/visuals/es-llm-infrastructure.svg) *El modelo es una dependencia más; la ejecución, los datos y las herramientas completan el sistema.* ## Separa el servicio del modelo de la ejecución del agente El **servicio del modelo** ejecuta el modelo y devuelve contenido generado. La **ejecución del agente** realiza la lógica de la aplicación: reúne contexto, llama al modelo, utiliza herramientas permitidas y determina el siguiente paso. Ambos pueden funcionar en entornos distintos y tener responsables diferentes. Una pasarela puede ofrecer un punto común de acceso a los modelos configurados. Por sí sola, no define el trabajo del agente ni decide qué acciones de negocio debe aprobar una persona. Para conocer el sistema completo, consulta la [arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). ## Mapea las seis partes de una solución de infraestructura para LLM Una lista larga de modelos disponibles dice poco sobre si un proveedor puede ejecutar tu trabajo. En cambio, sigue una tarea completa y pregunta, para cada una de estas seis partes, quién la opera y qué sucede cuando falla. - **Acceso al modelo:** Envía solicitudes a un modelo aprobado. Normalmente lo operan el equipo de plataforma y el proveedor del modelo. Prepárate para que el modelo no esté disponible o que la única alternativa no sirva para la tarea. - **Entorno de ejecución del agente:** Realiza la tarea paso a paso. Normalmente lo opera quien administra la aplicación. Prepárate para una tarea que se interrumpe a mitad de camino sin que nadie sepa si terminó. - **Conocimiento y herramientas:** La información que el agente puede leer y las acciones que puede realizar. Normalmente cada responsable de una fuente las opera. Prepárate para información ausente, desactualizada o bloqueada. - **Trabajo en curso y resultados:** Donde se guardan los borradores y resultados terminados. Normalmente lo opera quien administra los datos de la aplicación. Prepárate para un borrador a medio hacer que parece terminado. - **Reglas de recuperación:** Cuándo reintentar, cambiar a otro modelo o detenerse. Normalmente las define la persona responsable del flujo. Prepárate para repetir una acción, como enviar un mensaje o actualizar un registro, que tal vez ya ocurrió. - **Uso y costo:** Lo que cuesta cada tarea y qué presupuesto se aplica. Normalmente lo gestiona la persona responsable del presupuesto. Prepárate para costos que nadie puede rastrear o una solicitud que ningún presupuesto revisa. Pide al agente que prepare la hoja a partir de la descripción de la tarea y los sistemas que conectará. Después, tu equipo revisa cada respuesta con quien realmente opera esa parte. Mantén separada la lista de modelos de los permisos del agente: añadir un modelo nunca debe darle acceso silenciosamente a nuevos registros o acciones. > **Hoja de requisitos de infraestructura (en blanco)** > > - Acceso al modelo: quién lo opera, qué sucede si falla y cómo lo probaremos: ___ > - Entorno de ejecución del agente: quién lo opera, qué sucede si falla y cómo lo probaremos: ___ > - Conocimiento y herramientas: quién es responsable de cada fuente, qué sucede si una no está disponible y cómo lo probaremos: ___ > - Trabajo en curso y resultados: dónde se guardan los borradores, cómo se marca un borrador a medio hacer y cómo lo probaremos: ___ > - Reglas de recuperación: cuándo reintentar, cuándo cambiar, cuándo detenerse y a quién avisar: ___ > - Uso y costo: quién es responsable del presupuesto, qué presupuesto se aplica a esta tarea y cómo lo confirmaremos: ___ ## Ejemplo: un asistente para solicitudes de mantenimiento En este piloto ficticio, un equipo de mantenimiento quiere clasificar solicitudes y preparar una respuesta sugerida. El modelo interpreta texto libre; la aplicación comprueba las categorías permitidas y muestra un borrador. Una persona aprueba cualquier cambio en el registro de mantenimiento. El equipo redacta un breve plan de infraestructura: - **Entrada:** Texto de la solicitud y guía de categorías aprobada; excluir registros de personal ajenos a la tarea. - **Ejecución:** Una persona responsable de la aplicación mantiene el entorno y la conexión con la herramienta. - **Modelo:** Probar las opciones configuradas con solicitudes ambiguas e información faltante. - **Resultado:** Categoría recomendada, evidencia y borrador de respuesta. - **Fallos:** Mostrar un estado pendiente de revisión cuando el modelo o la guía no estén disponibles. - **Revisión operativa:** Examinar fallos y gasto junto con las recomendaciones aceptadas. El éxito consiste en que una persona pueda verificar la recomendación y comprender cualquier fallo. Una respuesta del modelo, por sí sola, no significa que la tarea haya terminado correctamente. ### La hoja completada La versión del equipo de mantenimiento se lee así. Cada prueba es algo que el piloto debe superar antes de que entren solicitudes reales. > **Hoja de requisitos de infraestructura: piloto de mantenimiento (ficticio)** > > - **Acceso al modelo:** El equipo de plataforma opera un modelo aprobado sin respaldo sin probar. Si el modelo no está disponible, la solicitud queda como "pendiente" y el operador de mantenimiento la atiende manualmente. *Prueba:* desactiva el modelo en un entorno de prueba y confirma que la solicitud aparece como pendiente. > - **Entorno de ejecución del agente:** Lo opera quien administra la aplicación. El agente revisa la solicitud frente a las categorías aprobadas y prepara un borrador; nunca modifica el registro de mantenimiento. Si una tarea se interrumpe a mitad de camino, queda marcada como incompleta hasta que el operador la revise. *Prueba:* interrumpe una tarea y confirma que no pueda pasar por terminada. > - **Conocimiento y herramientas:** El equipo de mantenimiento es responsable de la guía de categorías y el agente solo puede leer la versión aprobada. Si la guía falta, está desactualizada o bloqueada, el agente se detiene y pide atención manual. *Prueba:* intenta usar una versión antigua, una guía ausente y acceso bloqueado. > - **Trabajo en curso y resultados:** Los borradores quedan como "pendientes" hasta que el operador los acepta y solo el equipo de mantenimiento puede verlos. *Prueba:* interrumpe un guardado, inicia sesión como segundo usuario y revisa qué puede ver. > - **Reglas de recuperación:** El agente reintenta una vez cuando una llamada al modelo falla claramente. Si no puede saber si un paso terminó, se detiene y el operador revisa antes de repetir nada. *Prueba:* simula una respuesta lenta y confirma que el agente se detiene en lugar de repetir. > - **Uso y costo:** La persona responsable del presupuesto del piloto registra por separado los cargos del modelo, de otros servicios y el tiempo de revisión del personal. El uso faltante se informa como faltante, nunca como cero. *Prueba:* envía una solicitud que deba activar la advertencia presupuestaria y confirma que ocurra. Que una parte funcione no hace que toda la tarea funcione. Conserva la hoja aprobada con los resultados del piloto para que la siguiente persona operadora vea qué se pretendía y qué se comprobó. ## Diseña el piloto con resultados observables Elige casos representativos antes de ajustar la infraestructura: una solicitud clara, otra con dos categorías, una sin ubicación y una dependencia no disponible. Registra el tiempo de finalización, la utilidad del borrador y el costo de la tarea completa. Explicita las limitaciones si los registros de uso solo cubren parte del recorrido. Después determina si necesitas trabajar en la [conmutación entre proveedores](/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm), la [responsabilidad del despliegue](/es/conocimiento/fundamentos-de-ia/opciones-de-despliegue-de-llm) o la [diferencia entre una pasarela y una plataforma de agentes](/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes). Cuando compares costos operativos, cuenta los intentos fallidos y el tiempo que las personas dedican a corregir resultados, no solo los precios de los modelos. La [hoja de costo por tarea completada](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos#calcula-el-costo-por-tarea-completada) muestra cómo hacerlo. Los presupuestos son otra cuestión: limitan el gasto, mientras esta hoja te indica lo que realmente cuesta un resultado útil. > **En AgentShelf** > > La [descripción de infraestructura](/es/technology/infrastructure) explica los servicios gestionados y el acceso a modelos configurados. La disponibilidad depende de la configuración, las credenciales, la región, el plan y el catálogo. Consulta el [entorno de ejecución para desarrolladores](/es/technology/developer-runtime) y los [controles de gobernanza y costos](/es/platform/governance-cost-controls) para conocer las opciones admitidas, los presupuestos monetarios y los límites de su cobertura. ### Infraestructura para LLM: gestionada, híbrida u on-premise - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/opciones-de-despliegue-de-llm - Language: es - Description: Compara opciones de despliegue según los datos, la responsabilidad operativa y la recuperación, y distingue la arquitectura general de la oferta del producto. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Elegir infraestructura para LLM implica decidir dónde funciona cada parte y quién la mantiene. Gestionada, híbrida y on-premise son enfoques útiles, pero una etiqueta arquitectónica no identifica por sí sola el destino de instrucciones, archivos, resultados de herramientas o registros operativos. Dibuja por separado el servicio del modelo, el entorno del agente, los almacenes de datos y las conexiones con herramientas. Después marca cada límite que atraviesa la tarea. ![Tres enfoques muestran servicios gestionados, responsabilidades repartidas entre nube y entorno local, y componentes locales operados por el cliente.](/content/knowledge/visuals/es-llm-deployment-options.svg) *Define dónde se ejecutan el modelo, el entorno, los datos y los registros antes de elegir una etiqueta.* ## Compara cinco opciones de despliegue Cada opción reparte el trabajo entre tu equipo y tus proveedores. También pueden combinarse: un agente que ejecutas tú puede llamar a un modelo en la nube y un modelo que alojas tú puede estar en servidores alquilados. | Opción | Dónde se ejecuta el modelo | Quién lo mantiene en funcionamiento | Costos que debes planificar | | --- | --- | --- | --- | | Servicio de modelo gestionado | Los servidores del proveedor, con los modelos que ofrece. | El proveedor opera el modelo. Tu equipo aún controla quién lo usa y qué hace el agente. | Cargos de uso, límites de uso, regiones permitidas y un respaldo si el modelo no está disponible. | | Modelo alojado por un proveedor de nube | La plataforma de tu proveedor de nube. | Compartida. El contrato determina quién hace qué. | Compromisos de capacidad, redes y conservación de registros. | | Modelo autogestionado | Servidores que alquilas o posees. | Tu equipo: ejecutar, actualizar y restaurar el modelo. | Servidores, escalado, almacenamiento, supervisión y tiempo del personal. | | Híbrido | Algunas partes en tu entorno y otras fuera. | Varios responsables que deben coordinar acceso, redes, transferencias de datos e incidentes. | Demoras y cargos de transferencia entre entornos y dónde irá el trabajo si falla un enlace. | | En instalaciones propias | Tu propio centro de datos. | Tu equipo: capacidad, actualizaciones, acceso, supervisión y recuperación. | Margen de hardware, mantenimiento, energía, instalaciones y el hardware que necesita el modelo elegido. | Cuando alguien diga «on-premise», pregunta qué incluye: el modelo, el agente, los datos almacenados, los registros de actividad o todo el trayecto de una solicitud. Un modelo local no mantiene los datos locales si las herramientas del agente siguen llamando a servicios externos. Una plataforma de despliegue puede cubrir solo parte de este trabajo. Pregunta qué configura, actualiza, escala, registra y restaura por ti. Más opciones no significan menos trabajo para tu equipo. ## Decide cuándo conviene el despliegue local El despliegue en instalaciones propias tiene sentido cuando un requisito escrito, como dónde deben permanecer los datos, una conectividad poco fiable o una regla operativa, exige sistemas locales y tienes un equipo que los opere. Comprueba que un modelo aprobado funcione con el hardware que tienes y decide cómo lo actualizarás y probarás. Antes de comprometerte, sigue el trayecto de los datos en una solicitud normal y durante un fallo. Nombra quién resuelve problemas de hardware y decide cómo seguirá trabajando la gente cuando falte capacidad. El lugar donde se ejecuta un sistema no lo vuelve, por sí solo, compatible ni rápido. ## Planifica más allá del modelo Ejecutar un modelo es solo una parte de un agente. El agente también necesita información aprobada, permiso para usar sus herramientas, una forma de seguir el trabajo en curso, un punto donde una persona revise el resultado y reglas seguras para recuperarse de un fallo. La [hoja de requisitos de infraestructura](/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm) enumera estas partes para que detectes lo que falta antes de comparar precios de alojamiento. ## Empieza por el recorrido de los datos Para una tarea representativa, enumera: 1. Los documentos de entrada y dónde se cargan. 2. El contexto preparado para el modelo, incluidos los resultados de herramientas. 3. Dónde se realiza la inferencia. 4. Qué sistemas puede consultar o modificar el agente. 5. Dónde se conservan conversaciones, resultados y registros operativos. Revisa la ruta habitual y las alternativas. Aprobar la ubicación principal no aprueba automáticamente un destino de respaldo. Utiliza la [guía de revisión de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes) para convertir el mapa en preguntas para cada responsable. ## Ejemplo: un piloto de operaciones financieras Un equipo financiero ficticio quiere que un agente redacte explicaciones internas de diferencias de conciliación. El primer piloto usa registros inventados y produce borradores para revisión. Antes de utilizar registros reales, el equipo identifica el destino del modelo, el entorno de ejecución, el almacén de referencia y los registros operativos. Compara tres propuestas con la misma tarea. Para cada una, pregunta quién puede actualizar el entorno, restablecer el acceso a los datos de referencia, investigar un borrador incompleto y sustituir un modelo no disponible. También comprueba si el modelo necesario puede funcionar con la capacidad propuesta. El documento de decisión recoge la ruta de datos aprobada, los responsables, el esfuerzo operativo y las preguntas pendientes. Elegir una opción de despliegue no satisface por sí solo a un regulador. Para conocer el contexto del producto, consulta [agentes de IA en servicios financieros](/es/finance/financial-services-ai-agents). ## Incluye el costo de operar la opción elegida Compara el uso del modelo con el resto del trabajo: capacidad de cómputo, almacenamiento, conectividad, supervisión, actualizaciones y tiempo del personal. La infraestructura operada por el cliente necesita mantenimiento; un servicio gestionado sigue requiriendo que tu equipo configure el acceso y evalúe su adecuación. Prueba el diseño ante una dependencia no disponible y una actualización programada. Define quién decide si el piloto puede reanudarse. Un despliegue que parece sencillo en un diagrama puede requerir una coordinación compleja durante un incidente. El tiempo de preparación depende de lo que siga abierto: acceso a fuentes, inicio de sesión y redes, pruebas del modelo, pruebas de conexión y recuperación, y capacitación de quienes lo operarán. Estima esos pasos para tu tarea en vez de adoptar un plazo genérico. ## Vincula la arquitectura con una oferta documentada Pide al proveedor que identifique por escrito los componentes admitidos, las obligaciones del cliente, los destinos de datos y el comportamiento de recuperación. Separa las ideas arquitectónicas opcionales de los despliegues que se ofrecen actualmente. > **En AgentShelf** > > La oferta documentada incluye [servicios gestionados por AgentShelf](/es/technology/infrastructure) y [entornos admitidos gestionados por el cliente o externos](/es/technology/developer-runtime). Son el punto de partida adecuado para una evaluación. Si necesitas una solución híbrida o completamente en instalaciones propias, confirma con AgentShelf qué está disponible para tus requisitos antes de planificar con esa opción. Continúa con los [fundamentos de infraestructura para LLM](/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm) y [espacios de trabajo y agentes externos](/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos) para distinguir los componentes y sus vínculos. ### ¿Qué es un agente de IA? - Route: https://agentshelf.ai/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia - Language: es - Description: Un agente de IA combina un modelo, herramientas y reglas definidas para avanzar hacia un objetivo, comprobar resultados y derivar el trabajo cuando hace falta. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente de IA combina un modelo, herramientas y reglas definidas para avanzar hacia un objetivo, comprobar resultados y derivar el trabajo cuando hace falta. El modelo aporta razonamiento y resultados; el flujo que lo rodea determina qué información y acciones tiene disponibles. ## Ejemplo: preparar la revisión de incorporación de un proveedor Northstar Supplies envía un expediente de incorporación. El equipo de compras pide: «Prepara una revisión de incorporación con el expediente, la lista de verificación aprobada y la ficha actual del proveedor. Señala la evidencia que falta y redacta una solicitud de documentos para que alguien la revise. No apruebes al proveedor ni envíes ningún mensaje». El agente consulta únicamente esas tres fuentes. Compara el expediente con la lista, contrasta los datos pertinentes con la ficha actual, identifica la información que falta y prepara un borrador para el equipo de compras. El ejemplo es ficticio e ilustra el tipo de resultado esperado; no corresponde a un proveedor real. > **Northstar Supplies — borrador de incorporación** > > - **Hallazgo:** Falta un certificado de seguro vigente en el expediente de incorporación. > - **Solicitud propuesta:** «Envíenos un certificado de seguro vigente para que el equipo de compras pueda continuar la revisión». > - **Decisión:** El proveedor aún no está aprobado; el equipo de compras debe revisar el borrador. La acción útil del agente consiste en preparar un borrador respaldado por la evidencia. Si una fuente no se puede leer o hay datos contradictorios, debe indicar qué no pudo verificar y derivar el caso para su revisión. > **Regla de revisión:** La aprobación y el envío quedan a cargo de una persona. ![Ciclo ilustrativo del agente para la solicitud de Northstar Supplies, con una rama de información faltante que deriva el caso a revisión humana](/content/knowledge/visuals/es-what-is-an-ai-agent.svg) *El agente completa la revisión cuando la evidencia es clara. Si falta información, hace otra comprobación o deriva el caso a una persona.* ## ¿Qué hace que sea un agente? - **Trabajo:** Preparar una revisión. - **Contexto:** Usar el expediente, la lista y la ficha aprobados. - **Herramientas:** Determinar qué puede leer o cambiar el sistema. - **Reglas:** Describir cómo manejar la evidencia faltante y cuándo detenerse. En conjunto, estos elementos permiten que el sistema elija el siguiente paso dentro de una tarea acotada. Un modelo por sí solo podría resumir el formulario presentado. Una automatización fija podría comprobar si están todos los archivos requeridos. El agente del ejemplo compara evidencia entre las fuentes permitidas y adapta el borrador según lo que encuentra. Esa flexibilidad requiere permisos claros y una forma de comprobar el resultado. ## Cuándo conviene este patrón Usa un agente cuando: - La solicitud varía. - El siguiente paso depende de lo que indiquen las fuentes aprobadas. - Una persona puede revisar el resultado o resolver las excepciones. Un flujo fijo o una llamada directa a un modelo pueden ser más fáciles de definir cuando la secuencia no cambia o solo hay que transformar un elemento. Antes de permitir que un agente realice una acción de consecuencias importantes, define: - Quién se hace cargo de los casos sin resolver. - Qué datos deben verificarse. - Qué acciones no debe realizar bajo ninguna circunstancia. Para compararlo con los chatbots y la automatización, consulta [agente de IA, chatbot o automatización](/es/conocimiento/fundamentos-de-ia/agente-de-ia-vs-chatbot-vs-automatizacion). Para conocer los componentes del sistema, sigue con [la arquitectura de un agente de IA](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia) y [el entorno de control de un agente](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente). ### Glosario de agentes de IA - Route: https://agentshelf.ai/es/conocimiento/glosario - Language: es - Description: Definiciones en lenguaje sencillo de agentes, harnesses, contexto, herramientas, permisos y conceptos operativos, con enlaces a guías más detalladas. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Usa estas definiciones como referencia para leer y conversar sobre diseños de agentes. La terminología varía según el sistema; si un término afecta una implementación, consulta la documentación del producto correspondiente. ![Cuatro grupos de términos conectados: Sistema, Información, Acciones y Supervisión.](/content/knowledge/visuals/es-glossary.svg) Explora los grupos: [Sistema](#sistema) · [Información](#informacion) · [Acciones](#acciones) · [Supervisión](#supervision). ## Sistema ### Agente de IA **Concepto general.** Sistema que utiliza un modelo para elegir y realizar pasos hacia un objetivo dentro de límites configurados. La interfaz puede ser conversacional, pero eso por sí solo no determina si el sistema es un agente. Consulta [¿qué es un agente de IA?](/es/conocimiento/fundamentos-de-ia/que-es-un-agente-de-ia). ### Harness del agente **Concepto general y de producto en AgentShelf.** Configuración que proporciona al modelo instrucciones, contexto, capacidades y reglas de operación para una tarea. Cada sistema puede incluir responsabilidades distintas bajo este término. Consulta la [guía del harness](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente) y la [descripción del harness de AgentShelf](/es/platform/agent-harness). ### Entorno de ejecución del agente (runtime) **Concepto general.** Entorno en el que se realiza el trabajo del agente, por ejemplo, coordinando solicitudes, llamadas a herramientas y resultados. El entorno de ejecución lleva a cabo el comportamiento; la descripción de la tarea explica qué debe conseguir ese comportamiento. Consulta la [arquitectura del agente](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). ### Espacio de trabajo dedicado **Concepto de producto de AgentShelf con un significado más amplio en el sector.** AgentShelf usa este término para el espacio donde una persona gestiona el contexto, las herramientas, las conversaciones, los resultados y la actividad disponible de un agente. No deduzcas garantías de aislamiento de acceso o retención únicamente por el término. Consulta la [descripción del producto](/es/platform/agent-harness) y la [documentación sobre espacios de trabajo](/docs/es/workspaces). ### Agente externo **Término de la documentación de AgentShelf.** Agente disponible para una aplicación externa mediante la interfaz de integración documentada. Consulta la [documentación para desarrolladores](/docs/es) sobre la configuración y el ciclo de vida admitidos. ### Sesión **Concepto general cuyo comportamiento depende de la implementación.** Una sesión permite que el sistema mantenga la continuidad entre interacciones. Su duración, almacenamiento y reglas de identidad dependen de la implementación y pueden ser distintos de los de una sesión del navegador. Consulta [sesiones y almacenamiento](/docs/es/sessions-and-storage). ## Información ### Contexto aprobado **Término editorial de trabajo.** Información seleccionada y autorizada para una tarea y un público concretos, como una descripción de servicio aprobada. La aprobación requiere una persona responsable y un alcance; no significa que la fuente siga siendo precisa para siempre. Consulta [conocimiento y herramientas](/es/conocimiento/conocimiento-y-herramientas). ### Fundamentación en conocimiento **Concepto general.** Relación de una respuesta o decisión con evidencia pertinente, proporcionada o recuperada. La fundamentación ayuda a inspeccionar el resultado, pero aún hay que evaluar su pertinencia y fidelidad. Consulta [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones). ### Memoria del agente **Concepto general.** Información conservada o recuperada para mantener la continuidad entre pasos o interacciones. El contexto de una conversación y el almacenamiento persistente son mecanismos diferentes; comprueba qué guarda la implementación, para quién y durante cuánto tiempo. Consulta la [arquitectura](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia). ### Referencia pública **Término de la documentación de AgentShelf.** Referencia que se utiliza en el flujo de integración de agentes externos para identificar una superficie pública configurada para el agente. No autentica a la persona ni autoriza una acción. La credencial de arranque es distinta: el servidor la usa para firmar la aserción. Consulta [primeros pasos](/docs/es/getting-started) para conocer el uso exacto y [referencias públicas y arranque seguro](/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro) para entender el límite entre ambas. ### Artefacto **Concepto general cuyo comportamiento depende de la implementación.** Resultado producido, a menudo un archivo u otro elemento al que se puede acceder por separado. Su disponibilidad y sus reglas de acceso dependen del sistema. Consulta [archivos y resultados](/docs/es/files-and-artifacts). ## Acciones ### Habilidad (skill) **Término editorial de trabajo alineado con el contenido de AgentShelf.** Instrucciones o métodos reutilizables para una clase de trabajo, como un procedimiento de investigación. Una habilidad describe un método; una herramienta proporciona una capacidad. La forma de empaquetarlas depende del producto. Consulta la [comparación de recursos](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones). ### Llamada a herramientas **Concepto general.** El modelo solicita una capacidad definida y el sistema circundante decide si debe ejecutarla y cómo hacerlo. Una acción solicitada y una acción completada son estados distintos. Consulta [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). ### Conexión **Término editorial de trabajo alineado con el contenido de AgentShelf.** Vía configurada hacia un recurso o sistema externo. Puede incluir una API, credenciales, un conector o MCP. La existencia de una conexión no determina qué acciones puede realizar una persona. Consulta la [descripción de conexiones de AgentShelf](/es/platform/knowledge-tools-automation). ### Herramienta MCP **Concepto general de integración.** Capacidad invocable que se ofrece mediante el Model Context Protocol (MCP). Evalúa por separado el servidor, la capacidad, los datos intercambiados y los permisos; el nombre del protocolo no constituye una decisión de confianza. Consulta [conocimiento y conexiones](/es/conocimiento/conocimiento-y-herramientas) y [permisos](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). ### Resultado estructurado **Concepto general.** Resultado organizado según un formato o conjunto de campos previsto. Una estructura correcta facilita la inspección y el procesamiento posterior, pero no demuestra que los valores sean correctos. Consulta [cómo definir el trabajo de un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada). ## Supervisión ### Supervisión humana (human-in-the-loop) **Concepto general.** Diseño de flujo de trabajo en el que una persona revisa, aprueba, corrige o asume el control en puntos definidos. Indica quién es responsable y qué ocurre mientras se espera la revisión. Consulta [aprobaciones, transferencias y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes). ### Transferencia del agente **Concepto general de flujo de trabajo.** Traspaso de responsabilidad y contexto pertinente a una persona, otro agente o un sistema. Usa «derivación a una persona» cuando alguien asume el trabajo y «transferencia entre sistemas» cuando pasa de un sistema a otro. Define quién lo acepta y cómo detectar un traspaso incompleto. Consulta [revisión humana y transferencias](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes). ### Observabilidad del agente **Concepto operativo general.** Posibilidad de inspeccionar evidencia de la ejecución, como resultados, errores, actividad de herramientas y uso. Decide qué registros son necesarios sin suponer que hay que conservar todas las interacciones. Consulta [gobernanza y controles de costos](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos). ### IA en la sombra (Shadow AI) **Término organizacional general.** Uso de IA fuera de los procesos aprobados o visibles de una organización. Evalúa tanto la necesidad del flujo de trabajo como el acceso y la rendición de cuentas. Consulta la [guía de gobernanza](/es/conocimiento/gobernanza-de-ia) como punto de partida. ## Sigue aprendiendo Vuelve a los [fundamentos](/es/conocimiento/fundamentos-de-ia) para repasar el modelo general, o aplica los términos a una tarea concreta en la sección de [diseño de agentes](/es/conocimiento/diseno-de-agentes). ### Gobernanza, evaluación y costos de los agentes de IA - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia - Language: es - Description: Planifica cómo evaluar un agente de IA, definir sus permisos y límites de operación, y decidir cuándo necesita revisión humana. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Antes de iniciar una prueba piloto, asigna a alguien responsable del agente y decide quién puede usarlo, a qué puede acceder, qué resultados necesitan revisión y cuándo detenerlo. Conserva evidencia que otra persona pueda comprobar. Estas decisiones son la base de la gobernanza. ![Ciclo de supervisión en seis pasos, con una persona responsable de la decisión.](/content/knowledge/visuals/es-governance.svg) Esta ruta ayuda a quienes dirigen pilotos y operaciones, así como a las personas revisoras. Las guías ofrecen preguntas y plantillas de trabajo; la documentación de los sistemas que uses describe su comportamiento específico de control. ## Prepárate para decidir sobre el piloto 1. [Evalúa el agente antes de ponerlo en producción](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). Define casos representativos, resultados esperados y criterios de lanzamiento antes de evaluar el piloto. 2. [Revisa los permisos y los límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). Comprueba por separado el acceso a la información y la autoridad para realizar acciones. 3. [Diseña la revisión humana](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes). Identifica a quien revisará el trabajo y define cómo se pausa o se escala. 4. [Planifica la gobernanza y los controles de costos](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos). Asigna responsabilidades por el uso, los gastos, los cambios y los incidentes. ## Lleva un registro breve de las decisiones Un registro práctico identifica el agente y su versión, la persona responsable de la tarea, las fuentes y acciones permitidas, la evidencia de evaluación, los límites conocidos y quién aceptó el alcance del piloto. Añade la fecha de la próxima revisión y una manera de detener el flujo de trabajo. Por ejemplo, un piloto acotado de preguntas y respuestas sobre políticas internas podría registrar lo siguiente: - **Responsable:** La persona responsable de las políticas mantiene las fuentes aprobadas y revisa las excepciones. - **Evidencia de evaluación:** Incluye preguntas respondidas por la política vigente, una fuente faltante y versiones contradictorias. Continúa solo si las respuestas respaldadas citan una fuente vigente y los demás casos se derivan claramente. Consulta la [guía de evaluación](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). - **Permisos:** Lectura de material aprobado para esta tarea; sin acceso a expedientes de empleados ni permiso para editarlos. Revisa el límite con la guía de [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). - **Límite y decisión:** Solo se preparan borradores de explicaciones. Si falta evidencia o hay conflictos, se pausa el trabajo y se deriva la consulta a la persona responsable. El piloto se mantiene dentro de este alcance hasta que esa persona revise los resultados. No reduzcas los problemas de calidad, gastos y permisos a una sola puntuación general. Una ejecución económica aún puede producir una respuesta inútil; una respuesta convincente aún puede exceder la autoridad del flujo de trabajo. Define un criterio de decisión propio para las infracciones graves de los límites. ## Revisa después de un cambio importante Vuelve a examinar la evidencia cuando cambien las instrucciones, las fuentes, los modelos, las herramientas o los accesos. Repite los casos afectados por el cambio y conserva suficiente contexto para explicar la decisión. Para consultar las descripciones de producto de AgentShelf, visita las páginas sobre [límites de confianza](/es/platform/trust-boundaries) y [gobernanza y controles de costos](/es/platform/governance-cost-controls). Vuelve al [diseño de agentes](/es/conocimiento/diseno-de-agentes) cuando haya que modificar la tarea. ## Usa agentes para la ciberdefensa La [ruta de ciberdefensa](/es/conocimiento/ciberdefensa-con-ia) aplica estos controles de responsabilidad y permisos al trabajo defensivo. Empieza por [una ficha de tarea defensiva](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) y elige la exposición que investigarás. ## Todas las guías de este tema - [Evalúa un agente de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia): Evalúa un agente con tareas representativas, uso de herramientas, manejo de fallos y límites de aprobación antes de ampliar su acceso. - [Permisos y límites de los agentes de IA](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes): Define los límites de un agente según su identidad, la información, las capacidades, el entorno y la supervisión; comprueba cada límite en los sistemas conectados. - [Gobernanza y control de costos para agentes de IA](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos): Gobierna un agente al asignar una persona responsable, limitar datos y acciones, revisar resultados y medir el costo por tarea completada y revisada por una persona. - [Define quién puede usar y ver el trabajo de un agente](/es/conocimiento/gobernanza-de-ia/control-de-uso-y-visibilidad): Separa los límites de audiencia, del espacio de trabajo y de administración para que las personas invoquen, mantengan y revisen un agente en el contexto adecuado. - [Fallos de un agente de IA y cómo recuperarse](/es/conocimiento/gobernanza-de-ia/fallos-de-agentes-y-recuperacion): Diagnostica los fallos a partir de la evidencia y elige entre un reintento acotado, una corrección, una detención segura o la derivación a una persona. - [Gestiona el uso de IA no aprobado en tu equipo](/es/conocimiento/gobernanza-de-ia/gestion-del-uso-de-ia-no-aprobado): Haz visible el uso de IA con pautas claras, una vía segura para pedir ayuda, una revisión de riesgos proporcional y una forma aprobada de realizar el trabajo útil. - [Gestiona los cambios de agentes con revisión y reversión](/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes): Registra los cambios en instrucciones, fuentes, herramientas, modelo y acceso, y vuelve a probar los casos afectados antes de ampliar el uso. - [Lista de control de gobernanza para equipos](/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza): Asigna a cada flujo de un agente una persona responsable, un alcance aprobado, una ruta de revisión, un contacto operativo y una decisión para cambiarlo o detenerlo. - [Lista de control para revisar la seguridad de un agente de IA](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes): Revisa las personas usuarias, los flujos de información, las identidades, las herramientas, las dependencias, las pruebas y las personas responsables de responder antes de ampliar el uso o el acceso de un agente. - [Observabilidad de un agente de IA: qué registrar](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes): Registra la actividad del flujo, los errores, las derivaciones y las señales de recursos para que una persona responsable pueda investigar una ejecución y decidir qué revisar. - [Revisa las herramientas y el acceso a datos de un agente](/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos): Inspecciona cada herramienta conectada: su identidad, alcance de datos, operaciones permitidas, efectos, información devuelta y comportamiento ante fallos. - [Cómo establecer presupuestos para LLM](/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm): Planifica presupuestos monetarios, la cobertura de solicitudes compatibles y la revisión del gasto. - [Comparte agentes de IA entre equipos con reglas de acceso](/es/conocimiento/gobernanza-de-ia/compartir-agentes-entre-equipos): Distingue propuestas, aprobación de responsables, alcance de la biblioteca y permisos sobre los datos. ### Cómo compartir agentes de IA entre equipos con reglas de acceso - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/compartir-agentes-entre-equipos - Language: es - Description: Comparte agentes mediante propuestas, aprobación y disponibilidad por organización o equipo, con revisión separada de acceso a datos y responsabilidad operativa. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Compartir un agente de IA entre equipos requiere decidir su audiencia, obtener aprobación y revisar por separado información y acciones permitidas. En AgentShelf, cualquier persona puede presentar un agente a una biblioteca de organización o equipo. Los responsables de la organización o del equipo examinan la propuesta y aprueban cuáles se incluyen. ![Un responsable revisa la propuesta y aprueba disponibilidad organizativa o solo para integrantes del equipo; el acceso a datos se comprueba aparte.](/content/knowledge/visuals/es-share-ai-agents-across-teams.svg) *Aprueba la audiencia deliberadamente y verifica el acceso a fuentes como límite separado.* ## Elige la audiencia antes de presentar la propuesta Un agente aprobado de organización está disponible para toda ella. Uno aprobado de equipo solo está disponible para sus integrantes. Elige según quién debe utilizarlo, no simplemente según quién ayudó a crearlo. Si sirve a varios equipos de la misma organización, el alcance organizativo puede encajar cuando el trabajo sea adecuado para toda ella. Si pertenece a un solo equipo, preséntalo para ese equipo. Acuerda la audiencia con los responsables antes de presentar un agente de equipo como si estuviera disponible para más personas. Estas reglas cubren el uso compartido dentro de una organización, no entre organizaciones. Consulta [qué es una biblioteca de agentes de IA](/es/conocimiento/casos-de-uso/que-es-una-biblioteca-de-agentes) para distinguir colecciones públicas e internas. El descubrimiento, por ejemplo en la [biblioteca de agentes de AgentShelf](/es/discover), encuentra candidatos; la aprobación interna decide cuáles pertenecen a tu colección. ## Presenta una descripción que pueda revisarse Aporta evidencia suficiente para evaluar el flujo. Una descripción breve como esta le da a quien revisa lo que necesita: | Elemento | Qué debe conocer quien revisa | | --- | --- | | Trabajo y audiencia | Quién necesita el agente y qué resultado prepara | | Fuentes | Qué información está aprobada y quién puede acceder | | Acciones | Qué puede hacer el flujo y dónde decide una persona | | Pruebas | Cómo trata evidencia ausente, contradicciones y solicitudes fuera de alcance | | Responsabilidad | Quién atiende excepciones y mantiene la guía | | Costo | Quién controla la asignación y revisa el uso | Un prompt reutilizable puede dejar estas decisiones abiertas. Vincula la descripción con la [revisión de permisos](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y el registro presupuestario antes del uso habitual. ## Sigue propuesta, aprobación y disponibilidad 1. **Presentar:** Una persona propone el agente para la biblioteca de organización o equipo con uso previsto y evidencia. 2. **Examinar:** El responsable comprueba tarea, audiencia, límites y responsabilidad. Resuelve carencias antes de aprobar. 3. **Aprobar:** El responsable decide si se incluye la propuesta. 4. **Verificar disponibilidad:** Comprueba disponibilidad organizativa o restricción a integrantes del equipo, según el alcance aprobado. 5. **Revisar operación:** Confirma fuentes y acciones con usuarios previstos; revisa de nuevo tras cambios materiales. Aprobar un agente no concede acceso a todos los conjuntos de datos subyacentes. Verifica fuentes y autoridad sobre herramientas por separado. Este proceso tampoco determina quién puede editar un agente aprobado; confirma esa responsabilidad mediante el procedimiento de gestión aplicable. ## Aplica las reglas a un flujo ficticio Beacon Works tiene equipos de ventas y servicio que quieren un esquema común para reuniones con clientes. El trabajo usa una plantilla general aprobada y produce un borrador para quien dirige la reunión. Una persona propone disponibilidad organizativa porque el esquema es útil para toda Beacon Works. El responsable revisa trabajo y pruebas. Un ejemplo de ventas contiene notas privadas de acuerdos y uno de servicio incluye registros restringidos. Pide separar la estructura reutilizable del acceso a esos registros. Compartir el agente no hace que los datos de cada equipo estén disponibles para el otro. El piloto recomendado incluye una persona autorizada de cada equipo y verifica qué fuentes puede aportar o leer. El responsable aprueba la inclusión cuando el trabajo y los límites están claros. Si el agente solo sirve al proceso de ventas, lo adecuado es proponerlo para ese equipo. ## Preguntas que debes hacer a cualquier plataforma para compartir agentes «Compartir» no es un solo permiso. Abarca quién puede usar un agente, a qué información puede acceder, quién lo aprueba y quién se ocupa de él. Pregunta a cada plataforma cómo trata las cuestiones siguientes. La tercera columna muestra cómo las responde AgentShelf hoy. | Pregunta | Por qué importa | Cómo lo gestiona AgentShelf | | --- | --- | --- | | ¿Quién puede usar un agente aprobado? | La audiencia debe coincidir con el trabajo. | La aprobación organizativa pone un agente a disposición de toda la organización. La aprobación de equipo lo pone a disposición de ese equipo únicamente. | | ¿Quién decide qué se añade? | Alguien tiene que respaldar cada agente. | Cualquier persona puede presentar una propuesta. Los responsables de la organización y del equipo revisan las propuestas y deciden qué se añade. | | ¿Puede cada departamento conservar sus propias reglas de datos? | Los agentes compartidos no deben ampliar el acceso a los datos. | Poner un agente a disposición no cambia quién puede ver los datos. Cada fuente conserva sus propios permisos, así que revísalos para cada equipo. | | ¿Quién puede cambiar el agente y cómo se revisan los cambios? | Un cambio puede interrumpir el trabajo de todos los equipos que lo usan. | Define quién puede editar el agente y cómo se prueban los cambios como parte de la aprobación, y regístralo con el agente. | | ¿Puedes ver cómo se está usando? | Las personas responsables deben detectar problemas y costos. | Los informes de uso y costos muestran el gasto por modelo, agente y espacio de trabajo cuando se registran esos datos. Decide quién de tu equipo los revisa. | | ¿Puede utilizarlo otra organización? | Compartir fuera de la empresa es una decisión aparte. | La aprobación de la biblioteca cubre solo tu propia organización. | Para una plantilla que usa datos de una unidad de negocio, resuelve dos cosas por separado: quién puede usar la plantilla y qué datos puede leer cada persona. Pruébala con una persona usuaria real de cada equipo antes de lanzarla. ## Compartir un agente no es compartir sus resultados Compartir un agente decide quién puede *usarlo*. Compartir un informe terminado o un conjunto de notas decide quién puede *ver* ese resultado. Uno no implica el otro. Antes de compartir resultados, comprueba quiénes son las personas destinatarias y si la información de origen está restringida. [Espacios de trabajo y agentes externos](/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos) explica la configuración más amplia. ## Mantén una responsabilidad después de aprobar La aprobación es el inicio de la vida operativa de un agente, no el final de la revisión. Conserva un registro breve de mantenimiento con cada agente aprobado. La persona encargada del mantenimiento puede pedir al agente que redacte actualizaciones a partir de sus resultados recientes y de los problemas que informan las personas usuarias, y luego confirmar el registro. > **Registro de mantenimiento de un agente compartido (en blanco)** > > - Agente y audiencia aprobada (organización o equipo): ___ > - Persona encargada del mantenimiento y responsable que lo aprobó: ___ > - Información que usa y acciones que puede realizar: ___ > - Última revisión: fecha, cambios, pruebas realizadas y preguntas pendientes: ___ > - Dónde informan las personas usuarias de un mal resultado y quién puede pausar el agente: ___ > - Qué activa la próxima revisión (un cambio de fuente o política, una audiencia nueva, una prueba fallida o correcciones repetidas): ___ > - Quién decide retirarlo y dónde acuden las personas usuarias en su lugar: ___ Para el esquema de reuniones de Beacon, la persona encargada del mantenimiento revisa cada nueva versión de la plantilla, mientras cada equipo revisa sus propios registros restringidos. Si se le pidiera al agente que *enviara* los seguimientos en lugar de redactarlos, sería una nueva decisión sobre su autoridad y volvería al responsable. La retirada es una decisión que tu equipo toma y registra. Identifica quién recibe avisos de problemas y presenta cambios al responsable correspondiente. Revisa la audiencia cuando cambien integrantes, tarea, fuentes o acciones. Mantén accesibles la descripción vigente y las pruebas. Antes de ampliar la reutilización, verifica audiencia, aprobación, fuentes, acciones, responsable y presupuesto. Consulta [gestión de cambios](/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes) y los [límites de confianza de AgentShelf](/es/platform/trust-boundaries) para el contexto actual del producto. ### Define quién puede usar y ver el trabajo de un agente - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/control-de-uso-y-visibilidad - Language: es - Description: Separa los límites de audiencia, del espacio de trabajo y de administración para que las personas invoquen, mantengan y revisen un agente en el contexto adecuado. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Decide quién puede usar el agente, quién puede ver su contexto y sus resultados y quién puede configurarlo o revisarlo. Comprueba por separado el acceso a la experiencia pública, al espacio de trabajo y a la administración, además de los permisos del agente para usar herramientas o cambiar registros. ## Sigue una consulta de soporte por tres contextos Supongamos que un equipo de soporte ofrece un agente público para consultas básicas. La política pública aprobada para devoluciones indica que se debe solicitar una etiqueta mediante el formulario de soporte antes de enviar el artículo. Una nota privada de soporte dice que la cuenta de esta persona tiene una excepción de devolución sin resolver. Una persona especialista puede consultar esa nota en el espacio de trabajo del equipo; no debe aparecer en una respuesta pública. Una persona administradora gestiona los ajustes y el acceso de ambas experiencias. La respuesta para la página pública podría ser: > «Para solicitar una etiqueta de devolución, envía el formulario de soporte antes de enviar el artículo. Para recibir ayuda con tu cuenta, comunícate con una persona especialista de soporte». Por separado, quien realiza la revisión interna registra que la respuesta usa solo la política pública aprobada. La excepción privada queda disponible únicamente para una persona especialista autorizada en el espacio del equipo. La respuesta al visitante no incluye la nota ni revela que existe la excepción. Estas son expectativas de diseño para el ejemplo. Confirma cómo la aplicación real reconoce a cada persona, a qué información puede acceder cada superficie y qué registros puede revisar una persona administradora. ![Tres límites de acceso comprobados por separado: Público, Espacio de trabajo y Administración](/content/knowledge/visuals/es-agent-operating-boundaries.svg) *Comprueba el acceso por separado en la experiencia pública, el espacio del equipo y la administración.* ## Revisa los tres límites operativos | Contexto | Preguntas que conviene responder | Evidencia que se debe examinar | |---|---|---| | Audiencia y superficie | ¿Quién puede iniciar una conversación o enviar trabajo? ¿La experiencia es pública, está integrada en otra aplicación o solo admite personas autenticadas? | Comprobaciones de sesión y origen, ajustes de audiencia, entradas que puede enviar el público e información que la superficie puede devolver. | | Espacio de trabajo | ¿Qué miembros del equipo pueden ver o cambiar el contexto, las conversaciones, los resultados y los materiales de trabajo del agente? ¿Están separados de la experiencia pública? | Integrantes del espacio, responsables de las fuentes, visibilidad de resultados y actividad, y reglas para compartir o exportar. | | Administración | ¿Quién puede configurar instrucciones, fuentes, herramientas, despliegue y acceso? ¿Quién puede consultar registros operativos o cambiar la audiencia? | Roles administrativos, historial de configuración, acceso a sistemas conectados, registros de revisión y proceso para retirar el acceso. | Para cada límite, define quién es responsable y qué debe ocurrir si una persona o solicitud queda fuera de su alcance. Verifica esas expectativas en la interfaz y los sistemas conectados. Que una página parezca privada no demuestra por sí solo que estén restringidas las llamadas a datos o herramientas subyacentes. Una matriz de permisos puede comparar los recursos con las acciones —leer, redactar, actualizar, enviar y aprobar— dentro de cada contexto. Sirve para comprobar qué puede hacer el agente; no representa el acceso a la audiencia, al espacio de trabajo ni a la administración. ## Separa los límites de audiencia de los permisos de acción Un límite de audiencia pregunta quién puede entrar a una experiencia o ver su información. Una revisión de permisos de acción pregunta qué pueden leer, crear, actualizar, enviar o aprobar las herramientas del agente. Ambas cosas se relacionan, pero pueden fallar por separado: una interfaz pública bien delimitada aún podría llamar a una herramienta demasiado potente, mientras que una herramienta de solo lectura podría devolver información a la audiencia equivocada. En el ejemplo de soporte, la persona visitante recibe la respuesta de la política pública, mientras que una persona especialista puede consultar una nota interna en un contexto de trabajo separado. La persona administradora puede gestionar la configuración, pero la visitante no puede cambiarla. Antes de confiar en esa separación, el equipo debe verificar que así funcione la ruta desplegada. Vuelve a trazar los límites si cambian la audiencia, las personas del espacio de trabajo, las fuentes de contexto, la superficie de despliegue o el grupo de administración. Para revisar herramienta por herramienta, continúa con [cómo revisar las herramientas y el acceso a datos de un agente](/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos). Consulta [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) y [la lista de control de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes) para una revisión de acceso más amplia. La descripción pública actual de AgentShelf está en la página de [Confianza y límites](/es/platform/trust-boundaries); confirma el comportamiento del producto según la ruta configurada. ### Evalúa un agente de IA - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia - Language: es - Description: Evalúa un agente con tareas representativas, uso de herramientas, manejo de fallos y límites de aprobación antes de ampliar su acceso. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Una evaluación comprueba si el flujo configurado de un agente cumple su función, usa solo la información y las acciones permitidas y maneja los fallos de forma segura. Por ejemplo, imagina un agente de incorporación de proveedores de Northstar Supplies al que se le pide preparar un informe para Compras a partir de un expediente de incorporación, una lista vigente para incorporar proveedores y la ficha actual del proveedor. Debe señalar la falta de un certificado de seguro y redactar una solicitud para revisión; nunca debe aprobar al proveedor ni enviar la solicitud por su cuenta. ![Cuadro de evaluación ilustrativo de Northstar Supplies con casos rutinarios, falta de evidencia, registros contradictorios y errores de consulta](/content/knowledge/visuals/es-evaluate-an-ai-agent.svg) *Cuadro ilustrativo, no representa resultados medidos.* En este ejemplo: - **Expediente habitual:** Supera las cuatro comprobaciones. - **Falta evidencia:** Produce un borrador útil dentro de sus límites, pero hace falta revisar su procedimiento y recuperación. - **Registros contradictorios:** Falla porque el borrador no resuelve ni remite claramente la discrepancia, aunque respeta los permisos. - **Fallo de herramienta:** No puede completar el informe solicitado, así que el resultado falla. El procedimiento, los límites y la recuperación pasan porque informa del error de consulta y remite el caso de forma segura. Una transferencia segura y una tarea completada son resultados distintos. Para esta decisión ilustrativa: - **Detener:** Una infracción de permisos o un estado desconocido de una acción con efectos secundarios bloquea la ejecución; resuélvelo antes de continuar. - **Corregir:** Una brecha corregible de evidencia o derivación debe corregirse y probarse de nuevo antes de ampliar. - **Ampliar:** Considéralo solo cuando los casos afectados cumplan sus expectativas escritas y la persona responsable acepte la evidencia. **Decisión para estos resultados: corregir antes de ampliar.** El caso de registros contradictorios no deriva con claridad, y el de evidencia faltante requiere revisar el procedimiento y la recuperación. El fallo de herramienta supera las comprobaciones de procedimiento, límites y recuperación aunque el resultado de negocio siga incompleto. ## Define el resultado esperado Antes de probar, anota qué debe incluir una ejecución correcta y qué no debe hacer. En este ejemplo, el agente debe comparar el expediente con la lista, fundamentar cada hallazgo en los materiales proporcionados, señalar el certificado faltante y dejar la aprobación y el envío del mensaje en manos de una persona. Un informe bien redactado que invente evidencia o envíe la solicitud cuenta como una ejecución fallida, aunque parezca convincente. Designa a una persona responsable del flujo de trabajo y a otra que pueda juzgar si el informe es útil. Acuerden qué errores impiden iniciar un piloto, cuáles se pueden gestionar mediante revisión y cuáles conviene registrar. Fijen umbrales acordes con las consecuencias y la capacidad de revisión del equipo. Registra estas expectativas en [una definición concreta del trabajo de un agente](/es/conocimiento/diseno-de-agentes/definir-una-tarea-acotada) para mantener fijos la tarea, la evidencia, las acciones permitidas y las condiciones de parada durante las pruebas. ## Prueba un conjunto representativo Usa un conjunto pequeño de expedientes seguros y representativos: - Uno completo. - Uno al que le falte el certificado. - Uno con datos contradictorios. - Uno con un archivo adjunto ilegible. Registra el resultado esperado para cada expediente y por qué es correcto. Incluye distintas formas de hacer una solicitud y peticiones que queden fuera del trabajo asignado al agente. Usa datos sintéticos o debidamente protegidos en el entorno de prueba. Mantén fija la tarea y los criterios de éxito mientras cambian los expedientes. Así será más fácil detectar si un resultado cambió por la evidencia, las instrucciones o las herramientas configuradas. Repite las ejecuciones cuando una misma entrada pueda producir resultados distintos, y revisa tanto los pasos como el informe final. ## Inspecciona la ejecución y el borrador Comprueba qué fuentes leyó el agente, qué datos extrajo, si usó la consulta permitida y si se detuvo antes de aprobar o enviar algo. Revisa el borrador para detectar datos faltantes, afirmaciones sin respaldo y falta de claridad sobre quién se encarga del siguiente paso. Resultado ilustrativo basado en registros ficticios de Northstar Supplies: > **Borrador de incorporación: Northstar Supplies** > > - **Hallazgo:** Falta un certificado de seguro vigente en el expediente de incorporación. > - **Solicitud en borrador:** «Envíe un certificado de seguro vigente para que el equipo de Compras pueda continuar con la revisión». > - **Decisión:** El proveedor aún no está aprobado; una persona revisora debe aprobar cualquier solicitud que se envíe. Esta muestra no representa un registro real de un proveedor ni un resultado medido de un sistema. En una prueba, confirma que el hallazgo sobre el documento faltante coincida con el expediente y la lista, que el mensaje siga siendo un borrador y que no se haya aprobado ni enviado nada. ## Pon a prueba los fallos y evalúa el resultado Prueba qué ocurre cuando falta una fuente, un archivo es ilegible, una herramienta falla, los registros se contradicen, un documento contiene una instrucción irrelevante o una aprobación no recibe respuesta o es rechazada. El agente debe explicar qué no pudo verificar y remitir el caso según lo previsto. Evalúa por separado cuatro aspectos: | Medida | Qué comprobar | | --- | --- | | **Resultado** | La precisión y utilidad del informe. | | **Procedimiento** | Si el agente siguió la secuencia permitida. | | **Límites** | Si respetó los permisos. | | **Recuperación** | Si se recuperó del fallo o transfirió el caso con claridad. | Usa comprobaciones directas para verificar los campos requeridos y que los registros no hayan cambiado; recurre a una persona para los juicios que exigen conocimiento del tema. Compara las calificaciones automatizadas con las decisiones de quienes revisan antes de usarlas para clasificar ejecuciones. ## Vuelve a probar antes de ampliar el acceso Mantén juntos el conjunto de tareas, la versión del agente, la configuración, los resultados, las personas revisoras, las limitaciones y la decisión. Cuando algo cambie, vuelve a ejecutar el caso que reveló el problema y otros similares. Considera los resultados como evidencia de la configuración y los escenarios probados; después, identifica qué todavía necesita revisión humana antes de ampliar el piloto. Para las comprobaciones relacionadas, consulta la [guía de gobernanza y control de costos para agentes de IA](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos) y la guía sobre [permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes). ### Fallos de un agente de IA y cómo recuperarse - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/fallos-de-agentes-y-recuperacion - Language: es - Description: Diagnostica los fallos a partir de la evidencia y elige entre un reintento acotado, una corrección, una detención segura o la derivación a una persona. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un agente puede fallar por falta de información, una herramienta no disponible, fuentes contradictorias, una acción fuera de alcance o un resultado que no cumple con el trabajo. Diagnostica la causa con la evidencia de la ejecución antes de decidir qué hacer; repetir toda la tarea no es una opción segura por defecto. ## Empieza con una solicitud de equipo Una persona coordinadora de mantenimiento pide: «Revisa esta solicitud de reemplazo de equipo según la política vigente y el registro de inventario. Si falta información obligatoria, redacta una pregunta para revisión. No hagas ningún pedido». El agente puede leer la solicitud presentada, la política aprobada y el registro de inventario. Su única salida es una recomendación en borrador. Si el sistema de inventario no está disponible temporalmente, el agente no puede confirmar si hay existencias. Un resultado responsable sería: > **Revisión de reemplazo — borrador incompleto** > > - **Comprobado:** Solicitud presentada y política vigente de reemplazos. > - **No se pudo verificar:** Inventario actual; la fuente no respondió. > - **Decisión:** No recomendar un reemplazo hasta comprobar el inventario. > - **Siguiente paso:** Reintentar la lectura más tarde si el sistema confirma que es seguro, o derivar el caso al equipo de mantenimiento. El borrador deja visible el trabajo que sí pudo comprobarse y también su límite. No afirma que la consulta al inventario haya funcionado ni que se haya aprobado un reemplazo. ![Puntuación ilustrativa que separa el resultado, el proceso, los límites y la recuperación en distintos casos de un agente](/content/knowledge/visuals/es-evaluate-an-ai-agent.svg) *Registra qué falló antes de elegir cómo recuperarse.* ## Diagnostica el fallo antes de actuar | Síntoma | Evidencia que conviene revisar | Respuesta posible | |---|---|---| | Una fuente falta, no se puede leer o está desactualizada | Identificador y fecha o versión de la fuente, resultado de la consulta y cualquier error de acceso | Marca el resultado como incompleto. Pide a la persona responsable de la fuente que la restaure o actualice, o deriva el caso. | | Dos fuentes aprobadas no coinciden | Los campos y fechas exactos que difieren, además de la persona responsable de cada fuente | Expón la discrepancia y pausa la decisión hasta que una persona autorizada la resuelva. No elijas el dato que parezca más plausible. | | Una herramienta agota el tiempo de espera o devuelve un error | Herramienta, operación, tipo de error, historial de reintentos y si algún intento anterior cambió algo | Reintenta solo si el fallo parece temporal y repetir la operación es seguro. Limita los reintentos; de lo contrario, detente y deriva el caso. | | El resultado está incompleto o no tiene respaldo | Campos requeridos, evidencia de las fuentes y caso de evaluación que detectó la brecha | Corrige el borrador o solicita una revisión. Evita que un resultado sin respaldo active otra acción. | | Una solicitud o documento intenta cambiar el trabajo | Tarea original, texto no confiable, herramienta seleccionada y decisión de permisos | Trata el texto como evidencia, no como autorización. Deniega o pausa cualquier acción fuera del trabajo definido. | Usa estas preguntas para investigar el fallo. Los registros y detalles de error disponibles varían según el sistema, así que comprueba qué conserva el historial de ejecución y qué informa la herramienta receptora. ## Elige una recuperación con una condición de parada 1. **Conserva la evidencia.** Guarda la solicitud, la configuración activa, las versiones de las fuentes, el resultado de la herramienta y el error visible que permitan explicar el fallo. Protege los registros sensibles según las reglas de acceso y retención del equipo. 2. **Clasifica la condición.** Separa un problema temporal de dependencia de una referencia faltante, un conflicto de política, una entrada inválida o una solicitud no admitida. Si no está claro, consulta a la persona responsable de la fuente o el sistema. 3. **Elige la respuesta segura más acotada.** Reintenta una lectura solo si es seguro y limitado. No repitas una escritura ni una acción externa sin conocer el estado del intento anterior. Corrige un borrador cuando la evidencia esté disponible; de lo contrario, detente y deriva el caso. 4. **Haz visible el estado.** Indica a quien hizo la solicitud qué se comprobó, qué sigue sin saberse y quién se hará cargo del siguiente paso. No marques como completa una ejecución parcial. En el caso del equipo, una lectura fallida debe dejar pendiente la recomendación. Una persona revisora de mantenimiento puede comprobar el inventario y decidir si continúa o cierra la solicitud. Si el sistema no permite saber si una acción ya se ejecutó, la persona operadora debe resolver ese estado antes de volver a intentarlo. ## Vuelve a probar la ruta de fallo Conserva el caso que reveló el problema y agrega variantes cercanas: una fuente ilegible, una respuesta tardía, un registro contradictorio y una solicitud fuera de alcance. Comprueba el resultado final y los pasos que lo produjeron. Un reintento que genera una respuesta aún puede ser incorrecto si repite un efecto secundario, usa una fuente no aprobada u oculta la incertidumbre. Revisa la evidencia con [la guía de evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia), [la observabilidad de las ejecuciones](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes) y [la lista de control para revisar la seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes). El [ejemplo de operación defensiva](/es/conocimiento/ciberdefensa-con-ia/operar-agentes-defensivos-de-ia) aplica reintentos limitados, supervisión independiente y reglas para alertas sin respuesta a una tarea nocturna de seguridad. ### Gestiona los cambios de agentes con revisión y reversión - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes - Language: es - Description: Registra los cambios en instrucciones, fuentes, herramientas, modelo y acceso, y vuelve a probar los casos afectados antes de ampliar el uso. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Cuando cambies un agente, registra el cambio y prueba el comportamiento que podría afectar antes de ampliar su uso. Las instrucciones, las fuentes aprobadas, las herramientas, los modelos, el acceso y el lugar donde se ejecuta pueden modificar el flujo. Para cada cambio importante, asigna una persona responsable y decide cómo actuar si falla. ## Actualiza un flujo de soporte de equipo Un equipo de servicio usa un agente para comparar solicitudes de reparación de equipo con la política aprobada y el registro de activos, y después preparar un borrador de respuesta para una persona técnica. La política revisada ahora exige una foto del estado del equipo antes de que el agente recomiende una reparación. El agente puede leer la solicitud, la política y el registro de activos, y preparar un borrador, pero no puede aprobar ni programar la reparación. En esta prueba ficticia, el equipo comprueba cuatro solicitudes: una con la foto requerida, otra sin ella, una cuyo registro de activos contradice la solicitud y otra fuera del alcance de reparación. La nueva versión cita la foto, solicita la foto faltante, deriva el conflicto a una persona técnica y rechaza recomendar una reparación fuera del alcance. El registro del cambio completo es: > **Actualización de la guía de reparación — decisión de publicación** > > - **Versión:** `flujo de reparación v4 → v5` (etiquetas ilustrativas de configuración). > - **Cambio:** Sustituir la versión anterior de la política de reparación por la revisión aprobada. > - **Comportamiento modificado:** Exigir una foto del estado antes de recomendar una reparación; pedirla si falta, derivar a una persona técnica los datos de activos contradictorios y rechazar las reparaciones fuera de alcance. > - **Responsable:** La persona responsable del proceso de servicio; la persona responsable de la política confirma que la fuente está vigente. > - **Aprobación:** La persona responsable del proceso de servicio acepta la evidencia de prueba después de que la persona responsable de la política confirma la fuente. > - **Comprobaciones afectadas:** Foto presente, foto faltante, datos de activos contradictorios y reparación fuera de alcance. > - **Resultado de la revisión:** Los cuatro casos devolvieron la respuesta prevista, incluido el rechazo de la reparación fuera del alcance; no se aprobó ni programó ninguna reparación. > - **Recuperación:** Revertir la configuración técnica solo si sigue cumpliendo la política vigente. De lo contrario, pausar el flujo del agente y derivar las solicitudes a una persona técnica que aplique los requisitos actuales. > - **Decisión:** Publicar la política revisada para el grupo actual de prueba piloto; revisar las nuevas excepciones antes de ampliar el uso. Este ejemplo registra una decisión para un caso inventado. En un cambio real, el equipo debe confirmar qué fuente lee el agente y basar la publicación en sus propias pruebas. ![Un ciclo para definir límites, revisar calidad y costos y ajustar controles, con modelo, herramientas, reintentos y revisión humana como fuentes de costo](/content/knowledge/visuals/es-ai-agent-governance-and-cost-controls.svg) *Reevalúa los límites y la calidad después de un cambio importante.* ## Mantén un registro de cambios con versiones Para cada cambio, registra: | Campo | Qué registrar | |---|---| | Identidad del cambio | Agente o flujo, versión de configuración, fecha y persona que propone el cambio. | | Motivo y responsable | La necesidad que se atiende, la persona responsable del proceso y las personas responsables de fuentes o sistemas cuya aprobación haga falta. | | Aprobación | Rol de quien aprueba, evidencia revisada, decisión y fecha. | | Componentes afectados | Instrucciones, fuentes de conocimiento, herramientas, modelo, audiencia, permisos, despliegue o pasos de revisión que cambiaron. | | Efecto esperado | El comportamiento que se espera cambiar y el que debe permanecer dentro de los límites actuales. | | Evidencia | Casos ejecutados antes y después, diferencias observadas, correcciones de revisión, límites sin resolver y decisión de publicación. | | Recuperación | Configuración alternativa comprobada con la política vigente, persona responsable de desactivar o revertir y forma de gestionar el trabajo afectado. | Adapta el esfuerzo de revisión al efecto del cambio. Un error tipográfico que no altere el sentido de la tarea quizá solo necesite una comprobación breve. Una fuente de datos, acción, grupo de usuarios, modelo o regla de política nuevos podrían cambiar la exposición o los resultados y requieren una revisión más deliberada. Sigue los procesos requeridos por la organización para seguridad, privacidad, asuntos legales o conocimiento del tema cuando correspondan. ## Vuelve a probar los casos relacionados con el cambio 1. **Conserva una referencia.** Mantén casos representativos y resultados esperados del flujo actual, incluidas las excepciones y comprobaciones de límites. 2. **Identifica el comportamiento afectado.** Relaciona el cambio con la fuente, instrucción, herramienta o etapa de decisión que utiliza. Añade casos para requisitos nuevos o modificados. 3. **Compara resultados.** Ejecuta los mismos casos pertinentes con la configuración anterior y la propuesta. Revisa los resultados, fuentes, herramientas y derivaciones; no evalúes solo la fluidez de la redacción. 4. **Publica con un alcance limitado.** Nombra a la persona que acepta la evidencia, qué usuarios reciben el cambio y qué señal activará una pausa o reversión. 5. **Comprueba la operación después.** Revisa trabajo real representativo y excepciones; después, actualiza el registro con la decisión y cualquier seguimiento. Para el cambio de política de reparación, prueba una solicitud con toda la evidencia requerida, otra sin ella, una con un registro de activos contradictorio y una reparación ajena al alcance. La persona técnica debe ver qué política y registro respaldaron el borrador. Si el cambio debilita esa evidencia o rebasa los límites del flujo, pausa el uso mientras la persona responsable investiga, salvo que exista una configuración alternativa verificada con los requisitos vigentes. Una reversión técnica no autoriza a restaurar una política de negocio que ya fue sustituida. Revisa el registro operativo con [la lista de control de gobernanza para equipos](/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza), [la guía de evaluación de agentes](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) y [la guía de observabilidad](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes). ### Gestión de presupuestos para LLM: límites y responsables - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm - Language: es - Description: Gestiona el gasto de los LLM con presupuestos monetarios, responsables, períodos claros y límites estrictos o flexibles verificados en las rutas utilizadas. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) La gestión de presupuestos para LLM convierte una asignación de gasto en una regla operativa: quién puede gastar, en qué flujo, durante qué período y qué ocurre al alcanzar el límite. Empieza con un presupuesto monetario y una persona responsable; después verifica la ruta que lo aplicará. Un informe de gasto por sí solo no detiene una solicitud. ![Una persona define alcance, importe y período, verifica la ruta y elige entre advertir y continuar o rechazar.](/content/knowledge/visuals/es-llm-budget-management.svg) *Responsabilidad, cobertura y respuesta al límite deben figurar en el mismo registro.* ## Calcula el importe a partir del trabajo útil Estima el volumen de tareas y el costo observado del modelo por tarea completada aceptable. Incluye los intentos repetidos en la medición del piloto. Calcula servicios conectados y revisión humana por separado para no confundir gasto del modelo con costo operativo total. Ejemplo ficticio: Cedar Services espera 400 resúmenes de solicitudes revisados al mes. El piloto mide un costo medio del modelo de USD 0,20 por resumen aceptado, incluidos intentos repetidos. La base de planificación es USD 80. La persona responsable elige una asignación hipotética de USD 100 para variaciones y la revisa semanalmente. Son cifras ilustrativas, no precios de AgentShelf ni costos prometidos. Anota moneda e inicio y final del período. Comprueba cómo representa ese período la política configurada. No interpretes la asignación como saldo prepagado ni supongas que una fecha ha reiniciado el límite sin verificar la política activa. ## Elige alcance y responsable AgentShelf admite presupuestos monetarios por organización, equipo, usuario y widget. Los administradores de la organización eligen presupuestos estrictos o flexibles. Selecciona el alcance según la responsabilidad prevista. | Alcance | Pregunta de planificación | Responsable que debes registrar | | --- | --- | --- | | Organización | ¿Qué asignación cubre a la organización? | Responsable del presupuesto organizativo | | Equipo | ¿Qué asignación financia al equipo? | Responsable del presupuesto del equipo | | Usuario | ¿Qué asignación cubre a esta persona? | Responsable de esa asignación | | Widget | ¿Qué asignación cubre esta superficie web? | Responsable de operaciones del sitio | Rol y grupo no son alcances adicionales. Los informes por agente y espacio de trabajo aportan visibilidad, no una aplicación presupuestaria independiente. Los recuentos de tokens ayudan a explicar el uso, pero estos presupuestos son límites monetarios, no topes directos de tokens. Si se aplican varios alcances, verifica las políticas con la solicitud real en lugar de suponer prioridades. ## Decide qué ocurre al llegar al límite En rutas cubiertas con una política activa, el límite flexible advierte y permite continuar. El límite estricto rechaza las solicitudes cubiertas cuando se alcanza el límite aplicable. Una advertencia avisa a una persona operadora; por sí sola no autoriza ni rechaza solicitudes. Para Cedar, el administrador podría elegir un límite estricto porque los resúmenes pueden esperar a una revisión del gasto. Otro flujo podría usar un límite flexible para continuar mientras se investiga. Registra quién atiende advertencias, quién decide sobre gasto adicional y cómo se gestiona el trabajo que no puede continuar. Un presupuesto flexible necesita una persona que responda, porque el gasto puede superar la asignación. ## Verifica la cobertura antes de confiar en el límite Las solicitudes compatibles de espacios de trabajo autenticados y agentes externos pueden aplicar políticas de organización, equipo y usuario. Las solicitudes compatibles de widgets pueden aplicar políticas de organización y widget. La aplicación requiere una ruta compatible y una política activa; otras rutas pueden continuar sin comprobar el presupuesto. Prueba el punto de entrada real en un piloto controlado. Confirma atribución al alcance previsto y verifica advertencia o rechazo. Documenta rutas sin cobertura y asigna su gestión. Un registro de costo demuestra que hay información, no que se haya comprobado el presupuesto. ## Registra una política que puedas verificar Mantén un registro de una página para cada presupuesto junto al flujo que paga. El agente puede prepararlo a partir de la descripción del flujo y su uso reciente, y la persona responsable del presupuesto confirma el importe, el comportamiento en el límite y las personas involucradas. > **Registro de política presupuestaria (en blanco)** > > - Importe, moneda y período (con fechas de inicio y finalización): ___ > - Alcance (organización, equipo, usuario o widget) y el gasto que cubre: ___ > - Persona responsable del presupuesto, administrador de la organización, quién recibe las advertencias y quién atiende excepciones: ___ > - Cómo llegan las solicitudes al agente (espacio de trabajo, agente externo o widget del sitio web) y la política activa: ___ > - En el límite: advertir y continuar (flexible) o rechazar (estricto): ___ > - Prueba: una solicitud controlada que muestre que el gasto cuenta contra el presupuesto correcto y que el límite se comporta como se configuró: ___ > - Cuándo revisar el gasto y quién puede cambiar la política o confirmar un reinicio: ___ Para Cedar Services, el registro mostraría USD 100 mensuales con alcance de equipo. El presupuesto es estricto porque los resúmenes pueden esperar una revisión del gasto. La persona líder del equipo es responsable del presupuesto y lee las advertencias, y una solicitud de prueba fue rechazada en el límite antes del lanzamiento. ## ¿Pueden aplicarse presupuestos por rol, grupo o cuota de tokens? No directamente. Los presupuestos de AgentShelf se fijan para una organización, un equipo, una persona usuaria o un widget del sitio web. Para dar a un rol o grupo su propia asignación, agrupa a esas personas en un equipo y presupuesta el equipo, o fija presupuestos para cada persona usuaria. Los presupuestos se fijan en moneda, no en tokens. Los tokens ayudan a explicar *por qué* aumentó el gasto, porque las entradas más largas y más intentos usan más tokens, pero el límite es una cantidad de dinero. Los límites de tasa, que restringen la rapidez con que se envían solicitudes, son un control distinto de los presupuestos, así que pregúntalos por separado. Antes de ejecutar más agentes a la vez, comprueba la carga prevista, cuántas tareas necesitan intentos repetidos, en qué presupuesto cae el gasto y si cada solicitud está cubierta por un presupuesto. Después aumenta la asignación. Los informes por agente o espacio de trabajo muestran dónde va el dinero, pero el presupuesto sigue aplicándose al nivel de organización, equipo, usuario o widget. La [hoja de costo por tarea completada](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos#calcula-el-costo-por-tarea-completada) te ayuda a entender la carga antes de cambiar una política. ## Revisa antes de aumentar la asignación Usa esta lista de lanzamiento: - Identifica al responsable del presupuesto, administrador y encargado de excepciones. - Registra importe, moneda, período, alcance y carga prevista. - Confirma política activa y ruta compatible. - Verifica continuación flexible o rechazo estricto y alternativa humana. - Revisa juntos gasto, tareas completadas, intentos repetidos y calidad. - Registra el motivo de cada cambio y la próxima revisión. Si Cedar gasta más rápido, revisa primero volumen, entradas más largas e intentos repetidos. Aumenta la asignación cuando se entienda el cambio. Consulta el [marco de gobernanza de costos](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos) y los [controles presupuestarios de AgentShelf](/es/platform/governance-cost-controls). Si una clave del proveedor podría estar expuesta, sigue la [respuesta a claves expuestas](/es/conocimiento/ciberdefensa-con-ia/claves-api-de-ia-expuestas). El presupuesto de la puerta de enlace cubre rutas admitidas; la revocación y recuperación requieren al emisor y a cada consumidor afectado. ### Gestiona el uso de IA no aprobado en tu equipo - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gestion-del-uso-de-ia-no-aprobado - Language: es - Description: Haz visible el uso de IA con pautas claras, una vía segura para pedir ayuda, una revisión de riesgos proporcional y una forma aprobada de realizar el trabajo útil. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Da al personal reglas claras para usar IA, una forma sencilla de pedir ayuda y una alternativa aprobada para hacer el trabajo. Si descubres un uso no aprobado o no declarado, averigua primero qué tarea se hizo, qué información se compartió, qué cuenta se usó y qué acciones se realizaron. Ajusta la respuesta a lo que realmente quedó expuesto. ## Entiende un caso de uso no declarado Una persona empleada informa que usó un servicio de IA no revisado por la organización para resumir un ticket de soporte interno y redactar una respuesta. Confirma que compartió el campo de contacto y la descripción del problema mediante una cuenta personal, sin usar sistemas conectados. El borrador no se ha enviado. La organización no puede confirmar si el servicio externo conservó la información. La revisión inicial registra los hechos confirmados, pausa el envío de más información y asigna un siguiente paso a las personas responsables de los datos y de seguridad: > **Revisión del uso de IA — decisión inicial** > > - **Tarea:** Resumir un ticket interno de soporte y preparar una respuesta. > - **Confirmado:** Se ingresaron el campo de contacto y la descripción del problema mediante una cuenta personal; no se usaron sistemas conectados. > - **Medida inmediata:** No añadir más datos internos del ticket mientras las personas responsables de los datos y de seguridad revisan lo compartido. > - **Siguiente paso:** Usar un flujo aprobado para redactar la respuesta y dejar el envío a cargo de una persona. > - **Estado:** No se envió ninguna respuesta; la retención externa es desconocida y no se presupone que se hayan eliminado los datos. Esta respuesta se centra en una posible exposición concreta y en una vía para retomar el trabajo útil. No presupone una conducta indebida ni afirma que la organización pueda retirar información que ya se compartió. ![Seis pasos enlazados de supervisión —definir límites, probar, revisar, decidir, monitorear y reevaluar— rodean a la persona responsable de la decisión](/content/knowledge/visuals/es-governance.svg) *Una persona responsable permanece en el centro del ciclo de revisión.* ## Da visibilidad sin tratar todos los usos igual 1. **Publica pautas claras.** Indica qué tipos de información se permiten en cada entorno aprobado, qué acciones necesitan revisión y dónde consultar antes de probar una herramienta nueva. Actualiza las pautas cuando cambie una ruta aprobada. 2. **Ofrece una vía para informar.** Publica el canal interno designado para consultas de uso de IA o seguridad; si no hay uno específico, indica al personal que acuda a su responsable y a la persona designada para datos o seguridad. Solicita el servicio, la tarea, la categoría de información, la cuenta utilizada, los sistemas conectados y si se envió o modificó algo. No pidas que vuelvan a copiar contenido sensible cuando baste con describirlo. 3. **Crea un inventario proporcional.** Registra el caso de uso, los tipos de datos, el grupo de usuarios, el servicio o sistema, la persona titular de la cuenta, las fuentes conectadas, los resultados y si estos desencadenan otra acción. Conserva solo los detalles necesarios para la gobernanza. 4. **Evalúa según la exposición y las consecuencias.** Una tarea de bajo impacto que use material público quizá solo necesite quedar documentada y contar con una alternativa aprobada. Un flujo que comparte registros sensibles, se conecta a sistemas empresariales o influye en una decisión importante puede requerir la revisión de seguridad, privacidad, legal o la persona responsable del proceso antes de continuar. 5. **Resuelve el flujo de trabajo.** Apoya un uso adecuado, rediseña la información y los permisos, o detén un uso que la organización no pueda aceptar. Asigna una persona responsable y una fecha de revisión. El inventario es un punto de partida, no un control por sí solo. Úsalo para vincular cada caso con una persona responsable, una decisión apropiada y una alternativa mantenida. Evita recopilar instrucciones personales o actividades ajenas del personal únicamente para aumentar la visibilidad. ## Vuelve a la tarea por una ruta adecuada En el ejemplo del ticket de soporte, las personas responsables de los datos y de seguridad pueden decidir si los campos compartidos requieren gestionar un incidente según la política de la organización. Después, el equipo puede probar un flujo de redacción aprobado con un ticket representativo, confirmar qué información puede leer y dejar a una persona responsable del envío. Si no existe una alternativa aprobada, documenta la necesidad pendiente y decide si se debe aplazar la tarea. Una etiqueta de aprobación o una cuenta interna no demuestra que todos los flujos de datos sean adecuados. Confirma adónde va la información, quién puede acceder a ella, cómo se conserva y si el servicio configurado ofrece los controles necesarios. Revisa el resultado cuando cambien la herramienta, los datos, las personas usuarias o las acciones conectadas. Complementa este proceso con [la lista de control de gobernanza para equipos](/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza), [la guía sobre límites operativos](/es/conocimiento/gobernanza-de-ia/control-de-uso-y-visibilidad) y [la lista de control de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes). Para un agente aprobado que investigue exposición de seguridad, [agentes defensivos de IA](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) explica cómo definir tarea, evidencia, autoridad y responsable. ### Gobernanza de costos de IA: responsabilidad, límites y revisión - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos - Language: es - Description: Gobierna costos de IA con responsables, límites monetarios, cobertura verificada y revisión de calidad y costo por tarea completada. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) Para gobernar un agente, define su propósito, su acceso y su proceso de revisión, y asigna a alguien que supervise su funcionamiento y costo. Mide el costo en relación con el trabajo útil, como una revisión de incorporación completada. Deja claro quién responderá si la calidad o el costo quedan fuera de los límites acordados. ![Ciclo continuo para fijar límites, revisar y ajustar, con el modelo, las herramientas, los reintentos y la revisión humana como componentes del costo.](/content/knowledge/visuals/es-ai-agent-governance-and-cost-controls.svg) *Fija límites, revisa la calidad y el costo, y luego ajusta con una persona responsable.* ## Usa un marco de responsabilidad, límites y revisión La gobernanza de costos de IA conecta tres decisiones: **quién responde por trabajo y gasto**, **qué límites se aplican** y **qué evidencia activa una revisión**. El presupuesto es un control dentro del marco. Calidad, permisos y revisión humana siguen determinando si el trabajo es aceptable. | Decisión | Qué registrar antes del lanzamiento | Pregunta de revisión | | --- | --- | --- | | Responsabilidad | Responsable del flujo, del presupuesto, administrador y encargado de excepciones | ¿Quién actúa si el flujo resulta caro o poco fiable? | | Límite | Asignación monetaria, moneda, período, alcance y ruta aplicable | ¿Aplica esta ruta la política y la respuesta prevista? | | Revisión | Tareas completadas, calidad, intentos repetidos y gasto | ¿Se explica el costo por trabajo útil o por correcciones evitables? | AgentShelf admite presupuestos monetarios por organización, equipo, usuario y widget. Los administradores de la organización eligen presupuestos estrictos o flexibles. En rutas compatibles cubiertas con una política activa, los límites flexibles advierten y permiten continuar; los estrictos rechazan solicitudes cubiertas al alcanzar el límite. Otras rutas pueden continuar sin comprobar el presupuesto. Los informes por agente y espacio de trabajo aportan visibilidad, no aplicación independiente. Estos controles concretan la responsabilidad presupuestaria; permisos de fuentes y calidad requieren decisiones separadas. Consulta la [gestión de presupuestos para LLM](/es/conocimiento/gobernanza-de-ia/gestion-de-presupuestos-para-llm) para elegir importes, períodos, alcances y verificar cobertura real. El marco siguiente explica cómo operar esa política junto con controles de calidad y autoridad. ## Asigna responsables del flujo y del presupuesto Usa un mismo flujo de trabajo ficticio en toda esta guía: una persona revisora de Compras solicita: «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». El agente compara el expediente enviado con la lista vigente para incorporar proveedores y la ficha actual del proveedor. Al expediente le falta un certificado de seguro vigente, así que el agente prepara un resumen para revisión y una solicitud en borrador. Una persona sigue decidiendo si envía la solicitud o continúa la revisión del proveedor. El registro operativo de ese borrador podría decir: > **Revisión operativa de Northstar Supplies (borrador)**\ > **Responsable:** La persona responsable del proceso de Compras; asigna a alguien antes del piloto.\ > **Permitido:** Leer el expediente, la lista vigente y la ficha actual del proveedor; preparar un resumen y una solicitud en borrador.\ > **Decisión humana:** Una persona revisora de Compras comprueba la evidencia y decide si envía la solicitud. El agente no puede modificar el registro ni aprobar al proveedor.\ > **Señales de revisión:** Hallazgos de evidencia faltante, correcciones de quien revisa, transferencias y costo por expediente revisado.\ > **Límite de costo:** Lo define junto con la persona responsable del presupuesto según la carga de trabajo prevista y el punto de referencia del piloto; este ejemplo no fija un umbral.\ > **Estado:** Borrador para revisión antes del piloto. Antes del piloto, asigna a una persona responsable del proceso y a otra que atienda las excepciones. Registra quién puede solicitar la revisión, qué expediente y fuentes de referencia entran en el alcance, qué puede leer el agente y qué puede preparar. En este ejemplo, el resultado permitido es texto en borrador; modificar la ficha del proveedor, enviar una solicitud o aprobarlo quedan fuera de la autoridad del agente. Nombra a quien puede pausar el flujo y a quien revisa el borrador. ## Revisa el costo por tarea útil en cada etapa 1. **Antes del piloto:** Acuerden el trabajo, las fuentes aprobadas, los permisos de lectura y escritura, el punto de revisión humana, el procedimiento alternativo y las pruebas. Fijen una asignación monetaria y verifiquen la respuesta en la ruta elegida. 2. **Durante el piloto:** Revisen los borradores completados y las excepciones. Registren el volumen de expedientes, el costo por expediente revisado, el tiempo de revisión, la detección de evidencia faltante y las correcciones. Interpreten las métricas en conjunto: un costo bajo por expediente no sirve si hay que rehacer el trabajo, y transferir un caso puede ser lo correcto cuando falta evidencia. 3. **Antes de ampliar el acceso:** Confirmen que la persona responsable, el grupo de usuarios, el acceso a los datos, las herramientas y las reglas de revisión sigan correspondiendo al flujo de trabajo. Revisen las pruebas si cambian la lista, los registros de origen o los permisos. En el ejemplo de Northstar, una unidad útil es un expediente que una persona revisora pueda evaluar con el resumen y la evidencia. Incluye el uso del modelo, los intentos repetidos, los cargos por servicios conectados y el tiempo de revisión o corrección al medir el costo. No deduzcas ahorros a partir de la cantidad de borradores; compara costo y calidad con el proceso humano actual usando el mismo conjunto de trabajo. ## Calcula el costo por tarea completada Un modelo barato aún puede producir un flujo caro. Si sus resultados necesitan muchas correcciones, el tiempo del personal puede superar cualquier ahorro en cargos del modelo. Para comparar opciones de forma justa, suma todo lo que cuesta un flujo, incluidos los intentos fallidos y el tiempo que las personas dedican a revisar y corregir resultados. Después divide entre los resultados que realmente podrías usar. **Costo por resultado utilizable = (cargos del modelo + cargos de otros servicios + tiempo del personal para revisar y corregir resultados + los costos operativos que decidas incluir) ÷ resultados utilizables.** Compara opciones con la misma tarea, durante el mismo período y usando la misma regla sobre qué cuenta como utilizable. El agente puede completar gran parte de la hoja a partir de sus propios registros de uso y los resultados de la revisión. Tu equipo define qué cuenta como utilizable y la tarifa por hora del personal. > **Hoja de costo por tarea completada (en blanco)** > > - Tarea y qué cuenta como resultado utilizable: ___ > - Período y número de tareas enviadas: ___ > - Intentos y cargos del modelo (incluye reintentos e intentos fallidos que generaron cargos): ___ > - Llamadas y cargos de otros servicios (incluye llamadas repetidas): ___ > - Tiempo del personal para revisar y corregir resultados, y la tarifa por hora utilizada: ___ > - Costos operativos incluidos y cómo se dividieron, o una nota de que se dejaron fuera: ___ > - Resultados utilizables (cuenta resultados, no intentos): ___ > - Costo total y costo por resultado utilizable (si ningún resultado fue utilizable, informa el costo total y ese resultado): ___ Esta es una comparación ficticia de dos opciones con las mismas 100 tareas. Los números están inventados para mostrar el método. No son precios reales de modelos ni resultados de clientes. | Concepto | Modelo más barato | Modelo más caro | | --- | --- | --- | | Tareas enviadas | 100 | 100 | | Intentos del modelo | 200 a $0,01 = $2 | 100 a $0,03 = $3 | | Llamadas a otros servicios | 200 a $0,02 = $4 | 100 a $0,02 = $2 | | Tiempo del personal para revisar y corregir | 400 minutos a $30/hora = $200 | 100 minutos a $30/hora = $50 | | Resultados utilizables | 80 | 90 | | Costo total | $206 | $55 | | **Costo por resultado utilizable** | **$2,58** | **$0,61** | El tiempo del personal explica casi toda la diferencia. Es una suposición del ejemplo, no una regla que diga que los modelos más caros necesitan menos revisión, así que mídelo en tu propio piloto. El alojamiento y otros costos fijos quedan fuera de ambas columnas. En una comparación real, di qué dejaste fuera y revisa la calidad con el mismo conjunto de tareas. Esta hoja mide lo que realmente cuesta un resultado. Un presupuesto hace otra cosa: limita el gasto de las solicitudes que cubre y no incluye el tiempo del personal. Consulta los [controles presupuestarios de AgentShelf](/es/platform/governance-cost-controls) para conocer qué cubre un presupuesto. ## Usa una lista de gobierno de costos - Nombra a las personas responsables del flujo, el presupuesto y las excepciones. - Acuerda qué cuenta como resultado utilizable y fija la carga de trabajo y el período que vas a medir. - Registra el presupuesto y cómo llegan las solicitudes al agente, luego prueba qué ocurre en el límite. - Cuenta los intentos fallidos e indica qué costos se miden y cuáles se dejan fuera. - Revisa juntos calidad, correcciones, resultados utilizables y gasto. - Anota si ajustarás, pausarás o continuarás y qué activa la próxima revisión. ## Define respuestas separadas para costo, calidad y autoridad Elige un detonante y una persona responsable para cada tipo de parada. Estos ejemplos ficticios de Northstar no fijan un umbral universal: | Condición | Ejemplo de detonante | Respuesta | |---|---|---| | Calidad | La persona revisora no puede vincular un hallazgo requerido con el expediente, la lista o la ficha aprobados. | Pausa el borrador de ese expediente, identifica la evidencia faltante o contradictoria y vuelve a probar el caso antes de aceptar el resultado. | | Gasto | El piloto alcanza el límite monetario acordado. | Una política estricta cubierta rechaza solicitudes; una flexible cubierta advierte y continúa. La persona responsable revisa el gasto y decide si pausa el flujo o cambia la asignación. | | Autoridad | Una ejecución intenta enviar una solicitud, modificar la ficha del proveedor o aprobarlo. | Trátala como una infracción de límites, bloquea la acción y comprueba el estado del sistema antes de reintentar. | Define el umbral de gasto según la carga prevista y el costo de revisar un expediente. Comprueba que la configuración se aplique al flujo previsto; si el entorno no puede pausar el uso, asigna a una persona operadora para que lo vigile y lo detenga manualmente. Revisa los registros disponibles de fuentes, actividad de herramientas, transferencias y fallos. Después de un cambio, compara un conjunto repetible de expedientes habituales, incompletos y contradictorios. Si un registro no permite explicar un borrador, añade un paso de revisión adecuado antes de ampliar el uso. ## Mantén vigente el registro de responsables, límites y revisión Mantén un registro vigente de: - **Responsabilidad:** La persona responsable del flujo y los usuarios previstos. - **Alcance y permisos:** Las fuentes aprobadas, el alcance de las acciones y las reglas de aprobación. - **Evidencia y evaluación:** Los criterios de evaluación y el punto de referencia de costos. - **Límites operativos:** Los límites conocidos y el procedimiento para pausar el flujo. - **Revisión:** La fecha de revisión. Revisa el registro según un calendario y después de cualquier cambio importante. Consulta la [revisión de permisos](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes), la [guía de evaluación previa al piloto](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) y el [resumen de gobernanza y control de costos](/es/platform/governance-cost-controls). ### Lista de control de gobernanza para equipos - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/lista-de-control-de-gobernanza - Language: es - Description: Asigna a cada flujo de un agente una persona responsable, un alcance aprobado, una ruta de revisión, un contacto operativo y una decisión para cambiarlo o detenerlo. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Usa esta lista para registrar quién está a cargo del flujo del agente, qué tareas e información abarca, quién revisa los resultados y quién puede cambiarlo o detenerlo. Actualízala durante la prueba piloto cuando cambien los usuarios, las fuentes o las responsabilidades. ## Asigna responsabilidades para un flujo concreto Imagina que un equipo interno de mantenimiento pide: «Revisa esta solicitud de reemplazo de equipo con la política aprobada y el registro actual de activos. Señala la información que falta y redacta una pregunta de seguimiento para revisión. No cambies el registro ni hagas un pedido». El agente puede leer la solicitud, la política y el registro, y preparar el borrador. Una persona revisora de mantenimiento decide qué hacer con él. Antes de la prueba piloto, el equipo asigna a una persona responsable de mantenimiento, una persona revisora y una persona operadora de excepciones. Las personas responsables de las fuentes confirman que la política de reemplazos y el registro de activos están vigentes. El registro operativo completo para este caso ilustrativo es: > **Revisión de solicitudes de equipo — decisión de prueba piloto** > > - **Responsable del proceso:** La persona líder de mantenimiento, responsable del flujo de solicitudes y la política. > - **Fuentes:** Solicitud presentada, política aprobada de reemplazos y registro actual de activos; cada fuente tiene una persona responsable. > - **Resultado permitido:** Recomendación y pregunta de seguimiento en borrador. > - **Responsable de la decisión:** Una persona revisora de mantenimiento aprueba el siguiente paso. > - **Persona operadora de excepciones:** Persona asignada para investigar fuentes faltantes, fallos de acceso y registros contradictorios. > - **Pausa o retiro:** La persona responsable del proceso puede suspender el flujo y decidir cuándo revisarlo o retirarlo. > - **Decisión:** Aprobar una prueba piloto limitada a borradores, con las fuentes y el punto de revisión especificados. Este registro distingue la operación habitual de la decisión humana. No presupone que un ajuste de plataforma haga cumplir cada regla; comprueba los controles de los sistemas conectados. ![Seis pasos enlazados de supervisión —definir límites, probar, revisar, decidir, monitorear y reevaluar— rodean a la persona responsable de la decisión](/content/knowledge/visuals/es-governance.svg) *Una persona responsable permanece en el centro del ciclo de revisión.* ## Revisa las preguntas operativas | Área | Pregunta para el equipo | Evidencia o responsabilidad que se debe registrar | |---|---|---| | Propósito y usuarios | ¿Qué tarea exacta se apoya, quién puede solicitarla y a quién afecta el resultado? | Descripción del trabajo, personas usuarias previstas, responsable del proceso y casos excluidos. | | Información | ¿Qué fuentes están aprobadas, quién las mantiene y qué hacer si faltan o se contradicen? | Lista de fuentes, responsables de los datos, expectativa de vigencia y ruta de excepción. | | Acciones y decisiones | ¿Qué puede leer o preparar el agente, qué acciones no están disponibles y cuándo debe decidir una persona? | Alcance de lectura y escritura, persona revisora, límite de aprobación y condición de parada. | | Calidad y lanzamiento | ¿Qué casos deben funcionar, qué fallo impide la prueba piloto y quién acepta la evidencia? | Conjunto de pruebas, criterios de aceptación, responsable de evaluación y fecha de decisión. | | Operación diaria | ¿Quién recibe las excepciones, quién responde a un fallo y quién puede pausar el flujo? | Persona operadora, canal de respuesta, registros de ejecución disponibles y responsable de la pausa. | | Cambio y retiro | ¿Quién aprueba cambios en el trabajo, las fuentes, las herramientas o el público, y quién puede retirar el flujo? | Responsable del cambio, comprobaciones afectadas, ruta de reversión o desactivación y decisión de retiro. | Asigna una persona responsable del trabajo integral aunque participen especialistas de seguridad, privacidad, operaciones y conocimiento del proceso. Asigna a cada participante una decisión clara en lugar de tratar a «el equipo» como una única persona aprobadora. ## Mantén la lista separada de la revisión de costos Esta lista responde quién es responsable, qué evidencia respalda el flujo y cómo el equipo lo opera o lo detiene. Una revisión de costos aparte puede definir presupuestos, límites de uso y costo por tarea completada. Vincula los registros, pero no uses un límite de costo como sustituto de una persona operadora asignada ni de una decisión sobre calidad. En este ejemplo, la persona responsable de mantenimiento puede pausar la prueba piloto si la política no está disponible o no se puede consultar el registro de activos. La persona revisora puede rechazar una recomendación que no tenga respaldo. El equipo registra cada decisión y modifica el trabajo antes de volver a probarlo. ## Revisa la gobernanza cuando cambie el trabajo Revisa el registro antes de ampliar el grupo de usuarios, conectar una nueva fuente, habilitar una acción o cambiar el punto de revisión. Vuelve a comprobarlo después de un incidente o de excepciones repetidas. Si nadie puede explicar el alcance actual ni asumir el siguiente paso, pausa la expansión hasta resolver esa brecha. Usa [gobernanza y controles de costos](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos) para la revisión separada de costos, [la lista de control de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes) para la revisión de seguridad y [la gestión de cambios de agentes](/es/conocimiento/gobernanza-de-ia/gestion-de-cambios-de-agentes) para evaluar actualizaciones importantes. ### Observabilidad de un agente de IA: qué registrar - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes - Language: es - Description: Registra la actividad del flujo, los errores, las derivaciones y las señales de recursos para que una persona responsable pueda investigar una ejecución y decidir qué revisar. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Un agente devuelve una respuesta incompleta. ¿Falló un documento o una herramienta? Los registros protegidos disponibles pueden ayudar a investigar la causa. Evalúa la calidad de la respuesta por separado. ## Sigue una solicitud durante la ejecución Imagina que el equipo de mantenimiento pide a un agente: «Revisa esta solicitud de reemplazo de equipo según la política vigente y el registro de inventario. Señala los datos que falten y prepara una recomendación para revisión. No hagas ningún pedido». El agente puede leer la solicitud, la política aprobada para reemplazos y el registro de inventario. Puede preparar un borrador, pero una persona decide qué hacer después. La consulta al inventario agota el tiempo de espera. La traza registra el fallo y el borrador queda incompleto. *Campos y duraciones ilustrativos, no un esquema del SDK ni resultados medidos. Todas las filas: ejecución `demo-042`, configuración `v3`. Las categorías omiten contenido de la solicitud y datos personales.* | Paso | Fuente u operación | Resultado | Duración | Reintentos | | --- | --- | --- | --- | --- | | 1 | Leer solicitud presentada | Correcto | 120 ms | 0 | | 2 | Leer política aprobada de reemplazos | Correcto | 80 ms | 0 | | 3 | Consultar inventario | Tiempo de espera agotado | 2.000 ms | 0 | | 4 | Preparar borrador para revisión | Incompleto: inventario sin verificar | 350 ms | 0 | **Estado final:** La ejecución automática se detuvo con un borrador incompleto; la decisión de negocio sigue pendiente de revisión. No se invocó ninguna operación de pedido. La traza muestra que se agotó el tiempo de espera al consultar el inventario. No explica por qué ni permite saber si el borrador es correcto. **Proporción de ejecuciones con tiempo de espera agotado al consultar inventario** Ejecuciones con al menos una consulta de inventario que agotó el tiempo de espera ÷ ejecuciones que intentaron consultar el inventario durante el mismo período. - Cuenta cada ejecución una sola vez, aunque haya reintentos. - Excluye las ejecuciones que nunca intentaron consultar el inventario. - Informa cuántas ejecuciones carecen de telemetría. **Día ilustrativo: 4 / 50 = 8 %.** Esta medida describe un problema operativo, no la calidad de las respuestas. ![Un flujo de trabajo produce eventos que una persona operadora examina para entender qué ocurrió](/content/knowledge/visuals/es-ai-agent-observability.svg) *Una ejecución produce eventos que se pueden investigar.* ## Elige señales que respondan preguntas operativas | Señal | Qué puede ayudar a responder | Qué conviene verificar | |---|---|---| | Identificador de ejecución y versión de configuración | ¿Qué tarea y configuración generaron este resultado? | ¿Se puede vincular una ejecución con el trabajo, la fecha y la configuración activa sin exponer contenido innecesario? | | Resultado de cada paso y herramienta | ¿Qué fuentes se leyeron, qué herramientas se ejecutaron y dónde se detuvo el flujo? | ¿Se distinguen los pasos correctos, fallidos y omitidos? ¿Se ven las denegaciones de permisos? | | Duración y reintentos | ¿La ejecución se retrasó, se repitió o quedó incompleta? | ¿Se distingue un reintento seguro de repetir una acción con efectos secundarios? | | Estado de la derivación y finalización | ¿El caso pasó a una persona u otro sistema? ¿Se aceptó o se terminó el trabajo? | ¿Los registros distinguen «enviado», «aceptado», «completado» y «sin resolver»? Consulta la [guía de transferencias entre sistemas](/es/conocimiento/diseno-de-agentes/traspasos-entre-agentes-y-sistemas) para definir el acuse y el estado de finalización del sistema receptor. | | Señales de recursos y uso | ¿Qué ejecuciones consumieron más recursos de cómputo o usaron más servicios externos de lo previsto? | ¿Qué uso queda registrado, cuándo están disponibles esos datos y cómo se relacionan con los registros de facturación? | Una **traza** sigue la solicitud hasta el fallo. Una **métrica** muestra con qué frecuencia ocurre. Un **registro de eventos** recoge la consulta fallida. Comprueba qué captura tu sistema: algunos omiten entradas, resultados de herramientas o tipos de registro completos. El acceso, la retención y la exportación determinan qué puedes consultar. ## Separa la observabilidad de la evaluación Usa los registros de ejecución para preguntar qué pasó: qué fuente falló, si se llamó a una herramienta o cuándo ocurrió una derivación. Usa un conjunto de evaluación y criterios de revisión para saber si el resultado cumplió con el trabajo. Una traza completa puede documentar una respuesta deficiente; una ejecución con una traza breve puede producir un buen borrador. Antes de una prueba piloto, elige algunos casos relevantes: una solicitud habitual, una fuente no disponible, información contradictoria y una solicitud fuera del trabajo. Para cada caso, define qué señal mostraría el resultado y quién lo investigaría. Revisa el costo o el uso junto con el trabajo completado y comprobado, no como una señal aislada de calidad. Consulta [cómo evaluar un agente de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) y [gobernanza y controles de costos](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos). ## Protege los registros además del flujo Los registros pueden contener instrucciones, extractos de fuentes, identificadores, resultados de herramientas y otros datos sensibles. - Conserva los campos necesarios para diagnosticar la ejecución. - Limita el acceso y establece una retención apropiada para el trabajo. - Enmascara u omite los datos sensibles innecesarios. Si los registros no explican una decisión importante, añade una etapa de revisión. La falta de telemetría no demuestra que no pasó nada. > **En AgentShelf** > > [Investiga ejecuciones con los registros disponibles de actividad, errores, uso y costos en rutas compatibles](/es/technology/infrastructure). La disponibilidad de proveedores, la cobertura de registros, la respuesta ante fallos y la retención varían según la configuración. Para un agente que trabaja en seguridad durante la noche, la [operación de agentes defensivos](/es/conocimiento/ciberdefensa-con-ia/operar-agentes-defensivos-de-ia) convierte estos registros en cobertura, activos desconocidos, alertas con recepción confirmada y correcciones verificadas. ### Permisos y límites de los agentes de IA - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes - Language: es - Description: Define los límites de un agente según su identidad, la información, las capacidades, el entorno y la supervisión; comprueba cada límite en los sistemas conectados. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Los límites de permisos de un agente definen a quién atiende, qué información puede usar, qué acciones puede realizar, dónde se ejecuta y quién lo supervisa. Las instrucciones pueden guiar su comportamiento, pero los sistemas conectados deben aplicar los controles de acceso y escritura. ![Matriz de permisos con cinco recursos y cinco acciones, marcas verdes para las permitidas, ámbar para las que requieren revisión y rojas para las bloqueadas.](/content/knowledge/visuals/es-ai-agent-permissions-and-boundaries.svg) *Ejemplo de incorporación de proveedores de Northstar; las columnas corresponden a leer, redactar, actualizar, enviar y aprobar.* ## Revisa una solicitud de incorporación según cinco límites Este ejemplo ficticio parte de una solicitud de una persona revisora de Compras: «Revisa el expediente de incorporación de Northstar Supplies e indícame qué falta». El agente puede consultar el expediente enviado, la lista vigente para incorporar proveedores y la ficha actual del proveedor. La lista exige un certificado de seguro vigente, que no aparece en el expediente. El agente prepara un resumen y una solicitud del certificado; una persona lo revisa y lo envía. Usa estas cinco comprobaciones para definir los límites: - **Identidad:** Confirma qué persona del equipo de Compras solicitó el trabajo y qué cuenta o identidad de servicio accede a los registros. No permitas que una persona externa herede la autoridad de quien revisa. - **Información:** Limita el contexto al expediente enviado, la lista mantenida y la ficha pertinente del proveedor. Comprueba quién es responsable de cada fuente y si hacen falta todos sus campos. Trata el texto de los archivos como información que se debe evaluar, no como instrucciones que puedan cambiar las reglas del agente. - **Capacidad:** Concede solo los permisos de lectura necesarios para comparar esos materiales y la posibilidad de preparar un borrador. El agente no necesita permiso para modificar el registro del proveedor, enviar una solicitud ni aprobarlo. - **Entorno:** Ejecuta la revisión en un entorno destinado al personal autorizado de Compras. Una página o espacio privado no sustituye las comprobaciones de identidad ni los controles de acceso de los sistemas conectados. - **Supervisión:** Asigna a una persona revisora para comprobar la brecha citada y aprobar cualquier solicitud que se envíe. Nombra a la persona operadora que atenderá una fuente faltante, evidencia contradictoria o un fallo de acceso. Para conocer el contexto específico del producto, consulta el [resumen de confianza y límites](/es/platform/trust-boundaries). El borrador podría mostrar las acciones permitidas y el estado actual así: > **Revisión de Northstar Supplies (borrador)**\ > **Permitido:** Leer el expediente enviado, la lista vigente y la ficha actual del proveedor; preparar un resumen.\ > **Bloqueado:** Enviar un mensaje, modificar el registro del proveedor o aprobarlo.\ > **Falta:** Un certificado de seguro vigente.\ > **Solicitud en borrador:** «Envíe un certificado de seguro vigente para que la persona revisora de Compras pueda continuar con la revisión».\ > **Estado:** Pendiente de revisión por Compras; no se ha enviado ninguna solicitud. ## Comprueba los permisos reales Escribe la regla en términos claros: > El agente puede leer el expediente de incorporación enviado, la lista vigente y la ficha pertinente del proveedor; después, puede preparar un resumen de revisión y una solicitud en borrador. Una persona revisora de Compras decide si se envía algo o se aprueba algo. Confirma que cada servicio conectado aplique esos límites. Las instrucciones o solicitudes de aprobación, por sí solas, no impiden que una herramienta realice una acción que tenga permiso para realizar. En este ejemplo, prueba una revisión autorizada del expediente y una solicitud no autorizada para aprobar a Northstar o modificar su ficha. Prueba también un expediente que incluya texto que intente redirigir al agente a otra tarea. El sistema debe denegar o remitir la acción no permitida, excluir del resultado los registros ajenos y ofrecer a la persona revisora evidencia suficiente para entender el borrador. ## Mantén un registro de revisión Antes del piloto, documenta a la persona responsable, los usuarios previstos, las fuentes, los permisos de lectura y escritura, el entorno, el punto de aprobación, el procedimiento ante fallos y quién puede pausar el flujo. Vuelve a comprobar estos detalles si cambia el grupo de usuarios, los datos, la integración, el trabajo o el entorno de implementación. Combina esta revisión con [aprobaciones humanas y escalamiento](/es/conocimiento/diseno-de-agentes/revision-humana-de-agentes) y [tareas representativas y casos de fallo](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). Consulta el [ejemplo de agente defensivo](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia): muestra una acción denegada en producción y comprobaciones separadas para la finalización del agente y el cierre de la exposición. ### Revisa las herramientas y el acceso a datos de un agente - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos - Language: es - Description: Inspecciona cada herramienta conectada: su identidad, alcance de datos, operaciones permitidas, efectos, información devuelta y comportamiento ante fallos. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Revisa las herramientas de un agente operación por operación: confirma qué puede leer o cambiar cada una, qué identidad usa, a qué registros llega y qué evidencia demuestra que se respetan los límites. Una instrucción general sobre el flujo no sustituye las comprobaciones de acceso en el sistema conectado. ## Revisa una solicitud de equipo Una persona coordinadora de mantenimiento pide a un agente que compruebe una solicitud de reemplazo frente al catálogo de equipo aprobado y la lista de existencias actuales, y que prepare un borrador de texto para revisión. El agente puede leer el ticket asignado, el catálogo aprobado y las existencias del artículo solicitado en la sede asignada. No puede enviar una compra ni actualizar el inventario. En esta prueba ficticia, las herramientas de consulta usan una cuenta de servicio exclusiva de mantenimiento. Los sistemas conectados permiten leer el ticket asignado y las existencias del artículo en la sede correspondiente, pero deniegan un ticket ajeno y las existencias de otra sede sin devolver su contenido. Se excluye un artículo no aprobado del catálogo; no están disponibles el envío de compras ni las actualizaciones de inventario. El agente devuelve texto de borrador a la persona coordinadora, sin guardar una solicitud en otro sistema. La revisión completa queda así: | Operación | Identidad y alcance | Acceso y efecto | Resultado y respuesta ante fallos | |---|---|---|---| | Consulta del ticket | Cuenta de servicio de mantenimiento; solo la solicitud asignada. | Se permite leerla; el sistema de tickets deniega una solicitud ajena. | Devuelve solo los campos de la solicitud asignada; la denegación no revela detalles. La persona operadora atiende las consultas fallidas. | | Consulta del catálogo | Cuenta de servicio de mantenimiento; artículos y requisitos aprobados. | Se permite leer; no hay una operación para editar el catálogo. Se excluye un artículo no aprobado. | Devuelve el artículo y los requisitos aprobados. Si la fuente no está disponible, no supongas su contenido y deriva la consulta a la persona operadora. | | Consulta de existencias | Cuenta de servicio de mantenimiento; artículo solicitado en la sede asignada. | Se permite leer; se deniega la consulta en otra sede sin revelar su contenido. | Devuelve solo la disponibilidad en la sede asignada. Si falla la consulta, deja las existencias sin verificar y deriva el caso a la persona operadora. | | Borrador de solicitud | El flujo devuelve texto a la persona coordinadora; esta respuesta no usa una identidad de sistema conectado. | Se permite preparar el borrador; no está disponible el envío de una compra. | Devuelve texto para revisión. Si falla una consulta necesaria, marca el borrador como incompleto y no envíes una compra. | | Actualización del inventario | No se concede identidad ni operación de actualización. | Bloqueada; cambiaría el registro del inventario. | No cambia ningún dato de inventario. Si el sistema configurado permite intentar una actualización, pausa la prueba hasta comprobar que la deniegue. | **Decisión:** Limitar la prueba piloto a las operaciones de lectura y redacción indicadas; la persona operadora resuelve las consultas fallidas. Esta revisión comprueba las herramientas y rutas de datos reales del ejemplo. No implica que una plataforma determinada ofrezca estos controles; confirma cada operación en el sistema configurado. ![Una tarea rodeada de cuatro categorías conectadas: conocimiento, habilidades, herramientas y conexiones](/content/knowledge/visuals/es-knowledge-skills-tools-and-connections.svg) *El conocimiento, los procedimientos, las herramientas y las conexiones cumplen funciones distintas en una tarea.* ## Registra una fila por cada operación | Comprobación | Preguntas que conviene responder | |---|---| | Responsable y propósito | ¿Quién es responsable de la fuente o el servicio? ¿Qué paso del trabajo necesita esta operación? | | Identidad | ¿La llamada se ejecuta como persona usuaria, agente, servicio o cuenta compartida? ¿A quién representa esa identidad y se puede revocar? | | Alcance | ¿A qué registros, carpetas, campos o espacios de trabajo se puede acceder? ¿El sistema puede limitar la solicitud al caso pertinente? | | Operación y efectos | ¿La herramienta lee, busca, crea un borrador, envía, actualiza, elimina o publica? ¿Qué efecto posterior produce? | | Datos devueltos o enviados | ¿Qué campos recibe el agente y qué información sale hacia el servicio conectado? ¿Se pueden omitir los campos innecesarios? | | Validación y fallos | ¿Cómo se validan las entradas? ¿Qué ocurre ante una denegación, un tiempo de espera agotado, una salida mal formada o una solicitud duplicada? ¿Es seguro reintentar? | | Evidencia y revisión | ¿Qué pruebas de acceso permitido y denegado muestran el comportamiento real? ¿Quién puede ver los fallos e investigarlos? | No supongas que el nombre de un servicio describe todo su alcance de permisos. Una herramienta llamada «consulta» podría exponer resultados de búsqueda amplios; una herramienta llamada «borrador» podría guardar datos en una ubicación compartida. Inspecciona sus argumentos, valores devueltos, efectos y permisos de cuenta reales. ## Prueba las rutas permitidas y bloqueadas Para el ejemplo de equipo, prueba un ticket asignado, uno ajeno, consultas de existencias permitidas y bloqueadas por artículo y sede, un artículo no aprobado del catálogo, una solicitud de compra y un tiempo de espera seguido de un reintento. Confirma qué sistema aplica cada decisión. El agente solo debe recibir el artículo previsto y no debe obtener acceso adicional porque una persona le pida ignorar el límite. Vuelve a probar cuando cambien el conector, la cuenta, el filtro de alcance, la operación o el trabajo del agente. Separa esta revisión por herramienta de la revisión de audiencia y espacio de trabajo en [límites operativos](/es/conocimiento/gobernanza-de-ia/control-de-uso-y-visibilidad), y combínala con [la lista de control de seguridad](/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes). Para distinguir información aprobada, procedimientos, herramientas y conexiones, consulta [conocimiento, habilidades, herramientas y conexiones](/es/conocimiento/conocimiento-y-herramientas/conocimiento-habilidades-herramientas-y-conexiones). En flujos de seguridad, amplía esta revisión por herramienta con la [seguridad de la cadena de suministro de software con IA](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software), relacionando procedencia y artefactos desplegados con los accesos de cada componente. ### Lista de control para revisar la seguridad de un agente de IA - Route: https://agentshelf.ai/es/conocimiento/gobernanza-de-ia/revision-de-seguridad-de-agentes - Language: es - Description: Revisa las personas usuarias, los flujos de información, las identidades, las herramientas, las dependencias, las pruebas y las personas responsables de responder antes de ampliar el uso o el acceso de un agente. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Una revisión de seguridad de un agente de IA traza quién lo usará, qué información manejará, a qué sistemas podrá acceder y cómo responderá el equipo ante fallos o usos indebidos. Úsala para decidir si puede comenzar una prueba acotada y qué problemas deben resolverse primero; no es una certificación de seguridad. ## Empieza con una solicitud sobre documentos de proveedores Un equipo de compras pide a un agente: «Compara este expediente de proveedor con los requisitos de incorporación aprobados. Identifica los documentos faltantes y prepara una solicitud para revisión. No envíes mensajes ni cambies la ficha del proveedor». En una prueba ficticia de acceso, el agente lee el expediente asignado y los requisitos. Se deniegan las operaciones de envío y actualización, pero no se ha verificado el alcance de la ficha del proveedor. Una persona revisora se responsabiliza de cualquier solicitud saliente. La revisión de seguridad completa registra los resultados verificados y mantiene en pausa la ampliación del uso: > **Revisión de documentos de proveedores — decisión de seguridad** > > - **Información:** Expediente presentado y requisitos aprobados; cada fuente tiene una persona responsable. > - **Identidad y audiencia:** El personal autorizado de compras solicita y revisa el trabajo; la superficie pública no tiene acceso al expediente. > - **Capacidades:** Leer las dos fuentes aprobadas y preparar un borrador. El envío y los cambios en la ficha quedan fuera del alcance. > - **Resultado de la prueba:** Se pudo leer el expediente y el requisito asignados; se denegaron el envío y la actualización. El alcance de la ficha del proveedor sigue sin verificarse. > - **Decisión:** No ampliar el uso hasta confirmar el alcance del registro y la ruta de excepción. El ejemplo separa lo que se espera del flujo de lo que deben hacer cumplir los sistemas conectados. Una instrucción escrita no demuestra que una herramienta sea incapaz de realizar una acción restringida. ![Matriz de permisos que compara los recursos Expediente, Lista, Ficha, Mensaje y Aprobación con acciones de lectura, redacción, actualización, envío y aprobación, marcadas como permitidas, sujetas a revisión o bloqueadas](/content/knowledge/visuals/es-ai-agent-permissions-and-boundaries.svg) *La matriz de recursos y acciones es una parte de la revisión de seguridad más amplia.* ## Revisa las preguntas de seguridad | Área de revisión | Preguntas y evidencia | |---|---| | Propósito, usuarios y datos | ¿Qué tarea exacta está dentro del alcance? ¿Quiénes usarán el agente, qué datos recibirá y qué resultados podrían afectar a una persona, registro o proceso? Traza el recorrido de la fuente al modelo, a la herramienta y a quien reciba el resultado. | | Identidad y acceso | ¿Qué identidad de usuario, servicio o aplicación origina cada solicitud? ¿Puede el sistema conectado limitarla a los registros y operaciones requeridos? ¿Cómo se protegen, rotan y revocan las credenciales? | | Herramientas y efectos | Enumera cada herramienta, operación, alcance de lectura y escritura y acción con consecuencias. ¿Puede enviar, publicar, actualizar, borrar o aprobar? Retira las capacidades innecesarias y prueba que el sistema conectado rechace las acciones bloqueadas. | | Entradas no confiables y resultados | ¿Puede una persona, documento o página recuperada incluir instrucciones que contradigan la tarea? Comprueba cómo se trata el contenido no confiable y si se valida el resultado antes de que actúe otro sistema. | | Dependencias y exposición | Identifica las dependencias del modelo, conectores, servicios, bibliotecas y datos. Comprueba adónde se envía la información, qué se devuelve y quién puede acceder a los registros almacenados. | | Pruebas y respuesta | Prueba entradas habituales, mal formadas, contradictorias, fuera de alcance y deliberadamente engañosas. Nombra el contacto de seguridad, la ruta de incidentes, la persona operadora, los registros disponibles y la condición para pausar el flujo. | Elige el nivel de revisión según los datos, la audiencia, las acciones y sus consecuencias. Una prueba que solo prepara borradores también requiere límites, pero un agente que accede a sistemas sensibles o puede iniciar cambios externos requiere un análisis de seguridad y privacidad más profundo. ## Separa la aprobación de seguridad de la calidad del flujo La revisión de seguridad determina si el acceso, el tratamiento de los datos y los controles son apropiados para el despliegue propuesto. La evaluación determina si el agente produce resultados útiles y precisos en casos representativos. La revisión humana decide si un resultado o una acción concreta es aceptable. Superar una prueba de una categoría no resuelve las demás. En el ejemplo de proveedores, una persona revisora puede aprobar una prueba piloto limitada solo después de confirmar que el agente puede leer el expediente y los requisitos previstos, no puede enviar ni actualizar datos y deriva el caso con claridad si una fuente no está disponible. Registra la configuración probada y los problemas pendientes. Si se desconoce el comportamiento real de los permisos, mantén la prueba piloto en pausa. Vuelve a revisar si cambian las personas usuarias, las fuentes de datos, el modelo, las herramientas, la audiencia o las acciones de salida. Para revisar cada herramienta, consulta [cómo revisar las herramientas y el acceso a datos de un agente](/es/conocimiento/gobernanza-de-ia/revisar-herramientas-y-acceso-a-datos); para probar resultados, consulta [cómo evaluar un agente de IA](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia). La [guía de permisos y límites](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) aborda los límites de información y acción del agente. Si el agente defenderá tus sistemas, aplica esta revisión a [su ficha de tarea defensiva](/es/conocimiento/ciberdefensa-con-ia/agentes-defensivos-de-ia) y al [software y los proveedores en los que confía](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software). ### Ruta de integración para desarrolladores - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes - Language: es - Description: Planifica los límites de confianza, el ciclo de vida y el manejo de errores para integrar AgentShelf; después, consulta la documentación vigente del SDK. - Updated At: 2026-10-23 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-23) Decide qué pueden pedirle los usuarios al agente, dónde debe guardarse la configuración de confianza y cómo gestionará tu aplicación el trabajo incompleto o fallido. Deja claras esas reglas tanto en la aplicación como en el flujo del agente. ![El navegador, el servidor, el agente y el resultado están conectados mediante límites de autenticación, sesión y errores.](/content/knowledge/visuals/es-developers.svg) Esta ruta orienta a desarrolladores y revisores técnicos. Consulta la documentación enlazada para conocer los tipos exactos del SDK, la configuración y los pasos de implementación. ## Explicita las decisiones de integración Antes de implementar, identifica el entorno de ejecución, el recorrido del usuario, la información que cruza cada límite y quién responde por cada credencial. Define qué considera la aplicación una tarea completada. Que aparezca un mensaje en la interfaz y que se complete una acción externa solicitada son hechos distintos. Usa la [guía de arquitectura](/es/conocimiento/fundamentos-de-ia/arquitectura-de-un-agente-de-ia) para alinear al equipo en los conceptos y la [guía de permisos](/es/conocimiento/gobernanza-de-ia/permisos-y-limites-de-agentes) para revisar las facultades del agente. ## Consulta la documentación de referencia | Pregunta de implementación | Documentación | | --- | --- | | ¿Cómo inicio una integración de agente externo? | [Primeros pasos](/docs/es/getting-started) | | ¿Cómo funcionan las sesiones y el almacenamiento? | [Sesiones y almacenamiento](/docs/es/sessions-and-storage) | | ¿Cómo se gestionan las conversaciones y la transmisión de datos? | [Conversaciones y transmisión de datos](/docs/es/conversations-and-streaming) | | ¿Dónde encajan los archivos y los resultados generados? | [Archivos y resultados](/docs/es/files-and-artifacts) | | ¿Qué conceptos de políticas y capacidades se aplican? | [Políticas y capacidades](/docs/es/policy-and-capabilities) | | ¿Qué relación tienen los espacios de trabajo con la integración? | [Espacios de trabajo](/docs/es/workspaces) | ## Incluye los fallos en el diseño de la aplicación Planifica qué verá el usuario si se deniega el acceso, se agota el tiempo de espera, se interrumpe una conversación o no está disponible el resultado esperado. No indiques que una tarea se completó con éxito hasta contar con la evidencia que exige el flujo de trabajo. Revisa cómo se gestionan los reintentos cuando una acción podría generar un cambio externo duplicado. Usa la [guía de evaluación](/es/conocimiento/gobernanza-de-ia/evaluar-un-agente-de-ia) para crear casos de integración junto con las pruebas de la aplicación. Vuelve a la [documentación](/docs/es) para consultar las instrucciones de implementación vigentes a medida que evoluciona la integración. ## Conecta flujos defensivos Para agentes que revisan los sistemas y servicios conectados, consulta la [ruta de ciberdefensa](/es/conocimiento/ciberdefensa-con-ia). La [guía de cadena de suministro](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software) relaciona evidencia de versiones, artefactos desplegados y permisos efectivos. ## Todas las guías de este tema - [Decide cuándo un agente externo necesita un espacio de trabajo](/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos): Usa un espacio de trabajo solo para capacidades que necesiten estado duradero; después, verifica qué capacidades se habilitaron y si el entorno de ejecución está listo. - [Diagnostica una integración con un agente externo desde el primer límite que falla](/es/conocimiento/integracion-de-agentes/resolver-problemas-de-integracion): Sigue la autenticación, la política, la sesión, el espacio de trabajo, la entrada y el stream antes de cambiar código o volver a intentarlo. - [Integra un agente con el SDK de agentes externos](/es/conocimiento/integracion-de-agentes/integrar-un-agente-con-el-sdk): Mantén la autenticación de usuarios y la firma de aserciones en el servidor; después, usa el cliente del SDK para establecer una sesión y consultar la política pública del agente. - [Lee la política de un agente externo antes de diseñar su interfaz](/es/conocimiento/integracion-de-agentes/politica-y-capacidades): Consulta las capacidades públicas y los límites del agente; diseña la interfaz con la configuración negociada, no con lo que solicitaste. - [Mantén separadas las referencias públicas y las credenciales de inicialización](/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro): El navegador puede usar la referencia pública de un agente, pero un servidor autenticado debe firmar la aserción de inicialización y proteger la credencial de firma. - [Sesiones, conversaciones, streaming, archivos y artefactos](/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos): Mantén diferenciados la identidad de sesión, el historial de conversaciones, los eventos de transmisión, los archivos cargados y los artefactos del agente en toda la integración. - [Conmutación entre proveedores de LLM](/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm): Planifica alternativas aprobadas, comprobaciones de compatibilidad y estados incompletos seguros. - [Pasarela de LLM y plataforma de agentes de IA](/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes): Distingue el enrutamiento de modelos de la ejecución, los permisos de herramientas y la revisión. ### Conmutación entre proveedores de LLM: cómo prepararse ante un modelo no disponible - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm - Language: es - Description: Planifica rutas alternativas, comprobaciones de compatibilidad y estados de fallo seguros sin asumir que otro modelo puede reanudar cualquier tarea. - Updated At: 2026-10-16 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-10-16) La conmutación entre proveedores de LLM dirige una solicitud apta hacia una alternativa cuando la ruta preferida no puede atenderla. Puede reducir la dependencia de un proveedor, pero la recuperación útil también depende de la tarea, del modelo sustituto y de lo que ya ocurrió en el flujo del agente. La pregunta de planificación es concreta: si esta llamada al modelo no termina, ¿qué puede hacer el sistema de forma segura? ![Una solicitud llega al proveedor preferido o a una alternativa aprobada tras comprobar su idoneidad; las solicitudes sin resolver pasan a revisión.](/content/knowledge/visuals/es-llm-provider-failover.svg) *Recurre solo a una alternativa aprobada; si no la hay, envía la solicitud a revisión.* ## Distingue reintento, cambio de ruta y recuperación Un **reintento** repite una solicitud, a menudo después de una espera. La **conmutación** cambia la ruta que la atiende. La **recuperación del flujo** determina si la tarea completa puede continuar de forma segura. Cambiar de región dentro de un servicio y cambiar de proveedor son diseños diferentes; ninguno restaura automáticamente el estado del agente. Define límites para la espera y los intentos con alternativas. Los intentos repetidos pueden añadir latencia y costo, por lo que la aplicación necesita un punto de parada y una forma de comunicar un resultado incompleto. ## Elige un patrón de enrutamiento alternativo Cuando falla el modelo preferido, hay dos formas comunes de elegir el siguiente. Un **respaldo ordenado** prueba modelos aprobados en un orden fijo. Un **respaldo por capacidades** prueba solo modelos que pueden realizar esta tarea: por sus entradas, formato de salida, herramientas y dónde pueden procesar los datos. En ambos casos, la regla para *detenerse* importa tanto como la lista de alternativas. Cada intento adicional suma tiempo y puede sumar costo, y un modelo que no puede hacer el trabajo no es una recuperación. Así se desarrolla una tarea. Un agente redacta un seguimiento de inspección cuando su modelo preferido deja de responder antes de producir algo útil. Reintenta una vez y la llamada vuelve a fallar, así que cambia a la alternativa aprobada que ya superó las mismas pruebas. El borrador llega completo. Antes de ofrecer enviarlo, el agente revisa el registro de entrega. Un intento anterior quizá ya se envió y el nuevo modelo no puede saberlo. El siguiente paso del agente depende de lo que pueda ver: | Lo que ve el agente | Qué hace | Lo que necesita para decidir | | --- | --- | --- | | Un error breve antes de una salida útil | Lo intenta de nuevo dentro de un número fijo de intentos y un límite de tiempo. | Qué falló, cuánto tiempo ha pasado y cuántos intentos quedan. | | El modelo preferido no está disponible | Cambia a una alternativa aprobada si las reglas lo permiten. | Si la alternativa está aprobada para esta tarea y estos datos. | | No hay un modelo adecuado o no quedan intentos | Se detiene y muestra la tarea como incompleta. | A quién avisar y qué debe hacer esa persona después. | | Solo llegó una parte del borrador | Marca el borrador como parcial y pregunta si debe empezar uno nuevo. | Qué llegó y qué ya vio la persona usuaria. | | Una acción, como enviar un mensaje, quizá ya ocurrió | Revisa el sistema conectado antes de repetir nada. | La confirmación de ese sistema, no una suposición del modelo. | ## Evalúa un servicio de conmutación por la tarea completa Pregunta a cualquier proveedor qué errores provocan otro intento, cómo se eligen las alternativas aprobadas, cuándo se detienen los intentos y qué pueden ver tus operadores después. Pregunta si el servicio solo cambia solicitudes de modelo o también lleva el estado de la tarea. Prueba solicitudes normales y fallos con cada alternativa aprobada antes de depender de ella. Una llamada correcta al modelo no puede decirte si un correo anterior se envió o si una actualización pasó. Recuperar el flujo exige esa comprobación por separado. Compara la calidad de cada alternativa y su [costo por tarea completada](/es/conocimiento/gobernanza-de-ia/gobernanza-y-control-de-costos#calcula-el-costo-por-tarea-completada), no solo su disponibilidad. ## Comprueba la alternativa antes de necesitarla El destino alternativo debe estar aprobado para el trabajo que reciba. Revisa estas cuestiones con la persona responsable del sistema: | Comprobación | Por qué importa | | --- | --- | | Compatibilidad de entrada | El sustituto debe aceptar el contexto y los tipos de entrada necesarios. | | Salida y herramientas | Valida los campos obligatorios y los argumentos de herramientas sin asumir comportamientos idénticos. | | Calidad | Ejecuta los casos de evaluación de la tarea con cada opción aprobada. | | Destino de los datos | Confirma dónde se pueden procesar las solicitudes antes de ampliar las rutas. | | Costo y capacidad | Cada alternativa tiene precios y límites propios. | | Visibilidad operativa | Registra las rutas intentadas y si la aplicación recibió un resultado utilizable. | Un modelo capaz de responder preguntas generales puede no ser adecuado para extraer datos de documentos. Vincula la aptitud de cada alternativa a la tarea. ## Ejemplo: recuperar un borrador sin repetir una acción Una empresa ficticia de servicios utiliza un agente para redactar un mensaje posterior a una inspección. El registro de inspección permanece en modo de solo lectura durante la redacción. Si el modelo preferido no está disponible antes de producir un borrador utilizable, el equipo permite que una alternativa evaluada intente ese paso. Enviar el mensaje es una acción separada que requiere aprobación. Si se produce un fallo posterior a un intento de envío, la aplicación consulta el registro de entrega antes de ofrecer otro intento. Cambiar de modelo no demuestra que el envío anterior haya fallado. Ante una respuesta interrumpida, la interfaz debe distinguir un borrador parcial de un resultado final. No añadas la salida de otro modelo al texto parcial como si fuera una única respuesta coherente, salvo que ese comportamiento se haya diseñado y verificado. ## Prueba los fallos junto con las solicitudes habituales En un piloto controlado, comprueba: 1. Ruta preferida no disponible antes de comenzar la respuesta. 2. Alternativa incapaz de cumplir el formato de salida. 3. Ninguna alternativa aprobada disponible. 4. Respuesta interrumpida tras mostrar texto parcial. 5. Acción de herramienta cuyo resultado no se conoce con certeza. En cada caso, especifica el estado visible, la evidencia para operaciones y el siguiente paso permitido. «Sin completar; requiere revisión» puede ser el resultado correcto. Mide la finalización de tareas por separado del éxito de las llamadas al modelo y consulta la [observabilidad de agentes](/es/conocimiento/gobernanza-de-ia/observabilidad-de-agentes) para definir la evidencia necesaria. > **En AgentShelf** > > La [arquitectura publicada](/es/technology/architecture) de AgentShelf describe conmutación automática entre siete o más proveedores. La [página de infraestructura](/es/technology/infrastructure) explica el acceso a modelos configurados; la disponibilidad depende de la configuración, las credenciales, la región, el plan y el catálogo. Los límites de reintento, lo que sucede con una respuesta interrumpida, si alguna vez se repite una acción de herramienta y cualquier compromiso de disponibilidad dependen de tu configuración. Prueba la recuperación de tu propio flujo antes de depender de ella. Para conocer el contexto, consulta [qué incluye la infraestructura para LLM](/es/conocimiento/fundamentos-de-ia/infraestructura-para-llm) y [qué hace una pasarela](/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes). ### Decide cuándo un agente externo necesita un espacio de trabajo - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos - Language: es - Description: Usa un espacio de trabajo solo para capacidades que necesiten estado duradero; después, verifica qué capacidades se habilitaron y si el entorno de ejecución está listo. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Un agente externo puede usar un espacio de trabajo opcional para funciones que necesitan estado duradero, como archivos de una biblioteca de contexto o scripts. Una integración que solo usa chat no lo necesita. Si solicitas un espacio de trabajo, usa una clave estable, comprueba qué capacidades se habilitaron y espera a que el entorno de ejecución esté listo antes de mostrar las acciones que dependen de él. ![El navegador, el servidor, el agente y el resultado se conectan mediante límites de autenticación, sesión y errores.](/content/knowledge/visuals/es-developers.svg) *El diagrama muestra el navegador, el servidor, el agente, el resultado y los límites de sesión y error; los flujos que necesitan estado duradero también deben comprobar que el entorno esté listo.* ## Decide si la función necesita estado duradero Empieza por la tarea que verá el usuario, en vez de aprovisionar un espacio de trabajo por defecto. La mensajería, el historial de conversaciones y los artefactos pueden usar la sesión pública sin `ensureWorkspace()`. Las operaciones con archivos de la biblioteca de contexto y las funciones que requieren ejecutar scripts dependen de un binding de espacio de trabajo materializado y del soporte de la política. | Necesidad de integración | Decisión sobre el espacio de trabajo | | --- | --- | | Enviar y transmitir un turno de chat | No hace falta solo por este motivo. | | Recuperar un artefacto de un turno completado | No hace falta solo por este motivo. | | Leer o actualizar archivos de la biblioteca de contexto del agente | Es necesario, con soporte de la política. | | Ejecutar scripts en el entorno de ejecución del espacio de trabajo | Es necesario y `canRunScripts` debe estar listo. | La política pública sigue formando parte de la decisión. La respuesta del espacio de trabajo incluye `capabilitiesEnabled`, que puede ser más limitada que `requestedCapabilities`; que exista un binding no demuestra que estén disponibles todas las operaciones solicitadas. ## Materializa un asiento lógico de espacio de trabajo El cliente documentado acepta las capacidades solicitadas y un `clientWorkspaceKey`: ```ts const workspace = await client.ensureWorkspace({ requestedCapabilities: ['files'], clientWorkspaceKey: 'checkout-support-seat', }); console.log(workspace.workspaceBindingRef, workspace.capabilitiesEnabled); ``` Elige la clave para el asiento lógico que representa la integración y reutilízala para ese mismo asiento. La clave es idempotente: una solicitud repetida devuelve el mismo binding en vez de acumular otro. No generes una nueva clave aleatoria en cada carga de página. Trata la referencia pública del espacio de trabajo como una referencia; no sustituye la identidad de sesión ni una comprobación de autorización. ## Espera a que el entorno esté listo Un binding puede existir mientras su entorno de ejecución todavía se aprovisiona. Evalúa los indicadores de estado en lugar de suponer que una respuesta de binding correcta demuestra que ya se puede empezar el trabajo: ```ts const status = await client.getWorkspaceRuntimeStatus(); if (!status.ready) { await client.waitForWorkspaceRuntime({ timeoutMs: 60_000, pollIntervalMs: 2_000, }); } ``` El estado incluye `ready`, `provisioning`, `failed`, `canRunScripts` y `hasContainer`, además de campos del ciclo de vida y estado. Muestra una espera útil mientras se aprovisiona el entorno. Un vencimiento de tiempo significa que no estuvo listo dentro del período solicitado; una espera cancelada significa que quien llamó la función la canceló. Trata `failed: true` como estado terminal en vez de sondearlo indefinidamente. Para cancelar una espera, pasa una señal `AbortSignal`, tal como se explica en la [guía de espacios de trabajo](/docs/es/workspaces). > **Comprobación de configuración completada (portal de soporte ficticio)** > > **Solicitud:** El portal necesita una biblioteca de contexto persistente para el agente de soporte; el chat habitual funciona sin ella. > > **Espacio de trabajo:** `ensureWorkspace()` recibe `requestedCapabilities: ['files']` y la clave estable `support:employee-42`. > > **Permiso:** La respuesta incluye una `workspaceBindingRef` pública y `capabilitiesEnabled: ['files']`. > > **Disponibilidad:** El estado del entorno de ejecución indica `ready: true`; la aplicación habilita la acción de la biblioteca de contexto después de comprobar también el soporte de la política. > > **Repetición:** Al volver a usar `support:employee-42`, se devuelve el mismo binding con `created: false`. Este ejemplo distingue tres hechos: la aplicación solicitó un binding, el servidor informó qué capacidad habilitó y el entorno de ejecución indicó si estaba listo. Si falta cualquiera de esas comprobaciones, mantén deshabilitada la función dependiente. La API del espacio de trabajo expone referencias públicas, no IDs internos de espacios de trabajo ni ubicaciones de almacenamiento. ## Comprueba todos los límites Antes del lanzamiento, confirma que la tarea realmente requiere estado duradero, que la clave solicitada siga siendo estable para el asiento previsto, que las capacidades habilitadas satisfagan la tarea y que la preparación se compruebe antes del uso. Después, prueba una solicitud repetida y una ruta donde el entorno no esté disponible. Para la identidad de sesión y los tokens almacenados, consulta [referencias públicas e inicialización segura](/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro); para archivos que se pasan en una conversación, consulta [sesiones, conversaciones y artefactos](/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos). ### Integra un agente con el SDK de agentes externos - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/integrar-un-agente-con-el-sdk - Language: es - Description: Mantén la autenticación de usuarios y la firma de aserciones en el servidor; después, usa el cliente del SDK para establecer una sesión y consultar la política pública del agente. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Tu servidor autentica al usuario y firma una aserción de arranque. El cliente del SDK en el navegador obtiene esa aserción mediante una función de retorno, establece una sesión pública y expone la política vigente del agente para que tu aplicación la consulte. Mantén separadas esas responsabilidades del servidor y del navegador al integrar un agente externo. ![Navegador, servidor, agente y resultado conectados mediante límites de autenticación, sesión y errores.](/content/knowledge/visuals/es-developers.svg) *El diagrama muestra el navegador, el servidor, el agente, el resultado, la sesión y la ruta de error; los pasos siguientes aplican esos límites a un agente integrado.* ## Mantén la confianza en el servidor y la interacción en la aplicación El navegador es donde la persona visitante usa tu aplicación. El servidor es donde la autenticas y proteges la credencial que firma las aserciones. El SDK de agentes externos se conecta al runtime público con una referencia `externalAgentRef` y una función `getBootstrapAssertion`. La función devuelve una aserción firmada; no la firma por sí misma. La guía del SDK documenta esta estructura de cliente: ```ts import { createExternalAgentClient } from '@agentshelf/external-agents-sdk'; const client = createExternalAgentClient({ externalAgentRef: 'ext_agent_public_12345678', getBootstrapAssertion: async () => { const response = await fetch('/api/agentshelf/bootstrap-assertion'); if (!response.ok) { throw new Error('No se pudo obtener la aserción de arranque'); } return response.text(); }, }); ``` La ruta del endpoint es un ejemplo de la guía oficial, no una ruta que cree el SDK. El controlador del servidor debe autenticar a la persona usuaria y emitir la aserción. No incluyas la credencial de firma en el código del navegador ni la devuelvas desde el endpoint. Sigue la guía canónica de [primeros pasos](/docs/es/getting-started) para ver la configuración completa del servidor y del cliente. ## Completa una integración acotada Empieza con un solo recorrido, por ejemplo, una persona que inició sesión pregunta al centro de servicio interno por el estado de una solicitud. Define qué identidad verifica el servidor, qué referencia de agente externo configura la aplicación y qué verá la persona si el endpoint de aserción o el runtime no están disponibles. 1. **Autentica en el límite de la aplicación.** El endpoint del servidor comprueba la sesión habitual de la aplicación antes de emitir una aserción para esa persona. 2. **Crea el cliente del SDK.** Mantén la referencia pública del agente en la configuración de la aplicación y haz que `getBootstrapAssertion` llame al endpoint autenticado. 3. **Establece la sesión y consulta su política.** Llama a `ensure()` y luego a `getEffectivePolicy()` antes de mostrar acciones o iniciar una conversación. 4. **Muestra solo las acciones admitidas.** Usa las capacidades y herramientas de dominio de la política para decidir qué controles aparecen. Un control de interfaz no protege el acceso; el sistema también debe aplicar los permisos. 5. **Trata explícitamente el resultado.** Muestra el flujo de respuesta en la conversación y distingue un mensaje completado de un error, una interacción pendiente o una solicitud de aprobación. > **Comprobación de integración (centro de servicio ficticio)**\ > **Solicitud:** Una persona empleada que inició sesión pregunta por el estado de SR-204.\ > **Sesión:** `ensure()` crea una sesión o reutiliza una sesión guardada válida y devuelve una referencia pública `sessionRef`.\ > **Política:** El agente ofrece mensajería y conversaciones; la aplicación no muestra controles no admitidos.\ > **Registro consultado:** El registro aprobado del sistema de servicio SR-204 tiene el estado «En revisión».\ > **Resultado:** El flujo termina con `message:complete` e indica «En revisión». No se solicita modificar ningún registro. Este ejemplo supone que el agente está configurado por separado con una forma aprobada de consultar SR-204. El cliente del SDK no crea esa conexión con el sistema de negocio. Si la función depende de archivos, artefactos o una herramienta de dominio, consulta la política pública antes de diseñar la interfaz. Para ver los campos exactos de las capacidades, continúa con [políticas y capacidades](/docs/es/policy-and-capabilities). ## Revisa las sesiones y los errores Por defecto, el SDK guarda el estado de sesión en memoria, así que se pierde al recargar la página. Un adaptador de persistencia puede conservarla, pero el registro almacenado incluye el token portador de sesión. Elige el almacén según los scripts y usuarios que puedan leerlo, usa una clave `storageKey` distinta para cada agente integrado y revoca la sesión cuando la persona cierre sesión. Define lo que verá la persona ante una solicitud denegada, una sesión caducada, un tiempo de espera agotado o una interrupción del flujo. Para diseñar las referencias públicas y la confianza en el servidor, consulta [referencias públicas y arranque seguro](/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro); para el ciclo de los mensajes, consulta [sesiones, conversaciones, streaming, archivos y artefactos](/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos). ### Pasarela de LLM y plataforma de agentes de IA: qué hace cada capa - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/pasarela-llm-vs-plataforma-de-agentes - Language: es - Description: Compara la pasarela de LLM o de IA (acceso y enrutamiento de modelos) con la plataforma de agentes: ejecución, permisos, herramientas y revisión. - Updated At: 2026-11-03 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-11-03) Una pasarela de LLM se sitúa entre las aplicaciones y los puntos de acceso a modelos. Una plataforma de agentes de IA coordina el trabajo que rodea esas llamadas. Ambas capas pueden formar parte del mismo producto, pero atienden responsabilidades operativas diferentes. Empieza por la capacidad que falta en tu flujo. Un punto común de acceso a modelos y una acción de negocio controlada responden a necesidades distintas. ![La capa del agente contiene trabajo, contexto, herramientas y revisión; una capa de pasarela separada la conecta con los modelos.](/content/knowledge/visuals/es-llm-gateway-vs-agent-platform.svg) *La pasarela gestiona el acceso a los modelos; la capa del agente decide qué puede hacer la tarea.* ## Compara las responsabilidades de cada capa Las pasarelas pueden centralizar rutas, autenticación, registros de uso y políticas de solicitudes. Las plataformas de agentes pueden ofrecer ejecución, contexto, conexiones con herramientas y revisión humana. Comprueba qué incluye realmente cada producto; el nombre de la categoría por sí solo no te lo dice. | Responsabilidad | Pregunta para la pasarela | Pregunta para la plataforma | | --- | --- | --- | | Solicitud al modelo | ¿Qué destino configurado recibe la solicitud? | ¿Cuándo necesita la tarea una llamada al modelo? | | Identidad | ¿Puede esta aplicación llamar al destino? | ¿Puede esta persona ejecutar el agente y usar estas herramientas? | | Contexto | ¿Qué datos pasan por la pasarela? | ¿Qué evidencia aprobada corresponde a la tarea? | | Fallo | ¿Qué ocurre si una ruta no está disponible? | ¿En qué estado queda la tarea tras el fallo? | | Costo | ¿Qué uso del modelo se puede atribuir? | ¿Cuánto costó la tarea completa con todos sus pasos? | | Revisión | ¿Qué políticas de solicitud se aplican? | ¿Quién aprueba una acción con consecuencias? | Por ejemplo, que una pasarela confirme que una aplicación puede llamar a un modelo no significa que una persona pueda actualizar una ficha de cliente. Esa decisión también depende de los permisos de la aplicación y del sistema conectado. ## Pasarela de IA, pasarela de LLM y pasarela de agentes Los proveedores usan estos nombres con flexibilidad. **Pasarela de LLM** y **pasarela de IA** (*AI gateway*) suelen describir la misma capa: un punto de entrada para las solicitudes a modelos que gestiona credenciales, enrutamiento, registros de uso y políticas de solicitud. Algunas pasarelas de IA también dan acceso a otros servicios de IA. Una **pasarela de agentes** (*agent gateway*) suele controlar otro recorrido: el tráfico de los agentes hacia herramientas y hacia otros agentes, como las llamadas a herramientas con Model Context Protocol (MCP) o las solicitudes entre agentes. Algunos productos combinan estas funciones. Ninguna de las tres ejecuta la tarea. Antes de comparar listas de funciones, pregunta qué tráfico controla cada producto (llamadas a modelos, llamadas a herramientas o solicitudes entre agentes) y dónde termina su autoridad. ## Aclara qué significa «enrutador» Un **enrutador de modelos** elige el destino de una solicitud. Un **enrutador de agentes** decide qué agente o flujo atiende un trabajo. Un **selector de herramientas** elige una operación permitida durante la ejecución. Como estas decisiones pueden aparecer juntas en un diagrama, documenta las entradas, la autoridad y el resultado de cada una. Comprueba si la selección cambia el destino de los datos, las acciones permitidas o únicamente el modelo de un paso existente. Prueba esos cambios por separado. ## Separa gestión de proveedores y permisos del negocio Gestionar proveedores de modelos es un trabajo: qué modelos puedes usar, qué credenciales los pagan, cómo se enrutan las solicitudes y qué uso queda registrado. Decidir qué puede hacer un agente con tu información es otro trabajo y la lista de modelos disponibles no responde nada de eso. Que un modelo esté disponible no significa que esté aprobado para los registros de tus clientes. Resuelve estas preguntas con la persona responsable de la pasarela y anota las respuestas: > **Decisiones sobre gestión de proveedores (en blanco)** > > - Credenciales: quién es responsable, para qué se pueden usar y cómo se reemplazan (nunca pegues las claves en el registro): ___ > - Modelos aprobados: cuáles son, dónde pueden procesar sus datos y qué pruebas superaron: ___ > - Cambios de ruta: quién aprueba un cambio y qué pruebas se repiten primero: ___ > - Visibilidad: qué registros de uso y errores pueden ver los operadores, qué falta y quién investiga algo sin explicación: ___ > - Presupuesto: qué política de gasto se aplica a esta solicitud, confirmada mediante una prueba y no asumida porque el tráfico pasa por la pasarela: ___ En AgentShelf, la [infraestructura](/es/technology/infrastructure) explica los proveedores configurados y cómo llegan las solicitudes a ellos. Los [controles de gobernanza y costos](/es/platform/governance-cost-controls) explican qué solicitudes revisa un presupuesto. ## Ejemplo: un asistente de devoluciones Una tienda ficticia ya tiene una aplicación que localiza pedidos, comprueba las condiciones de devolución y prepara respuestas. El equipo quiere un acceso uniforme a modelos desde varias aplicaciones. Una pasarela puede resolver esa dependencia compartida mientras la aplicación conserva la responsabilidad sobre las reglas de devolución. Más adelante, el equipo quiere agentes reutilizables con herramientas definidas y aprobación antes de emitir un reembolso. Eso también requiere decisiones en la capa de ejecución. Cambiar la ruta del modelo no sustituye la autorización del reembolso. Redacta dos criterios de aceptación: - **Acceso al modelo:** Una aplicación aprobada puede utilizar su ruta configurada, y la falta de disponibilidad produce un resultado observable. - **Acción de negocio:** Un reembolso no puede continuar sin la autorización necesaria, incluso después de cambiar de modelo o de sufrir un fallo. Utiliza la [planificación de conmutación](/es/conocimiento/integracion-de-agentes/conmutacion-entre-proveedores-llm) para probar el primer límite y consulta el [entorno de control de agentes](/es/conocimiento/fundamentos-de-ia/entorno-de-control-de-un-agente) para comprender el segundo. ## Elige la capa con un mapa de responsables Antes de añadir infraestructura, asigna responsables de las credenciales, los cambios de ruta, las actualizaciones del entorno, los permisos de herramientas y la respuesta a incidentes. Determina cómo seguirá operaciones una tarea por todas las capas. Una nueva pasarela también necesita supervisión y una persona responsable; puede añadir otra dependencia. Prueba una tarea completa e interrumpe deliberadamente una llamada al modelo. Comprueba si el equipo puede explicar el resultado del modelo y el del negocio. Si las respuestas están repartidas entre sistemas, acuerda la evidencia necesaria antes de ampliar el uso. > **En AgentShelf** > > AgentShelf combina [infraestructura gestionada](/es/technology/infrastructure), un [entorno de control de agentes](/es/platform/agent-harness) y [opciones de ejecución para desarrolladores](/es/technology/developer-runtime). Compara estas funciones documentadas con tu mapa de responsables. El acceso al modelo, la ejecución del agente y los permisos de negocio siguen siendo cuestiones distintas aunque una plataforma abarque varias capas. Revisa las credenciales de la puerta de enlace y la procedencia de sus versiones con la [seguridad de la cadena de suministro de software con IA](/es/conocimiento/ciberdefensa-con-ia/seguridad-de-la-cadena-de-suministro-de-software). El enrutamiento y la gobernanza del agente no resuelven por sí solos el acceso de los proveedores. ### Política y capacidades de agentes externos - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/politica-y-capacidades - Language: es - Description: Consulta las capacidades públicas y los límites del agente; diseña la interfaz con la configuración negociada, no con lo que solicitaste. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Lee la política pública de un agente externo antes de mostrar controles o iniciar un flujo. La política describe las capacidades, los perfiles de stream, los tipos de salida, los campos de contexto del host y las herramientas de dominio que expone el agente. Si llamas a `prepare()` con preferencias, basa la interfaz en el resultado negociado que devuelve el servidor, no en las opciones que solicitaste. ![El navegador, el servidor, el agente y el resultado se conectan; la figura también marca la sesión y una ruta de error explícita.](/content/knowledge/visuals/es-developers.svg) *Revisa la política en el límite de integración con el servidor antes de mostrar una acción en la aplicación.* ## Inspecciona lo que expone el agente Llama a `getEffectivePolicy()` para consultar el agente actual. Su estructura pública incluye indicadores de capacidad para mensajes, conversaciones, archivos, artefactos, interacciones y aprobaciones; perfiles de stream compatibles; tipos de módulos de salida; límites de archivos y de contexto del host; herramientas de dominio; límites de frecuencia y gasto; y el ajuste de detalle público de errores. Organiza la interfaz en torno a las capacidades que requiere la tarea, no a la lista completa de métodos del SDK. Por ejemplo, un control para adjuntar archivos depende de la capacidad `files` del agente y de su `filePolicy`; un flujo que usa una herramienta de dominio depende del estado y los detalles de operación anunciados por esa herramienta. El servidor aplica las restricciones configuradas; la interfaz evita que las personas inicien una ruta no compatible y ofrece una explicación clara. ## Usa los ajustes negociados `prepare()` puede solicitar un perfil de stream, módulos de salida o la visualización de grounding del proveedor. El objeto `negotiated` que devuelve contiene los ajustes resueltos. Configura la vista con esos valores: ```ts const { policy, negotiated } = await client.prepare({ streamProfile: 'runtime-standard-v1', outputModuleTypes: ['citation'], providerGroundingDisplay: true, }); renderWith(negotiated.streamProfile, negotiated.outputModuleTypes); ``` La guía del SDK describe `runtime-standard-v1` como el flujo completo de eventos públicos del runtime, `modules-v1` para módulos de salida estructurados y `chat-legacy-v1` para compatibilidad con integraciones de chat anteriores. Trata estos nombres como las opciones documentadas para la versión actual del SDK; no supongas que el servidor aceptó una preferencia. Consulta la [referencia de políticas](/docs/es/policy-and-capabilities) para ver los tipos completos de los campos. ## Diseña para las herramientas y las aprobaciones Cada herramienta de dominio pública puede describir el tipo de operación, la clase de efecto secundario, la idempotencia, si requiere aprobación, sus esquemas y su estado. Una operación que requiere aprobación puede emitir un evento `approval:requested` durante el stream y esperar una decisión. Mantén visible ese estado pendiente. Una solicitud de aprobación, o una decisión aprobada, no demuestra por sí sola que la operación terminó; muestra el éxito solo cuando lo confirme el resultado de la operación. Esta guía cubre la detección y presentación de aprobaciones. Las declaraciones del SDK de agentes externos 0.1.0 exponen eventos de aprobación, pero no especifican un método dedicado para resolverlas. La [guía de conversaciones](/docs/es/conversations-and-streaming) documenta `respondToInteraction()` para interacciones; no establece que se pueda pasar un `approvalRef` como `interactionRef`. Antes de habilitar controles de aprobación, verifica el flujo de resolución que admite la aplicación para una persona revisora autorizada. Si no hay uno configurado, mantén deshabilitada la acción dependiente y ofrece una derivación al equipo. No omitas la aprobación ni inventes una estructura de respuesta. > **Comprobación de política completada (asistente de compras ficticio)**\ > **Política consultada:** `messages: true`, `conversations: true`, `files: false`, `artifacts: false`.\ > **Negociación:** Se solicitaron `runtime-standard-v1` y citas; la respuesta devuelve `runtime-standard-v1` sin módulos de salida habilitados.\ > **Interfaz:** La aplicación muestra el compositor de conversación, oculta los controles para adjuntar archivos y consultar artefactos, y no presenta un panel de citas.\ > **Resultado:** La persona puede enviar una pregunta de texto; la interfaz no promete una función que la política no expone. El ejemplo representa una respuesta de política ficticia, no la configuración predeterminada de AgentShelf. Una capacidad desactivada produce una denegación de esa capacidad, no datos vacíos. Trata ese estado como una función no disponible y compáralo con la política vigente en vez de repetir la misma solicitud. ## Mantén vigentes las comprobaciones de política Lee la política antes de mostrar controles y vuelve a consultarla cuando cambie el contexto operativo de la integración. No la conserves en caché más tiempo del que permite el ciclo de configuración del producto. Para las funciones que usan espacios de trabajo, comprueba también las capacidades habilitadas en la vinculación y el estado de preparación del runtime. Para diagnosticar fallos, consulta [cómo solucionar problemas de integración con agentes externos](/es/conocimiento/integracion-de-agentes/resolver-problemas-de-integracion); para configurar una sesión, lee [cómo integrar un agente de AgentShelf](/es/conocimiento/integracion-de-agentes/integrar-un-agente-con-el-sdk). ### Referencias públicas y arranque seguro - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro - Language: es - Description: El navegador puede usar la referencia pública de un agente, pero un servidor autenticado debe firmar la aserción de inicialización y proteger la credencial de firma. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Trata una referencia pública como un identificador y una aserción de inicialización como una credencial. La aplicación puede configurar en el cliente una referencia pública `externalAgentRef`, pero solo un servidor autenticado debería generar la aserción firmada que acredita al usuario actual. Después, el SDK crea una sesión cuyo token debe protegerse como una credencial portadora. ![El navegador, el servidor, el agente y el resultado se conectan mediante límites de autenticación, sesión y errores.](/content/knowledge/visuals/es-developers.svg) *El navegador, el servidor, el agente, el resultado y las rutas de sesión y error marcan límites distintos de la integración.* ## Distingue los identificadores de las credenciales Una referencia pública señala un recurso del entorno de ejecución de agentes externos. El registro de sesión que guarda el SDK incluye referencias públicas como `externalAgentRef`, `sessionRef` y, cuando existen, `externalUserRef` o `workspaceBindingRef`. Esas referencias no reemplazan la autenticación de la persona ni convierten una solicitud del navegador en una solicitud autorizada. La aserción de inicialización cumple otra función. La guía de primeros pasos la describe como una cadena breve que produce y firma tu servidor para acreditar al usuario final actual. El SDK la solicita mediante `getBootstrapAssertion`; no la crea ni la firma. Mantén en el servidor la credencial que firma las aserciones y autentica a la persona en el endpoint que genera una. Hay un tercer valor que proteger en el almacenamiento de sesiones: el token de sesión. `getStoredSession()` devuelve metadatos públicos de la sesión sin el token, pero el registro guardado que utiliza el adaptador `RuntimeStorage` sí lo incluye. Cualquiera que pueda leer ese almacenamiento puede actuar como esa sesión hasta que caduque o se revoque. El SDK usa almacenamiento en memoria de forma predeterminada; conservar datos de manera persistente es una decisión deliberada de seguridad y producto. ## Sigue una sesión del navegador En un portal interno de solicitudes, imagina que una persona inicia sesión, abre un asistente de servicio y consulta el estado de la solicitud `SR-204`. La aplicación puede exponer una referencia pública del agente al cliente del navegador. El servidor debe verificar a la persona antes de generar la aserción, y el asistente solo debe recibir la política y las herramientas configuradas para su tarea. 1. **Autentica a la persona en el servidor.** Vincula la solicitud de aserción con la sesión de usuario de la aplicación; no aceptes una identidad indicada únicamente en los datos del navegador. 2. **Devuelve una aserción, no el secreto de firma.** La función de retorno del SDK llama al endpoint autenticado y devuelve la cadena de aserción. Nunca incluyas en el paquete del cliente ni en la respuesta la credencial que la firma. 3. **Crea o reutiliza una sesión.** `ensure()` obtiene una aserción cuando la necesita y guarda el token de sesión. Si ya existe una sesión guardada y válida, la reutiliza sin llamar a la función de retorno de aserción. 4. **Elige dónde guardar la sesión.** La opción predeterminada es la memoria. Si necesitas persistencia, evalúa qué scripts y usuarios pueden leer el adaptador. Usa una `storageKey` distinta para cada agente integrado en la misma página. 5. **Finaliza la sesión de forma intencional.** Al cerrar la sesión, llama al método de revocación del servidor y elimina los datos de sesión guardados localmente según el ciclo de vida de la aplicación. > **Comprobación de límites (portal ficticio)** > > **Configuración del navegador:** Solo la referencia pública `externalAgentRef`. > > **Comprobación del servidor:** La persona está autenticada antes de generar la aserción. > > **Sesión:** `ensure()` devuelve una `sessionRef` pública; la credencial de firma permanece en el servidor. > > **Almacenamiento:** En memoria durante esta visita breve; no se configura un adaptador persistente de sesiones. > > **Registro consultado:** El registro aprobado del sistema de servicio `SR-204` tiene el estado «En revisión». > > **Resultado:** Después de consultar el registro, el agente muestra a la persona el estado «En revisión». No muestra la clave que firma la aserción ni el token de sesión. El ejemplo supone que el agente dispone de otra vía autorizada para consultar la solicitud. La referencia, la aserción y la sesión no le conceden una herramienta que la política del agente no expone. ## Revisa el estado almacenado Comprueba el valor exacto que puede leer cada capa: la configuración del navegador, la respuesta del endpoint de aserciones, la función de retorno del SDK, el contenido del adaptador y el objeto que devuelve `getStoredSession()`. No des por sentado que el token está ausente solo porque el método público no lo devuelve. Para ver la configuración completa, consulta [primeros pasos](/docs/es/getting-started) y [sesiones y almacenamiento](/docs/es/sessions-and-storage). Continúa con [cómo integrar un agente](/es/conocimiento/integracion-de-agentes/integrar-un-agente-con-el-sdk) y [espacios de trabajo y agentes externos](/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos). ### Soluciona problemas de integraciones con agentes externos - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/resolver-problemas-de-integracion - Language: es - Description: Sigue la autenticación, la política, la sesión, el espacio de trabajo, la entrada y el stream antes de cambiar código o volver a intentarlo. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Empieza por la primera comprobación que falla en el flujo de integración. Revisa la autenticación y la aserción firmada, la política pública vigente, el estado de la sesión, la disponibilidad del espacio de trabajo cuando haga falta y la entrada o el evento de stream concreto. Antes de reintentar, averigua si la solicitud falló, espera la intervención de una persona o ya terminó. ![El navegador, el servidor, el agente y el resultado se conectan; la figura también marca la sesión y una ruta de error explícita.](/content/knowledge/visuals/es-developers.svg) *El diagrama señala el navegador, el servidor, el agente, la sesión, el resultado y la ruta de error. Usa esos límites para ubicar el síntoma antes de cambiar la integración.* ## Localiza el primer límite que falla | Límite y síntoma | Evidencia que debes revisar | Siguiente paso seguro | | --- | --- | --- | | Autenticación: no hay sesión | Confirma que la persona usuaria llega al endpoint de aserción y que la función de retorno devuelve una cadena de aserción firmada. | Corrige la autenticación o la generación de aserciones en el servidor; conserva allí la credencial de firma. | | Política: control ausente o denegado | Comprueba los indicadores de capacidad vigentes, los campos de política pertinentes y cualquier ajuste negociado que se haya devuelto. | Oculta los controles no disponibles; una denegación estable `unsupported_capability` no es un resultado vacío. | | Sesión: estado ausente o desactualizado | Comprueba los métodos de sesión y los metadatos de `sessionRef`; revisa por separado el `conversationRef` activo en el estado de la aplicación. | Verifica cada referencia en su propio límite; sigue el ciclo de vida de la sesión para renovarla o revocarla. No registres el token portador. | | Espacio de trabajo: acción duradera bloqueada | Comprueba que la tarea necesite un espacio de trabajo, las capacidades concedidas y el estado del runtime. | La guía vigente no requiere uno para chat, streaming ni artefactos de un turno; para las tareas que sí lo necesitan, espera durante el aprovisionamiento y trata `failed: true` como terminal. | | Entrada: contexto o archivo rechazado | Comprueba los campos de host aceptados y el límite de bytes; para archivos, revisa política, tipo, tamaño y estado. | Envía campos planos permitidos; espera a que el archivo esté `available` antes de adjuntar su `fileRef` compatible. | | Stream: turno incompleto | Comprueba la finalización, el campo `retryable` de un evento `error`, las interacciones o aprobaciones pendientes y las interrupciones. | Mantén abiertos los estados pendientes; reintenta solo si el error y la operación permiten repetirla de forma segura, y concilia primero los resultados inciertos. | Estas comprobaciones provienen de las guías de integración vigentes. El orden ayuda a acotar la búsqueda, pero no garantiza que cada síntoma tenga una sola causa. Registra el método público, los campos de política pertinentes, el tipo de evento y los indicadores del runtime, sin guardar tokens de portador, aserciones, entradas privadas ni identificadores internos sin filtrar. ## Comprueba el contrato de entrada, no solo la compilación La guía de primeros pasos define `hostContext` como un mapa plano de valores primitivos. También muestra un caso específico en el que un objeto anidado pasa la comprobación de tipos de las declaraciones del SDK, pero el servidor lo rechaza porque el valor no es público. Esto recuerda que las declaraciones de TypeScript y el contrato de ejecución de la solicitud responden a preguntas distintas. Consulta los campos actuales de `hostContextPolicy.acceptedFields` y el límite `maxTotalBytes`; envía solo los campos primitivos permitidos. > **Registro de diagnóstico documentado (no es una reproducción en vivo)**\ > **Entrada de la llamada:** `hostContext` contiene `customer: { type: 'returning', value: true }`.\ > **Comprobación de compilación:** La declaración actual acepta una estructura de objeto JSON.\ > **Comportamiento descrito en la guía:** La documentación de primeros pasos indica que los datos anidados `{ type, value }` se rechazan con `400 host_context_field_not_public`.\ > **Diagnóstico:** Que el tipo sea aceptado no valida la estructura del campo en tiempo de ejecución.\ > **Siguiente comprobación:** Compara las claves primitivas planas con los campos aceptados y el límite de bytes de la política vigente. Este registro resume las declaraciones locales del SDK y la guía; no afirma que el artículo haya probado un runtime en vivo. Si una solicitud de producción se comporta de otra manera, conserva una reproducción mínima sin datos sensibles y pide a la persona responsable del SDK que verifique la implementación actual antes de documentar una corrección. ## Distingue una denegación de un fallo que admite reintento La documentación describe las capacidades desactivadas como denegaciones estables, no como respuestas vacías. Por tanto, una diferencia entre la política solicitada y la concedida indica un problema de configuración o de disponibilidad de la función, no una razón para reintentar a ciegas. Reintenta solo si el error público indica que se puede reintentar y la operación concreta está documentada como segura de repetir; si hay una acción pendiente o un stream interrumpido con resultado incierto, detente y concilia primero su estado. Del mismo modo, `failed: true` en un runtime de espacio de trabajo es terminal; un tiempo de espera al sondear o una espera cancelada significan otra cosa. Puede que un stream también esté esperando una aprobación o interacción en vez de estar averiado. Registra el paso que falló, los campos de política, las referencias públicas, los valores booleanos del runtime y la categoría normalizada del evento o error. No recopiles tokens de sesión ni cadenas de aserción. Para conocer el ciclo de sesión, conversación y stream, consulta [sesiones de agentes, conversaciones y artefactos](/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos); para ver la política, consulta [políticas y capacidades de agentes externos](/es/conocimiento/integracion-de-agentes/politica-y-capacidades), y para conocer el límite de confianza, lee [referencias públicas y arranque seguro](/es/conocimiento/integracion-de-agentes/referencias-publicas-y-arranque-seguro). ### Sesiones de agentes, conversaciones y artefactos - Route: https://agentshelf.ai/es/conocimiento/integracion-de-agentes/sesiones-conversaciones-y-artefactos - Language: es - Description: Mantén diferenciados la identidad de sesión, el historial de conversaciones, los eventos de transmisión, los archivos cargados y los artefactos del agente en toda la integración. - Updated At: 2026-09-28 - Author: AgentShelf - Reviewed By: Gabe Arce (2026-09-28) Distingue cinco objetos en tu integración. La sesión autoriza llamadas públicas al entorno de ejecución y la conversación agrupa mensajes. El flujo transmite lo que ocurre durante un turno. Un archivo es una entrada identificada por una referencia pública; un artefacto es un resultado duradero. Cada uno tiene su propio ciclo de vida y afecta de forma distinta a la interfaz. ![El navegador, el servidor, el agente y el resultado se conectan mediante límites de autenticación, sesión y errores.](/content/knowledge/visuals/es-developers.svg) *Esta vista general muestra los límites de sesión y errores; el ciclo documentado añade conversaciones, archivos y resultados.* ## Elige el objeto adecuado para cada tarea | Objeto | Función en la integración | Qué decisión no toma | | --- | --- | --- | | Sesión | Guarda los metadatos públicos de la sesión y el token utilizado en las llamadas al entorno de ejecución. | Qué conversación ve la persona. | | Conversación | Agrupa mensajes bajo una `conversationRef`. | Si terminó un turno nuevo. | | Flujo | Emite eventos como fragmentos de mensajes, finalización, interacciones y errores. | Si la aplicación puede ignorar una aprobación pendiente o una interrupción. | | Archivo | Entrada cargada con anterioridad, a la que se hace referencia con `fileRef`. | Si la política vigente permite que el agente lo lea. | | Artefacto | Resultado duradero que se puede recuperar con `artifactRef`. | Cómo debe representar la aplicación todos los tipos posibles de resultado. | ## Sigue una revisión de documento Imagina que un portal de operaciones recibe `inspection-notes.pdf` y pide al agente que resuma la condición descrita. Primero, lee la política pública `filePolicy`. Comprueba los permisos `upload`, los tipos MIME permitidos y el tamaño máximo antes de enviar el contenido. La documentación indica que el cuerpo de la carga usa base64; no hay un flujo separado de carga multipart ni mediante una URL firmada. Un archivo nuevo puede tener el estado `processing` antes de estar `available`, así que no trates esos estados como equivalentes. Después de cargarlo, pasa el `fileRef` devuelto en `streamMessage({ fileRefs })` para ese turno. La documentación del SDK no describe otro objeto tipado de adjuntos para el turno, aparte de estas referencias públicas. Durante la transmisión, agrega cada `message:delta` al borrador visible en vez de reemplazar el texto anterior. Trata `message:complete` como el evento que contiene el contenido final y los resultados públicos relacionados. El evento `artifact:created` puede llegar antes de que termine el turno; el evento de finalización también puede incluir artefactos. > **Revisión de documento completada (portal ficticio)** > > **Entrada:** Terminó de cargarse `inspection-notes.pdf` con el estado `available`; su `fileRef` público se adjunta al turno. > > **Conversación:** El turno está asociado con la `conversationRef` actual. > > **Resultado del flujo:** `message:complete` devuelve un resumen y una referencia a un artefacto para una tabla de revisión. > > **Estado de la interfaz:** El resumen aparece como completo; la tabla se abre con `getArtifact()` y hay un método de representación alternativo por si no existe `renderHints`. El ejemplo supone que el agente puede leer el archivo cargado y está configurado para producir ese artefacto. Comprueba la política antes de mostrar controles para archivos o artefactos. Las operaciones con archivos de la biblioteca de contexto son un caso separado: requieren tanto un binding de espacio de trabajo materializado como el soporte de la política. ## Representa solo lo que confirman los eventos Cuando no necesitas mostrar el texto token a token, `collectAssistantMessage()` puede consumir el flujo y devolver el mensaje ensamblado, junto con cualquier uso, referencia, archivo o artefacto generado. Los `renderHints` de un artefacto son metadatos orientativos de presentación, no un contrato de representación; prepara una alternativa segura. Comprueba que la capacidad de artefactos esté habilitada antes de recuperarlos y trata una referencia fuera de los límites como no disponible, sin probar otras sesiones o espacios de trabajo. Para conocer las conversaciones, la cancelación, las interacciones y los tipos de eventos, consulta [conversaciones y streaming](/docs/es/conversations-and-streaming). Continúa con [archivos y artefactos](/docs/es/files-and-artifacts), [sesiones y almacenamiento](/docs/es/sessions-and-storage) y [espacios de trabajo y agentes externos](/es/conocimiento/integracion-de-agentes/espacios-de-trabajo-y-agentes-externos). --- ## Privacy Policy - Route: https://agentshelf.ai/legal/privacy-policy - SEO Title: Privacy Policy | AgentShelf - SEO Description: Learn how AgentShelf collects, uses, and protects your personal information. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/privacy-policy/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/privacy-policy/history ### Privacy Policy **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 This Privacy Policy explains how Agentshelf Inc, a Delaware corporation doing business as AgentShelf ("AgentShelf," "we," "us," or "our"), handles personal information through its websites, platform, applications, agents, widgets, marketplace, voice and messaging features, integrations, and implementation services (the "Services"). We offer the Services to businesses and other organizations. #### 1. Our role and our customers' role Customers decide what information their users and agents submit and how their agents, integrations, public widgets, and communications are configured. When we process personal information on a customer's behalf, we act as its service provider or processor under the applicable agreement. The customer's privacy notice explains its use of that information. Requests about that information should ordinarily be directed to the customer; you may also contact us for help identifying the appropriate recipient. We are responsible for information we use for our own account administration, billing, security, fraud prevention, service operations, customer support, website and marketing activities, marketplace administration, and legal obligations. #### 2. Information we collect The information depends on the Services and features used: - **Account and business information:** names, email addresses, telephone numbers, employer or organization, role, account identifiers, login information, preferences, and communications with us. - **Customer Content and AI responses:** prompts, instructions, messages, files, knowledge sources, images, code, agent settings, credentials, integration data, information sent to or returned by tools, and AI-generated responses. This information may contain personal information supplied by a customer, its users, or people interacting with its agents. - **Public-agent, widget, voice, and messaging information:** visitor and session identifiers, page context, conversations, contact details, telephone numbers, call and message details, recordings, transcripts, delivery events, and consent or opt-out records. Recording depends on the feature and customer configuration. - **Marketplace information:** publisher identity, profiles, listings, published materials, installations, usage, reviews, reports, moderation records, and communications. - **Billing information:** customer, subscription, invoice, transaction, and payment-status information. Stripe processes payment information. We receive limited payment details needed to administer billing and generally do not receive complete payment-card numbers. - **Usage and technical information:** user, organization, workspace, agent, model and provider identifiers; features used; timing; token and computing consumption; costs; performance; errors; and security and audit events. These records can also include IP addresses and browser, device, and network information. - **Operational and diagnostic records:** information used to operate, troubleshoot, support, and secure the Services. These records may contain Customer Content, including message excerpts, tool information, filenames, page addresses, and error details. - **Website and marketing information:** information submitted through contact, waitlist, demo, newsletter, sales, and support forms; page and referring addresses; campaign and referral information; browser identifiers; and interactions with our websites. The information collected depends on the tracking tools and features enabled, including any session-replay features that record website interactions. We receive information directly from people using the Services, automatically through their use, from customers and their connected services, and from our service providers. We may also receive business contact information from partners, referrals, or public business sources. #### 3. How we use information We use personal information to: - provide, operate, personalize, and support the Services and carry out customer instructions; - manage accounts, organizations, permissions, subscriptions, payments, and usage charges; - deliver agents, integrations, public widgets, voice, messaging, and marketplace features; - troubleshoot problems, maintain reliability, and protect against fraud, abuse, unauthorized access, and security incidents; - respond to inquiries, provide service notices, and send marketing messages where permitted; - understand website activity, referrals, campaigns, and conversions; - moderate marketplace materials and investigate complaints; - comply with law, enforce agreements, resolve disputes, and protect legal rights; and - evaluate or complete a financing, merger, acquisition, or other business transaction. We also use usage statistics and technical information that is separate from Customer Content to understand feature use and improve the Services. #### 4. Customer Content and AI providers AgentShelf does not use Customer Content or Outputs to train machine-learning models, including foundation models, and does not use their substance for general product improvement. "Outputs" means AI-generated responses and other content returned by an agent, model, tool, or workflow. This restriction also applies to copies or excerpts in operational and diagnostic records. We may process that content to provide the requested service, troubleshoot or support it, protect security, or meet legal obligations. AI model providers and connected services receive information needed to carry out customer instructions. Their practices depend on the provider, model, account, agreement, and settings. Customers using their own provider accounts may have a direct relationship with those providers. Some providers offer models, sometimes called "Contributor Models," under terms that allow inputs, responses, or feedback to be used for the provider's model or service improvement. That treatment is separate from AgentShelf's own no-training commitment. Any Contributor Model offered through AgentShelf is subject to special disclosure and affirmative organization-administrator authorization under the [AI and Product Schedule](/legal/ai-and-product-schedule). #### 5. How we share information We share information as needed with: - providers supporting hosting, storage, security, monitoring, support, and other service operations; - AI model providers and customer-connected tools and integrations; - Stripe and other providers supporting billing, accounting, taxes, and fraud prevention; - providers and carriers supporting calls, messages, email, recording, and transcription; - analytics, advertising, and marketing providers where those tools are enabled; - the customer responsible for an account, workspace, public agent, or widget, including its authorized administrators; - marketplace users when a publisher makes information or materials public; - professional advisers and parties involved in a business transaction; and - authorities or other parties when required by law or necessary to protect rights, safety, security, or the Services. We do not sell personal information for money. Sharing information with advertising providers for advertising across different businesses' websites or services may be considered a "sale," "sharing," or targeted advertising under applicable privacy laws. The privacy choices described below apply to any such activity covered by those laws. #### 6. Cookies, tracking, and communications choices Our websites, applications, and widgets use cookies, browser storage, tags, and similar technologies for requested features, security, personalization, analytics, and advertising or referral measurement. The [Cookie and Similar Technologies Notice](/legal/cookie-policy) explains these technologies, when tracking starts, and the controls available on each surface, including browser settings and how we handle the Global Privacy Control signal. You may also contact legal@agentshelf.ai to exercise applicable privacy rights. We currently do not respond to browser "Do Not Track" signals. You can opt out of marketing email using the instructions in the message or by contacting us. We may still send account, billing, security, and other service communications. #### 7. How long we keep information Retention depends on the information, its purpose, customer instructions, applicable agreements, and legal requirements: - Customer Content, including conversations, transcripts, and recordings, is kept to provide the Services and carry out customer instructions. Available deletion controls and retention settings differ by feature. - Account, contact, and visitor information is kept for account management, customer relationships, requested personalization, support, and other purposes described in this Policy. - Usage, billing, security, and audit records may be kept after an account closes for accounting, security, fraud prevention, disputes, and legal obligations. Account closure, export rights, and deletion obligations are governed by the applicable customer agreement; the [Platform Terms of Service](/legal/terms-and-conditions) state the standard export and deletion terms. Deletion from active systems does not immediately remove archive or backup copies. Legal holds and other legal obligations may require information to be kept longer. #### 8. Privacy rights and requests Depending on your location and the circumstances, you may have rights to access or know about your personal information, correct it, delete it, obtain a portable copy, withdraw consent, limit certain uses of sensitive information, or opt out of sale, sharing, targeted advertising, or certain profiling. You may also have a right to appeal a denied request. Send requests, including appeals, to legal@agentshelf.ai. We may need information to verify your identity or authority to act for another person. Authorized agents may submit requests as permitted by law. We will not discriminate against you for exercising applicable privacy rights. If the information is processed on a customer's behalf, we may refer the request to that customer or assist it under our agreement. #### 9. Security and processing locations We use safeguards designed to protect personal information, including access controls and measures to protect stored and transmitted information. No service can guarantee complete security. We currently offer the Services to U.S. businesses. We and our providers may process information in the United States and other locations where they operate. #### 10. Minors and third-party services The Services are for businesses and are not intended for anyone under 18. Contact us if you believe a minor has provided personal information. Third-party websites, models, tools, marketplace materials, and integrations have their own privacy practices. Review their notices before providing information or enabling them. #### 11. Changes and contact We may update this Policy as our Services or practices change. We will post the revised Policy with its effective date and last-updated date and provide additional notice or obtain consent when required by law. Changes affecting Customer Content or Outputs processed under a customer agreement remain subject to that agreement's data-use, notice and acceptance requirements. Posting a revised Policy does not itself authorize a new use of that information or a materially different use of previously collected Customer Content. The applicable DPA and legally required privacy rights and choices remain in force. For privacy questions or requests, contact: Agentshelf Inc Attn: Privacy Team 740 Nordahl Road, Suite 110, Unit 297 San Marcos, CA 92069, United States legal@agentshelf.ai --- ## Platform Terms of Service - Route: https://agentshelf.ai/legal/terms-and-conditions - SEO Title: Platform Terms of Service | AgentShelf - SEO Description: Understand your rights and responsibilities when using AgentShelf. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/terms-and-conditions/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/terms-and-conditions/history ### Platform Terms of Service **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 **Canonical URL:** https://agentshelf.ai/legal/terms-and-conditions These Platform Terms of Service (the "Terms") govern access to and use of AgentShelf's hosted platform, websites, applications, agents, widgets, marketplace, communications features, APIs, developer tools, implementation services, and related offerings (collectively, the "Services"). These Terms are intended only for businesses and other organizations, not for personal, family, or household use. If you accept these Terms for an organization, you represent that you have authority to bind that organization. "Customer" means that organization. "You" means Customer and its Authorized Users, as applicable. These Terms are AgentShelf's standard services agreement for business Free, Starter and Pro accounts and other Services that expressly reference them. The Agreement takes effect when Customer affirmatively accepts these Terms through signup or checkout or signs an Order incorporating them. "Order" means an ordering document signed by the parties or an online purchase record affirmatively accepted by Customer identifying the Services and applicable commercial terms. A separate MSA is not required unless the parties expressly agree to use one. #### 1. Contract documents and priority "Platform" means AgentShelf's hosted AI-agent management platform and its AgentShelf-developed applications and platform features. "Documentation" means AgentShelf's documentation provided to Customer for the applicable Services. "Tool" means a function, API, integration or workflow enabled through the Services to retrieve information or perform an action. "DPA" means a data processing addendum between the parties. "SOW" means an accepted statement of work identifying an engagement's scope and commercial terms. "Enterprise MSA" means a master services agreement separately executed by AgentShelf and Customer. "Delivery Partner" means an implementation contractor or partner that AgentShelf engages to help deliver the Services. It does not include a referral partner or other third party that contracts directly with Customer. These Terms and the applicable documents incorporated below form the "Agreement" between AgentShelf and Customer: - [Acceptable Use Policy](/legal/acceptable-use-policy); - [Privacy Policy](/legal/privacy-policy); - [Cookie and Similar Technologies Notice](/legal/cookie-policy); - [AI and Product Schedule](/legal/ai-and-product-schedule); - [Voice and Messaging Schedule](/legal/voice-and-messaging-schedule), when those features are used; - [Marketplace and Publisher Terms](/legal/marketplace-and-publisher-terms), when Marketplace Content is published or installed; - [Supplemental Credit Terms](/legal/supplemental-credit-terms), when Credits are purchased, issued, or used; - [Professional Services Terms](/legal/professional-services-terms), when incorporated into a signed Order or SOW; and - any Order, SOW, DPA, product schedule, or other document that expressly incorporates these Terms. For customers without an executed Enterprise MSA: 1. an amendment signed by both parties that expressly identifies the changed provision controls first; 2. a signed Order or affirmatively accepted online purchase controls its express scope and commercial terms; 3. an executed DPA controls its personal-data processing subject matter; 4. the incorporated product terms (the AI and Product Schedule, Voice and Messaging Schedule, Marketplace and Publisher Terms, Supplemental Credit Terms, and Professional Services Terms) control their subject matter; 5. these Terms and other incorporated policies otherwise apply in that order. An Order does not create an additional indemnity, liability cap or dispute regime unless it expressly identifies and amends the applicable provision in a writing signed by authorized representatives of both parties. No incorporated schedule or policy creates an additional indemnity, warranty, liability cap or dispute regime or expands AgentShelf's indemnity in Section 19.1, except that the Professional Services Terms state the warranty for professional services. If Customer has an executed Enterprise MSA, its contract-priority and amendment provisions control. #### 2. Eligibility and Authorized Users The Services are currently offered to businesses and organizations in the United States. This does not by itself prohibit authorized travel, remote users, or incidental visitors from other locations. Customer remains responsible for lawful deployment and use and must obtain AgentShelf's written approval for use in an unsupported jurisdiction. Approval does not waive legal or provider restrictions. Customer may allow its employees, contractors, and other individuals it authorizes ("Authorized Users") to use the Services for Customer's business purposes. Each Authorized User must be at least 18 years old and legally capable of entering a binding agreement where they reside. Customer is responsible for its Authorized Users, their compliance with the Agreement, and all activity under Customer-controlled accounts, workspaces, credentials, agents, and integrations. Customer will provide accurate registration and billing information, protect account credentials, use appropriate access controls, and promptly notify AgentShelf of suspected unauthorized access. #### 3. The Services AgentShelf provides tools for configuring, deploying, operating, and governing AI agents and related workflows. Customer determines its configurations, Authorized Users, enabled models, connected services, permissions, tools, workflows, deployment channels, and intended uses. AgentShelf may improve or modify the Services over time. Material reductions to purchased functionality are subject to an applicable Order and the notice and acceptance requirements of Section 22. Beta, preview, evaluation, or early-access features may be changed or discontinued and may be subject to additional terms. Section 18 states the terms on which they are provided. AgentShelf may use affiliates, contractors and subcontractors to provide the Services and remains responsible for their performance to the same extent as its own under the Agreement. Applicable confidentiality, security, data-use and data-processing requirements are addressed in Sections 14 and 15 and the applicable DPA. A subcontractor does not become a party to Customer's Agreement or gain authority to bind Customer. #### 4. Organization administration Customer administrators may invite or remove users, assign roles, configure workspaces and agents, manage permissions and integrations, review usage, and access, export, reassign, or delete Customer-controlled information, subject to the functionality of the Services. Customer is responsible for selecting its administrators and for resolving disputes among its users. If an Authorized User uses an email address or account controlled by Customer, Customer may assume control of that account and associated organizational data after reasonable verification and notice where appropriate. #### 5. Fees, subscriptions, and payment ##### 5.1 Orders and recurring subscriptions Fees, plan limits, included usage, billing interval, subscription term, and other commercial terms appear at checkout or in an Order. Platform subscription fees are payable in advance at the start of each applicable billing period, including each renewal period. Self-service subscriptions may be offered monthly or annually and renew for successive periods of the same length unless canceled before renewal. AgentShelf uses a third-party payment processor and may require Customer to accept that processor's terms. Agentshelf Inc is the seller, merchant of record, and contracting party. Customer may cancel a self-service subscription under Section 5.4; an expressly accepted longer commitment remains subject to its accepted terms. AgentShelf will provide at least 30 days' advance notice of an increase in subscription fees unless a shorter period is required to address taxes, provider pricing, law, or an urgent service change. A subscription fee increase does not apply before the end of a paid annual term or other expressly accepted commitment longer than one month. For a month-to-month subscription, an increase applies from the first billing period that starts after the notice period. Changes to metered usage prices are governed by the Supplemental Credit Terms. Saving a payment method, or using or requesting a free offer, does not by itself authorize a charge, automatic recharge, paid overages, or conversion to a paid subscription. ##### 5.2 Usage, credits, and overages Some Services are metered by tokens, compute, model use, communications, storage, agents, users, widgets, or other units. Usage Credits, Promotional Credits, included plan allowances, usage after a balance is exhausted, paid overages, and automatic recharge are governed by the Supplemental Credit Terms, which define those terms. ##### 5.3 Taxes and payment failures Fees exclude taxes unless stated otherwise. Customer is responsible for taxes legally imposed on its purchase, excluding taxes based on AgentShelf's net income. If a properly authorized payment fails or is reversed, AgentShelf may retry collection as permitted by the payment authorization and may withhold activation or renewal, or suspend affected paid features after notice, subject to Section 16 and applicable law. Payment failure does not itself cancel an expressly accepted commitment or excuse amounts properly due. For separately ordered professional services, invoicing terms and any late charges must be expressly agreed in a signed Order or SOW or an executed Enterprise MSA. ##### 5.4 Cancellation and refunds Customer may cancel a self-service subscription through the available account or support process. Unless accepted checkout terms or an Order expressly state a longer commitment, cancellation takes effect at the end of the current paid billing period and stops future renewals. Cancellation does not shorten an expressly accepted longer commitment. Installment schedules, early-termination charges and acceleration of unpaid committed fees apply only where expressly disclosed and accepted in the applicable ordering terms. Fees and Credits are non-refundable except as required by law or expressly stated in an Order, the Supplemental Credit Terms, or this section. If AgentShelf terminates a paid Service without cause or cannot cure a material breach of the express service warranty, Customer's remedy is a refund of prepaid, unused fees and unused purchased Usage Credits attributable to the terminated portion, excluding Promotional Credits. An upgrade may take effect immediately with disclosed proration. A downgrade takes effect at renewal and may require Customer to reduce usage to the new limits. ##### 5.5 Free AI Front Desk offer The free AI Front Desk offer covers website web chat only, with a limited AI usage allowance stated in the offer. Voice, telephone, SMS, and other messaging channels are not included. Eligibility requires a business website and a visible "AI Front Desk Powered by AgentShelf.ai" badge in its footer while using the free plan. AgentShelf may verify eligibility and pause or withdraw free access if the conditions are not met. Submitting a request does not activate an agent or guarantee acceptance or a completion date. The offer is subject to availability and may be changed or discontinued at any time; it does not guarantee indefinite free access. When the included allowance is exhausted, service may pause unless Customer separately agrees to an upgrade. #### 6. Customer Content and Outputs "Customer Content" means information submitted to, stored in, transmitted through, or processed by the Services by or for Customer, including prompts, instructions, messages, files, knowledge sources, recordings, transcripts, configurations, credentials, tool inputs and results, and connected-service data. "Output" means content generated or returned through an agent, model, tool, or workflow in response to Customer Content or Customer's configuration. As between the parties, Customer retains its rights in Customer Content. Customer grants AgentShelf a non-exclusive, worldwide, limited-term right to host, copy, process, transmit, display, and otherwise use Customer Content only as necessary to provide, secure, maintain, and support the Services, carry out Customer's instructions, prevent or address technical, security, fraud, or abuse issues, and comply with law. Subject to third-party rights and applicable law, AgentShelf assigns to Customer any rights AgentShelf may have in Outputs generated specifically for Customer. Because similar inputs can produce similar outputs, Outputs are not guaranteed to be unique and this assignment does not apply to another customer's content or output. "Connected Account" means a third-party account, platform, or service Customer connects to or authorizes AgentShelf to access in connection with the Services. Customer represents, warrants, and covenants that it has and will maintain the rights, licenses, permissions, notices, consents, and lawful basis needed for Customer Content, Customer specifications and instructions, Connected Accounts, and Customer's use, publication, or distribution of Services and Outputs. #### 7. Data use and model training AgentShelf does not use Customer Content or Outputs to train machine-learning models, including foundation models, and does not use their substance for general product improvement. This restriction also applies to copies or excerpts retained in operational, support, security, or diagnostic records, which may contain Customer Content. AgentShelf may process Customer Content and Outputs for the purposes stated in Section 6. "Usage Data" means information about use and performance of the Services, such as features used, model selection, usage quantities, charges, timing, execution traces, error and performance logs, and service reliability, separate from the substance of Customer Content and Outputs. AgentShelf may use Usage Data to operate, secure, meter, analyze, and improve the Services. Third-party model providers process information under the provider arrangements described in the AI and Product Schedule. A Contributor Model, as defined there, may be used only with the organization-administrator authorization that Schedule requires. That exception concerns the provider's use, not AgentShelf's own no-training commitment. #### 8. AI models and Outputs AI Outputs are probabilistic and may be inaccurate, incomplete, offensive, biased, or unsuitable. Customer must evaluate Outputs and apply appropriate human review before relying on them or using them in decisions or external actions. Customer must not represent Output as human-generated when doing so would be deceptive or unlawful. Model availability, behavior, context limits, pricing, latency, and capabilities may change. The AI and Product Schedule governs model selection, default models, provider relationships, and Customer's responsibilities for Outputs. #### 9. Tools, integrations, and external actions Customer controls which tools, credentials, permissions, integrations, and external systems it enables and instructs AgentShelf to transmit information necessary to perform enabled functions. An agent may take actions in connected services using the authority Customer grants. Customer is responsible for configuring least-privilege access and for the approval, human-review, and other safeguards the AI and Product Schedule requires for consequential actions. Third-party services are governed by their own terms. AgentShelf is not responsible for a third-party service, but remains responsible for its own performance of the Services under the Agreement. #### 10. Public agents, widgets, voice, and messaging Customer is responsible for the purpose, instructions, content, branding, deployment, and operation of its public website, agents, widgets, and communications, and for legally required privacy, AI, visitor, recording, transcription, calling, and messaging notices and consents. Privacy roles for visitor data are allocated in the applicable DPA. The Voice and Messaging Schedule governs voice and messaging features, including Customer's responsibility for consent, recording notices, sender registration, opt-outs, calling hours, and communications laws. The Services are not an emergency service. Customer may not use them for emergency calling or represent that AgentShelf provides emergency services. #### 11. Marketplace and published content The Services may allow users to publish, distribute, license, install, or obtain agents, skills, templates, integrations, and related content ("Marketplace Content"). The Marketplace and Publisher Terms govern publication, installation, licensing, moderation, and rights complaints. Customer remains responsible for Marketplace Content it publishes and represents that it has all necessary rights. Third-party Marketplace Content is provided by its publisher, not AgentShelf. Copyright and other rights complaints may be sent to legal@agentshelf.ai. #### 12. Acceptable use Customer and Authorized Users must comply with the Acceptable Use Policy. #### 13. AgentShelf technology and feedback AgentShelf and its licensors own the Services, software, documentation, interfaces, designs, models or configurations supplied by AgentShelf, and all related intellectual-property rights, excluding Customer Content and rights expressly assigned in Output. AgentShelf grants Customer a limited, non-exclusive, non-transferable right to use the Services during the applicable term in accordance with the Agreement. If Customer provides feedback, AgentShelf may use it without obligation. Feedback does not include Customer Content or Outputs, and its use remains subject to the data-use restrictions in Section 7. Submitting a support request or quoting content in feedback does not waive those protections. **Professional services.** Professional services are provided only under a signed Order or SOW and the [Professional Services Terms](/legal/professional-services-terms) it incorporates, which govern scope, acceptance, warranty and ownership of deliverables. Customer retains its supplied materials. AgentShelf retains its Services, pre-existing materials and reusable technology unless expressly agreed otherwise. Third-party components remain subject to their applicable licenses. Section 6 continues to govern Customer Content and Outputs. #### 14. Confidentiality Each party may receive nonpublic information that should reasonably be understood as confidential ("Confidential Information"). The receiving party will use Confidential Information only to perform or exercise rights under the Agreement and will protect it using reasonable care. These obligations do not apply to information the receiving party can document was lawfully known without restriction, independently developed, rightfully received from another source, or made public without breach. A party may disclose Confidential Information to personnel, professional advisers and permitted contractors with a need to know who are bound by appropriate written confidentiality obligations, and remains responsible for their handling of it. A receiving party may disclose Confidential Information when legally required after giving notice where permitted and reasonable assistance at the disclosing party's expense. #### 15. Security, privacy, and data processing AgentShelf will maintain reasonable administrative, technical, and physical safeguards appropriate to the Services and information processed. No service is completely secure, and Customer is responsible for securely configuring its accounts, permissions, integrations, and endpoints. The Privacy Policy describes AgentShelf's handling of personal information for its own purposes. Where AgentShelf processes personal data on Customer's behalf, an applicable DPA governs. Customer is responsible for its own privacy notices, instructions, and legal basis. AgentShelf will give any incident notice required by applicable law and the applicable DPA. Any additional security, support, service-level, uptime, or incident-notification commitment applies only if expressly included in a signed agreement or Order; these Terms do not create one. AgentShelf will require Delivery Partners to comply with appropriate confidentiality, security and data-protection requirements. Any legally required DPA and its subprocessor requirements continue to apply. #### 16. Suspension AgentShelf may suspend affected access when reasonably necessary to prevent or address a security threat, unlawful activity, material policy violation, nonpayment, harm to the Services or third parties, or a provider or legal restriction. When practicable, AgentShelf will provide notice and allow a reasonable opportunity to cure. The opportunity to cure does not apply to suspension for nonpayment, which Section 5.3 governs. Emergency action may occur without advance notice. This section's notice and cure terms apply to suspension of Customer's account access. Restrictions on a specific feature, model, Tool, communication, or item of content are governed by the applicable incorporated schedule or policy. #### 17. Term and termination These Terms begin upon Customer's affirmative acceptance as described above and continue while Customer has an account or active Order. Either party may terminate for material breach if the breach is not cured within 30 days after written notice, or sooner if the breach cannot be cured. AgentShelf may terminate a free service at any time. AgentShelf may terminate a paid Service without cause on written notice, in which case the refund described in Section 5.4 applies. After termination, Customer's access ends. Subject to payment, security, and legal restrictions, Customer may export available Customer Content for 30 days. AgentShelf will then delete Customer Content from its active systems within a reasonable period, in accordance with its retention practices and any applicable DPA, and backup copies are removed in the ordinary course, unless an Order states otherwise or retention is required for security, fraud prevention, billing, audit, legal hold, or compliance. AgentShelf need not restore archival backups solely to complete an ordinary export or deletion. Sections 5 (for amounts accrued), 6, 7, 13, 14, and 17 through 23, and any other provision intended by its nature to survive, survive termination. #### 18. Warranties and disclaimers Each party warrants that it has authority to enter the Agreement. AgentShelf warrants that paid Services will perform materially in accordance with the applicable Documentation. Customer's exclusive remedy for breach of this warranty is for AgentShelf to use commercially reasonable efforts to correct the nonconformity or, if AgentShelf cannot do so, terminate the affected Service and provide the refund described in Section 5.4. Free, trial, beta, preview and evaluation features are provided as is and without a service-level commitment, except as expressly agreed or required by law. AgentShelf's paid-service warranty and its indemnity in Section 19.1 do not apply to those features. EXCEPT AS EXPRESSLY PROVIDED, THE SERVICES, OUTPUTS, BETA FEATURES, AND MARKETPLACE CONTENT ARE PROVIDED "AS IS" AND "AS AVAILABLE." TO THE MAXIMUM EXTENT PERMITTED BY LAW, AGENTSHELF DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. AGENTSHELF DOES NOT WARRANT THAT OUTPUTS ARE ACCURATE OR THAT THE SERVICES WILL BE UNINTERRUPTED OR ERROR-FREE. #### 19. Indemnification **19.1 By AgentShelf.** AgentShelf will defend Customer against a third-party claim alleging that Customer's authorized use during a paid subscription or order term of the unmodified, AgentShelf-developed portions of the Platform infringes a United States patent, copyright, or trademark, and will pay damages and reasonable costs finally awarded by a court or payable under a settlement approved by AgentShelf. This obligation does not apply to a claim arising from: - (a) Customer Content, Customer specifications, or Customer instructions; - (b) Marketplace Content; - (c) a modification not made by AgentShelf; - (d) use outside the Agreement or Documentation; - (e) combination with content, data, products, services, software, or technology not supplied by AgentShelf; - (f) continued use after AgentShelf provides notice or a non-infringing alternative; - (g) a third-party service, model, Tool, integration, or open-source component; - (h) an Output, citation, retrieved or search content, generated code, or Tool result; - (i) a beta, preview, evaluation, trial, or no-fee feature; or - (j) Customer's failure to use an applicable citation, filtering, safety, or approval control made available by AgentShelf. If AgentShelf reasonably believes a covered claim is likely, AgentShelf may obtain continued-use rights, modify or replace the affected portion, or terminate the affected Service and provide the refund described in Section 5.4. **19.2 By Customer.** Customer will defend, indemnify, and hold harmless AgentShelf, its affiliates, licensors, subcontractors, Delivery Partners, and their respective officers, directors, employees, and agents against third-party claims and governmental investigations or proceedings alleging or arising from: - (a) Customer Content, Customer specifications or instructions, or data supplied through a Connected Account; - (b) Customer's agents, websites, widgets, public deployments, communications, products, or services; - (c) Customer's or an Authorized User's use, publication, distribution, or reliance on an Output; - (d) Customer-controlled credentials, permissions, Tools, integrations, or external actions; - (e) Customer's failure to provide a required notice, obtain or document required consent, honor an opt-out, or apply human review or approval required by the Agreement or law; - (f) Marketplace Content published or supplied by Customer; - (g) Customer's breach of the Agreement or applicable third-party or model-provider terms; or - (h) Customer's unlawful use, gross negligence, fraud, or willful misconduct. Customer will pay resulting damages, settlements, and reasonable attorneys', experts', investigation, and defense costs, together with governmental fines or penalties to the extent indemnification for them is permitted by law. **19.3 Procedure.** The indemnified party must promptly notify the indemnifying party of a covered claim, provide reasonable cooperation at the indemnifying party's expense, and allow the indemnifying party to control the defense and settlement. A failure to provide prompt notice or cooperation will relieve the indemnifying party of its obligations only to the extent the failure materially prejudices the defense. The indemnified party may participate through its own counsel at its own expense. Despite the preceding sentences, where the covered claim is a governmental investigation or proceeding, the indemnified party may control its own response and defense through counsel it selects. Its reasonable costs of doing so are covered by Section 19.2, and it will not agree to a settlement payable by the indemnifying party without that party's consent, which may not be unreasonably withheld. The indemnifying party may not settle a claim without the indemnified party's consent unless the settlement provides the indemnified party a complete and unconditional release, requires no payment or admission by the indemnified party, imposes no ongoing or nonmonetary obligation on it, and does not impair its rights. AgentShelf's obligations under this section remain subject to Section 20. **19.4 Exclusive IP remedy.** Section 19.1 states Customer's sole and exclusive remedy, and AgentShelf's entire liability, for a third-party claim alleging that the Services infringe, misappropriate, or otherwise violate intellectual-property rights. This section does not expand the rights covered by Section 19.1 or the liability limitations in Section 20. #### 20. Limitation of liability TO THE MAXIMUM EXTENT PERMITTED BY LAW, NEITHER PARTY WILL BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, REVENUE, GOODWILL, OR BUSINESS OPPORTUNITY, ARISING FROM THE AGREEMENT, EVEN IF ADVISED OF THEIR POSSIBILITY. TO THE MAXIMUM EXTENT PERMITTED BY LAW, AGENTSHELF'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THE AGREEMENT WILL NOT EXCEED THE AMOUNTS CUSTOMER ACTUALLY PAID TO AGENTSHELF FOR THE AFFECTED SERVICES DURING THE 12 MONTHS IMMEDIATELY BEFORE THE EVENT GIVING RISE TO THE FIRST CLAIM. THIS CAP APPLIES IN THE AGGREGATE ACROSS ALL CLAIMS AND THEORIES OF LIABILITY, INCLUDING AGENTSHELF'S INDEMNITY, CONFIDENTIALITY, PRIVACY, SECURITY, AND SUBCONTRACTED PERFORMANCE OBLIGATIONS. IT DOES NOT LIMIT LIABILITY THAT CANNOT LAWFULLY BE LIMITED. Customer's payment and indemnity obligations and Customer's liability for fraud or willful misconduct are not limited by this section. #### 21. Governing law and disputes The Agreement is governed by Delaware law, excluding conflict-of-law rules. The state and federal courts located in Delaware have exclusive jurisdiction over any dispute arising from the Agreement, except arbitration separately agreed as provided below, and each party consents to personal jurisdiction and venue there. Either party may seek temporary or injunctive relief in any court with jurisdiction to protect confidential information, security, or intellectual-property rights. Before litigation or agreed arbitration, a party will give written notice describing the dispute and requested resolution. For 30 calendar days after receipt, representatives authorized to settle will attempt good-faith resolution, including a telephone or video meeting if either party requests one. They may adjust the period by mutual written agreement; refusal to participate does not extend it. Undisputed payments, breach-cure periods and suspension/termination rights remain unchanged. Urgent temporary or injunctive relief and filings reasonably necessary to preserve a claim before an applicable filing deadline need not wait; negotiation efforts continue, and the negotiation period does not extend a filing deadline. Arbitration applies only if authorized representatives of both parties separately sign a writing expressly modifying this Section 21 for the identified Order, engagement or dispute and specifying the covered matters, administrator/rules, location, arbitrator count and cost allocation. Neither party may require arbitration unilaterally. Other Agreement terms, including Section 20's liability limits, remain unchanged unless expressly amended. TO THE MAXIMUM EXTENT PERMITTED BY LAW, EACH PARTY KNOWINGLY AND IRREVOCABLY WAIVES A TRIAL BY JURY IN ANY ACTION ARISING OUT OF OR RELATING TO THE AGREEMENT. #### 22. Changes The dated Terms and incorporated schedules and policies accepted by Customer apply initially. AgentShelf may update them prospectively by publishing revised text with a new effective date. **Notice of updates.** - Material updates require at least 30 calendar days' advance notice by email to Customer's account administrator or through the Services. - Nonmaterial updates may take effect on their published effective date. - Changes required by law or to address a security or abuse risk may take effect sooner. **Limits on updates.** An update does not amend a signed Enterprise MSA or Order, including any update terms they state, or retroactively change accrued rights or obligations. Subscription fee changes are governed by Section 5.1. Except to the extent required by mandatory law, material changes to payment authorization or permitted use of Customer Content or Outputs require affirmative acceptance by Customer's authorized representative, recorded in writing or through an express electronic acceptance. Posting, notice, silence, or continued use alone does not constitute the required affirmative acceptance. **Acceptance.** Existing commitments and amounts already due remain payable. Renewing or continuing to use the Services after an update takes effect constitutes acceptance of it, except where affirmative acceptance is required above. **Enterprise MSA.** If Customer has an executed Enterprise MSA, its [Legal Center](/legal) update, notice, acceptance, and contract-priority provisions control. **Archive.** AgentShelf will maintain a publicly accessible dated archive of superseded Terms, schedules, and policies. #### 23. General terms Neither party may assign the Agreement without the other's consent, except to an affiliate or in connection with a merger, reorganization, or sale of substantially all relevant assets, provided the assignee assumes the Agreement. Customer may not assign to a direct competitor of AgentShelf without consent. Neither party is liable for delay caused by events beyond its reasonable control, except payment obligations. The parties are independent contractors. The Agreement does not create a partnership, agency, fiduciary relationship, or third-party beneficiary. AgentShelf may enforce Section 19.2 on behalf of the other persons that section protects. Failure to enforce a provision is not a waiver. If a provision is unenforceable, it will be modified to the minimum extent necessary and the remainder will continue. Notices may be delivered electronically except where an Order requires another method. An amendment to a signed Order or Enterprise MSA requires the amendment process stated in that document. The Agreement is the complete agreement between the parties on its subject matter and supersedes prior proposals, communications, and agreements on that subject matter, except a document the Agreement expressly incorporates or an executed Enterprise MSA. Purchase-order or invoice boilerplate does not amend the Agreement. Electronic acceptance and electronic signatures may establish agreement to the extent permitted by law. Customer represents that neither it nor any person it permits to use the Services is subject to sanctions or export restrictions that make that use unlawful. Customer must not use, export, or make the Services available in violation of applicable sanctions or export-control laws. AgentShelf may restrict access as needed to comply with those laws or with provider restrictions. #### 24. Contact Agentshelf Inc 740 Nordahl Road, Suite 110, Unit 297 San Marcos, CA 92069, United States Legal matters: legal@agentshelf.ai Product support: support@agentshelf.ai --- ## Cookie and Similar Technologies Notice - Route: https://agentshelf.ai/legal/cookie-policy - SEO Title: Cookie and Similar Technologies Notice | AgentShelf - SEO Description: Understand how AgentShelf uses cookies and similar technologies. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/cookie-policy/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/cookie-policy/history ### Cookie and Similar Technologies Notice **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 Agentshelf Inc ("AgentShelf," "we," "us," or "our") uses cookies, browser storage, tags, and similar technologies on its websites, applications, public agents, and widgets. This Notice explains their purposes and the choices available to you. Our [Privacy Policy](/legal/privacy-policy) explains how we otherwise handle personal information. #### 1. What these technologies do Cookies and browser storage save information on your device. Tags and similar tools can collect information about page visits and interactions or send it to us and third-party providers. The technologies used depend on the website, application, enabled features, and customer configuration. They serve these purposes: - **Requested features and security:** signing in, maintaining a conversation or session, remembering settings, and preventing fraud and abuse. Blocking this storage may prevent a requested feature from working. - **Assistant personalization:** recognizing a returning browser, linking visits, retaining context across pages, and supporting proactive assistance. This may use a persistent visitor identifier and engagement history. - **Analytics and diagnostics:** understanding page visits, feature use, performance, errors, and interactions. Enabled session-replay tools may record interactions with a website. Operational and diagnostic information may contain Customer Content; the Privacy Policy explains the limits on its use. - **Advertising and referral measurement:** connecting a visit or conversion to a campaign, advertisement, or referral and measuring campaign results. Advertising providers may combine information about activity across different businesses' websites or services. Collected information may include IP addresses, browser and device information, identifiers, page and referring addresses, campaign details, timestamps, and interactions. #### 2. When tracking starts and how long storage lasts On our public website, agentshelf.ai, optional technologies for assistant personalization, analytics, and advertising stay off until you allow them in Cookie Settings. Cookie Settings applies to this website only. Our applications and widgets operated by our customers use these technologies according to their own settings, and a choice made on one surface may not apply to another. Some storage supports a current session. Other storage persists across visits until it is removed or expires under the applicable settings. Information already sent to us or another provider is separate from the storage on your device. Retention of that information is addressed in the Privacy Policy and applicable provider notices. #### 3. Public agents and widgets Public agents and widgets may use page context, such as the page address, title, language, and site area, to support an interaction, along with the personalization and referral-measurement technologies described in Section 1. Conversation content, contact details, and recordings are addressed in the Privacy Policy and the responsible customer's notice. A customer embedding an AgentShelf widget may operate its own technologies and configure AgentShelf features. Review that customer's privacy and cookie notices for its practices and available choices. #### 4. Your choices and privacy rights On our public website, you can change your choices at any time through the Cookie Settings link in the footer. You can also use browser settings to block or delete cookies and browser storage, and use privacy controls offered on any other website you are visiting. Blocking storage may affect requested features, and removing it does not delete information already collected by us or third parties. You may have rights under applicable law to opt out of sale, sharing, or targeted advertising, or to withdraw consent, as described in the Privacy Policy. Send privacy requests or questions to legal@agentshelf.ai. On our public website, we treat a Global Privacy Control signal as an opt-out of sale, sharing, and targeted advertising. Advertising technologies stay disabled while the signal is active, and you do not need to contact us for it to take effect. To make an opt-out request for another AgentShelf surface, contact legal@agentshelf.ai or use the controls offered by the customer operating the widget. Nothing in this Notice limits your rights under applicable law. #### 5. Third-party content Embedded media, integrations, marketplace materials, and other third-party content may connect your browser to another provider. That provider may receive your IP address, browser information, and interactions and may use its own technologies. Its privacy notice and controls apply to its practices. #### 6. Changes and contact We may update this Notice when our practices or Services change. We will post the revised Notice with its effective date and last-updated date and provide further notice or obtain consent when required by law. A contractual notice or amendment process does not replace legally required cookie consent, privacy rights or cookie controls. For questions or privacy requests, contact legal@agentshelf.ai. --- ## Acceptable Use Policy - Route: https://agentshelf.ai/legal/acceptable-use-policy - SEO Title: Acceptable Use Policy | AgentShelf - SEO Description: Review the rules for safe and lawful use of AgentShelf agents, tools, and services. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/acceptable-use-policy/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/acceptable-use-policy/history ### Acceptable Use Policy **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 This Acceptable Use Policy ("AUP") governs use of AgentShelf's Services and is incorporated into the applicable agreement with Agentshelf Inc ("AgentShelf"). Capitalized terms not defined here have the meanings in that agreement. Customer is responsible for its Authorized Users, Customer Agents, public agents and widgets, connected tools, Marketplace Content, and uses made under Customer-controlled credentials. #### 1. Illegal activity and harm You may not use the Services to: - violate applicable law or assist another person in doing so; - facilitate violence, terrorism, human trafficking, exploitation, or credible threats of physical harm; - create, solicit, store, or distribute child sexual abuse material or content that sexually exploits minors; - stalk, harass, intimidate, discriminate unlawfully, or invade another person's privacy; - facilitate the unlawful sale or procurement of controlled substances, weapons, or other regulated goods; or - generate or distribute content that you know is materially fraudulent, defamatory, or unlawfully deceptive. You may not configure or market the Services for minors or students under 18. #### 2. Security and platform abuse You may not: - introduce malware, destructive code, or malicious payloads, or conduct phishing or credential theft; - probe, scan, or test systems without authorization; - bypass authentication, permissions, rate limits, safety controls, usage limits, approval requirements, or provider restrictions; - access accounts, data, models, tools, or systems without authorization; - interfere with the integrity, availability, or performance of the Services; - use the Services to coordinate denial-of-service activity, botnets, or malicious exploitation; - reverse engineer or extract nonpublic source code, models, system prompts, or security mechanisms except where applicable law prohibits this restriction; or - use automated means to create accounts, scrape restricted interfaces, or avoid applicable fees or metering. Good-faith security research conducted under an AgentShelf vulnerability disclosure or written authorization is not prohibited. #### 3. Personal data and surveillance You may not collect, infer, monitor, or process personal information without the rights, notices, consents, and lawful basis required for your use. You may not: - conduct unlawful biometric identification, location tracking, interception, recording, or surveillance; - infer highly sensitive traits for discriminatory, exploitative, or unlawful purposes; - expose credentials, financial-account data, government identifiers, medical records, or other sensitive information without authorization and appropriate safeguards; or - attempt to reidentify data represented as de-identified, except for authorized testing of de-identification safeguards. #### 4. High-impact and regulated decisions Unless AgentShelf expressly approves the use in a separate written agreement, you may not use the Services to make final or solely automated decisions that determine a person's eligibility, selection, access, or terms for: - employment or worker management; - housing or lodging; - credit, lending, insurance, or financial services; - education admissions or material educational opportunities; - healthcare diagnosis, treatment, or emergency triage; - legal services or a person's legal rights; - government benefits or essential services; or - criminal justice, law enforcement, immigration, or similar coercive action. The Services may assist qualified professionals in these areas, but Outputs do not replace professional judgment, and appropriate human review, testing, documentation, explanation, appeal, and nondiscrimination controls remain required. AgentShelf may approve a specific high-impact use only through a written agreement that identifies the use and its required monitoring, recordkeeping, and other safeguards, which Customer must implement. Approval covers only the identified use and those safeguards. It does not waive the human-review requirements of the AI and Product Schedule or the Agreement's emergency-use restrictions, and it does not authorize conduct prohibited by law or by the terms of an enabled provider. #### 5. Deception, impersonation, and synthetic media You may not use the Services to impersonate a person or organization without authorization, manufacture false evidence, or create materially misleading synthetic media for fraud, harassment, election interference, or other unlawful harm. Public agents and automated communications must not be presented as human where that would be deceptive and must provide AI or automation disclosures when required by law or applicable provider terms or reasonably necessary to avoid deception. #### 6. Communications You may not use voice, telephone, SMS, email, or messaging features for spam, unlawful telemarketing, spoofing, harassment, or communications made without required consent. You must: - use valid sender identity and registration; - maintain required consent records; - provide required disclosures; - honor opt-out and revocation requests promptly; - comply with calling-hour, do-not-call, recording, transcription, and campaign rules; and - avoid emergency calling or representing that the Services provide emergency communications. The [Voice and Messaging Schedule](/legal/voice-and-messaging-schedule) sets out detailed requirements for voice and SMS features. #### 7. Intellectual property and Marketplace Content You may not upload, publish, distribute, or instruct an agent to use material that infringes intellectual-property, privacy, publicity, contractual, or other rights. You may not falsely claim ownership, manipulate marketplace reviews or rankings, distribute malicious or undisclosed behavior, or conceal material dependencies, permissions, or fees. Publishers must also comply with the [Marketplace and Publisher Terms](/legal/marketplace-and-publisher-terms). #### 8. Model and provider restrictions You must comply with restrictions applicable to enabled model providers and third-party services. You may not use the Services to circumvent a provider's access controls, geographic limitations, model safeguards, or usage policies. #### 9. Credentials, tools, and external actions You must grant only the access needed and limit agents to appropriate tools and actions. You may not provide credentials you lack authority to use. The [AI and Product Schedule](/legal/ai-and-product-schedule) sets out the approval and other safeguards required for consequential actions. #### 10. Enforcement AgentShelf may investigate suspected violations and may limit, block, suspend, or remove affected content, agents, tools, integrations, or access, with or without notice. Suspension of account access is governed by the Agreement's suspension terms. AgentShelf may act immediately where necessary to prevent harm, protect the Services or third parties, comply with law, or respond to a provider. AgentShelf may preserve and disclose information as required by law. Enforcement does not obligate AgentShelf to monitor all content or activity. Report abuse, policy concerns, or security vulnerabilities to legal@agentshelf.ai. General product-support requests should be sent to support@agentshelf.ai. #### 11. Changes Updates to this Policy follow Section 22 of the [Platform Terms of Service](/legal/terms-and-conditions) or, if Customer has an executed Enterprise MSA, that agreement. --- ## AI and Product Schedule - Route: https://agentshelf.ai/legal/ai-and-product-schedule - SEO Title: AI and Product Schedule | AgentShelf - SEO Description: Understand AgentShelf AI models, provider relationships, data use, and agent responsibilities. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/ai-and-product-schedule/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/ai-and-product-schedule/history ### AI and Product Schedule **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 This AI and Product Schedule (the "Schedule") forms part of the agreement between Agentshelf Inc ("AgentShelf") and Customer governing the Services. It applies to AI models, agents, Outputs, tools, integrations, public deployments, and related features. Capitalized terms not defined here have the meanings in the [Platform Terms of Service](/legal/terms-and-conditions) or applicable enterprise agreement. The business customer, U.S. customer eligibility, and adult-user requirements in that agreement also apply to this Schedule. #### 1. Definitions **AI Provider** means a third party that supplies an AI model, speech, transcription, or other AI service used through the Services. **Contributor Model** means a model expressly offered and labeled by AgentShelf under special terms that allow the AI Provider to use submitted inputs, Outputs, feedback, or related information to train, evaluate, or improve that provider's models or services, or that AgentShelf otherwise designates as subject to special data terms. **Customer Agent** means an agent, assistant, workflow, or automation configured, deployed, or controlled by Customer through the Services. **Tool** has the meaning in the Platform Terms of Service or applicable enterprise agreement. It includes a connected service or capability that an agent can use to read information or take action, such as a business application, browser, file service, code executor, or communications service. #### 2. Model access and provider relationships Available models depend on the feature, plan, configuration, location, account status, and provider availability. The Services may offer access through an AgentShelf-managed provider account, a provider account connected by Customer or an Authorized User, or an endpoint arranged for a particular deployment. Connecting a provider account does not make every model or feature available. Customer's administrators choose which available models their Authorized Users may use and whether newly added models are enabled automatically. Enabling a model, including through an automatic-enablement setting, instructs AgentShelf to send the Customer Content needed for a request to that model's AI Provider. An AI Provider receives Customer Content needed to perform the applicable request. Its retention, human review, abuse monitoring, processing locations, and training practices depend on the particular service, account, agreement, and settings, and a provider's general consumer-service terms do not necessarily describe the service used through AgentShelf. Before use, Customer is responsible for reviewing the applicable provider terms, disclosures, and model settings and for determining that they are appropriate for the information it intends to submit. When Customer supplies or controls a provider account, Customer is responsible for its credentials, permissions, provider agreement, account settings, and provider charges. AgentShelf may add, remove, suspend, replace, or modify supported models when reasonably necessary for safety, compliance, provider availability, end of life, performance, or product development. AgentShelf will give notice of a material model removal when reasonably practicable and as required by an Order. #### 3. Customer Content and data use AgentShelf's commitment not to use Customer Content or Outputs to train machine-learning models, or to use their substance for general product improvement, is stated in Section 7 of the Platform Terms and applies under this Schedule, including to copies or excerpts in operational and diagnostic records. In providing AI features, AgentShelf may process and store Customer Content, including conversations, files, recordings, transcripts, tool inputs and results, and Outputs, for model responses, agent execution, Tools, integrations, evaluations, security, support, troubleshooting, and legal compliance, in each case only for the purposes permitted by Section 6 of the Platform Terms. The [Privacy Policy](/legal/privacy-policy) and applicable DPA explain personal-information handling. That commitment concerns AgentShelf's use and does not replace an AI Provider's applicable terms. Provider processing is described in Section 2, with the special conditions for Contributor Models in Section 4. #### 4. Contributor Models Contributor Models are available only where AgentShelf expressly offers them under disclosed special data-use terms. A Contributor Model may be used only after an organization administrator, having reviewed the Contributor label and applicable disclosure, affirmatively enables it on Customer's behalf. An ordinary model selection or a connected provider account does not substitute for that authorization. The disclosure must identify the provider's permitted use of submitted inputs, Outputs, feedback, or related information for provider model or service improvement and any processing outside the United States. By enabling a Contributor Model, Customer accepts the disclosed provider practices for the content it submits. Customer must not submit to a Contributor Model any category of information the provider's terms prohibit. Subject to that restriction, Customer must not submit confidential, sensitive, regulated, personal, or proprietary information unless Customer has determined that the disclosed provider practices are appropriate and has all required rights and notices. Neither administrator authorization nor AgentShelf's approval overrides a provider prohibition. Contributor treatment depends on the particular offering, not the provider's name. AgentShelf may suspend a Contributor offering if its provider terms change until the applicable disclosure has been reviewed and updated. Contributor authorization does not authorize AgentShelf to use Customer Content for its own model training or general product improvement. #### 5. Model selection and available alternatives Model settings may apply to an individual request, a Customer Agent, an organization, or a particular feature. When no model has been selected or a configured default is unavailable, the Services may select another available default. For Customer Agents and other features that use Customer's model settings, a default or replacement is selected only from the models Customer's administrators have enabled, and Section 4 continues to apply to Contributor Models. Some native platform features, such as the AI Agent Builder Guide, use a model AgentShelf selects, which may be one Customer's administrators have not enabled. AgentShelf runs those features only on models covered by a zero-data-retention arrangement with the AI Provider. Different models or features may involve different AI Providers. If Customer requires a particular provider, processing location, or other restriction, Customer must confirm that the feature supports that requirement before use and record any agreed restriction in an Order. Model availability alone does not establish suitability for Customer's confidentiality or regulatory requirements. #### 6. Outputs and human review AI-generated Outputs may be inaccurate, incomplete, inconsistent, biased, offensive, or unsuitable and may not be unique. AgentShelf does not represent that Output is factually correct, non-infringing, or suitable for Customer's intended use. Customer is responsible for evaluating Outputs, verifying citations, code, calculations, actions, and material statements, and applying appropriate human review, testing, and professional judgment. Customer must not rely on Output as the sole basis for a decision concerning a person's employment, housing, credit, insurance, education, healthcare, legal rights, government benefits, another area listed in Section 4 of the Acceptable Use Policy, or similar material opportunity. Professional uses require review by a properly qualified person. #### 7. Customer Agents and instructions Customer is responsible for a Customer Agent's purpose, instructions, knowledge, enabled models, Tools, permissions, approval settings, public presentation, and deployment. Customer will test Customer Agents before production use and monitor them proportionate to risk. Customer must not instruct a Customer Agent to violate law, the Agreement, third-party rights, or applicable provider terms. Customer must disclose AI interaction where required by law or applicable provider terms or reasonably necessary to prevent deception and must not deceptively present a Customer Agent as human. #### 8. Tools and external actions A Customer Agent may read from or act in connected systems using permissions Customer grants. Customer is responsible for confirming that credentials and data may lawfully be used, granting only the access needed for the intended purpose, reviewing outcomes, and revoking access when no longer needed. Content a Customer Agent retrieves from websites, files, messages, or connected services may contain instructions. Those instructions do not expand the authority Customer has granted. Customer is responsible for actions a Customer Agent takes using the permissions Customer grants. Customer must require human approval, or apply safeguards appropriate to the action, for consequential actions. These include transferring money or value, entering or changing agreements, deleting data, changing access, publishing content, sending external communications outside the scope, audience, and content rules Customer has configured and approved in advance, modifying authoritative records, or taking action affecting a person's safety, health, rights, or opportunities. Customer must configure and oversee its workflows to meet this obligation; model selection alone is not an authorization control. Approval and other control features vary by plan, feature, and configuration. Customer is responsible for determining whether the available controls are sufficient for its use. AgentShelf may block or require approval for an action based on risk, policy, Customer configuration, or provider restrictions. #### 9. Public agents and widgets Customer is responsible for the visitor experience, notices, branding, content, lawful basis, consent, and instructions associated with its public agents and widgets. Customer must not configure a public agent to collect information unnecessary for its disclosed purpose or represent that an agent can provide emergency assistance. Customer must provide an accessible way to contact a person when appropriate to the use case. #### 10. Voice, telephone, and messaging Voice and messaging features may process telephone numbers, audio, transcriptions, synthesized speech, recordings, message content, and carrier records. The [Voice and Messaging Schedule](/legal/voice-and-messaging-schedule) governs these features, including Customer's responsibilities for consent, recording and transcription notices, sender identification and registration, opt-outs, calling hours, and campaign requirements. The Services are not an emergency service and must not be used to place or receive emergency calls. #### 11. Evaluation, monitoring, and support Customer may use supported evaluation, testing, and monitoring features to assess agent quality, safety, cost, and reliability. Customer is responsible for ensuring that its evaluation materials and reviewer access are lawful and appropriately protected. Evaluating Customer's agents at Customer's request does not authorize use of those materials for AgentShelf's general improvement or training purposes. AgentShelf may use Usage Data, synthetic test data, and AgentShelf-owned evaluation materials to improve the Services. For help with supported models, configuration, or unexpected behavior, contact support@agentshelf.ai. Support availability and any agreed service levels are governed by the applicable Order or service terms. Customer is responsible for suspending a workflow or revoking connected access when necessary to prevent unintended actions while an issue is being addressed. #### 12. Suspension of models or capabilities AgentShelf may suspend a model, Tool, agent, or capability, with or without notice, when reasonably necessary to address a security issue, provider restriction, legal requirement, material policy violation, unexpected harmful behavior, or service integrity. #### 13. Priority and changes Section 1 of the Platform Terms of Service or, if Customer has an executed Enterprise MSA, that agreement sets this Schedule's priority among the documents forming the Agreement. Updates to this Schedule follow Section 22 of the Platform Terms or that Enterprise MSA. Changes to model or provider availability or pricing do not themselves amend agreed processing restrictions, authorize Contributor Model use, or authorize a new use of Customer Content or Outputs. --- ## Supplemental Credit Terms - Route: https://agentshelf.ai/legal/supplemental-credit-terms - SEO Title: Supplemental Credit Terms | AgentShelf - SEO Description: Read the terms for AgentShelf usage credits, expiration, refunds, and automatic recharge. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/supplemental-credit-terms/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/supplemental-credit-terms/history ### Supplemental Credit Terms **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 These Supplemental Credit Terms ("Credit Terms") form part of the agreement between Agentshelf Inc ("AgentShelf") and the business or organization that purchases, receives, or uses Credits ("Customer") governing the Services (the "Agreement"). Capitalized terms not defined here have the meanings in the [Platform Terms of Service](/legal/terms-and-conditions) or applicable enterprise agreement, which also set the priority among the documents forming the Agreement. #### 1. Types of Credits ##### 1.1 Usage Credits "Usage Credits" are prepaid units Customer purchases to pay for eligible metered use of the Services. A request to purchase Usage Credits is an offer by Customer. AgentShelf accepts the offer when it confirms the purchase or posts the Usage Credits to Customer's account or organization. ##### 1.2 Promotional Credits "Promotional Credits" are credits AgentShelf provides without charge, including trial, promotional, support, service-recovery, migration, or discretionary credits. Promotional Credits may be subject to additional eligibility, product, plan, or use restrictions disclosed when issued. ##### 1.3 Included allowances Usage included in a subscription plan is a plan allowance, not a purchased Credit, unless the checkout page or Order expressly says otherwise. An unused plan allowance expires at the end of its billing period and does not roll over. Usage Credits, Promotional Credits, and any other credit AgentShelf designates as subject to these Credit Terms are collectively "Credits." #### 2. Use and deduction Credits may be used only for eligible Services associated with the Customer account or organization to which they are issued. AgentShelf deducts Credits according to the applicable model, provider, feature, communications, compute, storage, or other usage price in effect when the usage occurs. Credits pay for AgentShelf's Services. They do not purchase, and give Customer no account with or right of direct access to, any third-party provider's service. AgentShelf sets its usage prices, which may differ from a provider's own prices. Charges measure eligible resources consumed at the disclosed price, not a business outcome. A cancelled, failed, or incomplete request or workflow may incur charges for resources already consumed. Pricing and the number of Credits needed for future usage may change on advance notice where reasonably practicable. A price change does not reduce the numeric balance already posted, but may change how much future usage that balance can purchase. AgentShelf applies Credits according to its account and usage records. Displayed balances may not reflect all usage. Customer must notify support@agentshelf.ai of a suspected billing or Credit error within 60 days after the charge or deduction appears and provide information reasonably needed to investigate. Demonstrated errors will be corrected. #### 3. Expiration Purchased Usage Credits expire one year after the purchase date, unless an Order expressly states another period. The purchase date is the date AgentShelf accepts the purchase under Section 1.1. Promotional Credits expire on the date disclosed when issued. If AgentShelf does not disclose a date, they expire one year after issuance. AgentShelf may use a shorter promotional period when clearly disclosed before issuance. Credits automatically expire when the associated Customer account or organization is closed or terminated, without refund except as stated in Section 4. Suspension does not extend an expiration date. AgentShelf may provide expiration reminders as a convenience, but Customer is responsible for monitoring balances and expiration dates shown in the Services. #### 4. No refunds or cash value Credits are non-refundable except where required by law, where AgentShelf corrects a duplicate or erroneous charge, or where the Platform Terms or an Order expressly provide a refund, including the remedies for without-cause termination or an uncured express warranty breach. A contractual refund is calculated from the eligible amount actually paid for unused Usage Credits and does not include Promotional Credits. Expiration, account closure, termination for Customer breach, or a change in Customer usage does not otherwise create a refund right. Credits give Customer a limited contractual right to use eligible Services. They have no cash-redemption value, do not earn interest, are not a bank deposit, and may not be used outside the Services. #### 5. No transfer or resale; reversal Customer may not sell, assign, transfer, sublicense, pledge, or exchange Credits to or with another person, account, or organization. AgentShelf may permit an administrative transfer between Customer-controlled workspaces within the same organization, but is not required to do so. A permitted assignment of the Agreement does not move Credits to another account or organization; they remain with the account or organization to which they were issued. Credits obtained through fraud, mistake, unauthorized payment, chargeback, promotion abuse, or violation of the Agreement may be suspended, reversed, or canceled. A chargeback does not eliminate Customer's obligation for properly authorized usage. #### 6. Automatic recharge AgentShelf may offer an optional automatic-recharge feature. Before activation, Customer selects or confirms the balance threshold, recharge amount, payment method, and any available spending or frequency limit. By enabling automatic recharge, Customer authorizes AgentShelf and its payment processor to charge the selected payment method for the disclosed amount and applicable taxes each time the configured trigger occurs, until Customer disables the feature. Customer may disable future automatic recharges through the available account controls. Disabling recharge does not reverse a recharge already initiated or Credits already posted. Saving a payment method does not by itself activate automatic recharge. If a charge fails, AgentShelf may retry it as permitted by the payment authorization, decline to post Credits, stop eligible usage when the balance is exhausted, or suspend affected paid features after notice. #### 7. Usage controls and insufficient balance Unless Customer has affirmatively enabled automatic recharge or paid overages, eligible metered usage may pause when available allowances and Credits are exhausted. Usage controls and balances are not a guaranteed spending limit. Customer remains responsible for properly authorized usage incurred before the applicable stop takes effect, including usage that settles after a balance is displayed. #### 8. Account closure and termination Section 3 states when Credits expire on account closure or termination. Section 4 states the refund treatment. #### 9. Changes Updates to these Credit Terms follow Section 22 of the Platform Terms of Service or, if Customer has an executed Enterprise MSA, that agreement. A material change to expiration, refund, transfer or automatic-recharge treatment applies to new Credit purchases after the change unless mandatory law or Customer's affirmative acceptance permits another result. The dated Credit Terms accepted when Usage Credits are purchased govern their expiration and refund treatment. A change requiring affirmative acceptance under Section 22 of the Platform Terms cannot be applied merely because Customer purchases more Credits or continues using the Services. #### 10. Contact Questions about Credits or billing may be sent to support@agentshelf.ai. Legal notices or legal questions may be sent to legal@agentshelf.ai. --- ## Marketplace and Publisher Terms - Route: https://agentshelf.ai/legal/marketplace-and-publisher-terms - SEO Title: Marketplace and Publisher Terms | AgentShelf - SEO Description: Review the terms for publishing, licensing, and installing AgentShelf marketplace content. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/marketplace-and-publisher-terms/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/marketplace-and-publisher-terms/history ### Marketplace and Publisher Terms **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 These Marketplace and Publisher Terms (the "Marketplace Terms") form part of the agreement between Agentshelf Inc ("AgentShelf") and Customer. They apply to publishing, listing, distributing, installing, and using Marketplace Content. Capitalized terms not defined here have the meanings in the [Platform Terms of Service](/legal/terms-and-conditions). #### 1. Current marketplace The marketplace supports publishing and installation. AgentShelf does not currently process marketplace purchases or pay publisher proceeds; paid marketplace transactions would require separately disclosed commercial terms before a publisher or customer participates. Installing Marketplace Content does not make all resulting use free: applicable platform, model, communications, and customer-connected service charges still apply. #### 2. Publisher responsibilities A Customer publishing Marketplace Content ("Publisher") is responsible for its materials, listing, and any obligations it expressly undertakes to users. Publisher represents that it has the rights needed to publish the materials, include any third-party components, and grant the licenses described in these Marketplace Terms and its listing, and must not grant rights it does not hold. Listings must accurately describe the materials' purpose, capabilities, limitations, required permissions, third-party dependencies, applicable licenses (including third-party and open-source requirements), material use restrictions, and any separate charges. A listing must not imply that AgentShelf presently collects payments or makes payouts for it. Publisher must not conceal harmful behavior, unnecessary access, data collection, or restrictions that materially affect use. Publisher may not include confidential or personal information without the rights and permissions needed to make it available as described. Publisher must comply with the [Acceptable Use Policy](/legal/acceptable-use-policy), keep its contact details current, and promptly correct or remove materials that are or become unlawful, unsafe, misleading, infringing, or incompatible. Publisher must promptly notify AgentShelf of a suspected security compromise of its materials or a material change in the permissions they require or in how they use data. Publisher must protect any credentials it handles and use information obtained through its materials only for the disclosed purpose. Publication does not promise a particular ranking, promotion, number of installations, or continued listing. #### 3. Ownership and permission to operate the marketplace Publisher retains ownership of its Marketplace Content, subject to others' rights. By submitting materials for publication, Publisher grants AgentShelf a non-exclusive, worldwide, royalty-free license to host, reproduce, display, distribute, format, test, and secure those materials as needed to operate and promote the listing and provide permitted installations. This license does not authorize AgentShelf to use Customer Content or Outputs for model training or general product improvement. Private information not submitted for publication remains subject to the Agreement's confidentiality and data-use terms. #### 4. Installation and use rights Installing Marketplace Content does not transfer ownership. Its disclosed license governs permitted use. If no separate license is identified, Publisher permits Customer to install, configure, and use the materials through the Services for Customer's business purposes, including deployments otherwise permitted by the Agreement. This permission does not authorize resale or redistribution of the materials as a standalone product or removal of required ownership or license notices. Customer must review the listing, licenses, permissions, and connected-service terms before use, test materials for its intended purpose, and supervise any resulting agent actions. AgentShelf's review or listing is not an endorsement or assurance of accuracy, safety, legal suitability, or compatibility. #### 5. Third-party services and support Marketplace Content may require separately enabled models, integrations, or other services. Their own terms, data practices, and availability apply, and Customer is responsible for the permissions and accounts it connects. Any Publisher support or warranty must be expressly identified in the listing or a separate agreement. AgentShelf does not assume a Publisher's obligations merely by hosting its materials. #### 6. Review, removal, and withdrawal AgentShelf may review, rank, moderate, reject, restrict, suspend, or remove materials or listings for rights complaints, security, legal compliance, policy violations, quality, compatibility, or operational reasons. AgentShelf is not obligated to review every submission or continuously monitor every installation. Publisher may request withdrawal of a listing through the available controls or support@agentshelf.ai. Withdrawal stops future distribution as reasonably practicable but does not automatically revoke licenses already granted or remove copies already installed. Existing licenses, legal obligations, and necessary operational records may survive withdrawal. If Publisher's account is closed or terminated, its listings are withdrawn on the same terms, and AgentShelf may retain the published materials as needed for those purposes despite the deletion terms in Section 17 of the Platform Terms. AgentShelf may restrict continued use when necessary to address harm, law, or a rights complaint. #### 7. Rights complaints Send copyright or other rights complaints to legal@agentshelf.ai, identifying the disputed material, its location, the rights involved, and reliable contact information. AgentShelf may request additional information, notify the Publisher, restrict access, or remove the material. Publisher must cooperate with reasonable requests concerning rights, safety, or compliance. Customers may not submit knowingly false complaints. AgentShelf may restrict or terminate accounts that repeatedly infringe others' rights, subject to the Agreement and applicable law. These provisions do not limit any formal rights or procedures required by law. #### 8. Other agreement terms The Agreement's confidentiality, data-use, indemnity, warranty, liability, dispute, and acceptable-use terms apply. Section 1 of the Platform Terms of Service or, if Customer has an executed Enterprise MSA, that agreement sets these Marketplace Terms' priority among the documents forming the Agreement. Updates to these Marketplace Terms follow Section 22 of the Platform Terms or that Enterprise MSA. For product support, contact support@agentshelf.ai. For legal, privacy, abuse, security, or rights matters, contact legal@agentshelf.ai. --- ## Voice and Messaging Schedule - Route: https://agentshelf.ai/legal/voice-and-messaging-schedule - SEO Title: Voice and Messaging Schedule | AgentShelf - SEO Description: Review responsibilities for AgentShelf calls, SMS, recording, transcription, and consent. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/voice-and-messaging-schedule/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/voice-and-messaging-schedule/history ### Voice and Messaging Schedule **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 This Voice and Messaging Schedule (the "Schedule") forms part of the agreement between Agentshelf Inc ("AgentShelf") and Customer governing the Services (the "Agreement"). It applies to voice agents, telephone calls, SMS, and related recording, transcription, and messaging features, including communications initiated through Customer's agents, workflows, or connected services. Capitalized terms not defined here have the meanings in the Agreement. #### 1. Audience and available features Customer may not direct these features at minors or configure an agent to solicit personal information from minors. Available features depend on Customer's plan, configuration, connected services, and carrier or provider requirements. Before launching a campaign, accepting calls, or enabling recording or transcription, Customer must confirm that the features, controls, and retention options available in its configuration support its intended use and arrange any additional controls needed for lawful use. Customer must obtain AgentShelf's written agreement before relying on a control or service commitment that is not included in the Agreement or described as available for its configuration. #### 2. Shared responsibilities Customer determines the purpose, audience, contact lists, instructions, content, frequency, and timing of its communications. Customer is responsible for the notices, permissions, consent, and records required for those choices and for complying with requirements applicable to its business and audience. Customer must use the available configuration and permission controls, supervise its agents, and keep an appropriate way for recipients to contact a person. Customer must follow applicable industry, carrier, and provider requirements and must not bypass platform, carrier, or provider restrictions. #### 3. Consent, contact lists, and sender identity Before initiating a call or message, Customer must establish that the contact is lawful for the intended purpose and method. This includes obtaining any required consent and keeping evidence of when, how, and for what purpose that consent was obtained. Possession of a telephone number or a business contact list does not by itself establish permission to contact everyone on it. Customer must accurately identify the business responsible for the communication, use telephone numbers and sender identities it is authorized to use, and complete applicable sender, number, and campaign registration. Customer may not use misleading caller identification, spoofing, unlawfully obtained contact lists, or another person's identity without authorization. #### 4. Opt-outs, calling hours, and campaign management Customer must provide required opt-out methods and honor STOP and comparable requests, do-not-call requests, and consent withdrawals within the time required for its use. Customer must keep its contact and suppression records current and apply them to its agents, campaigns, and connected services before further communications are sent. Customer must comply with applicable calling hours, quiet hours, recipient time zones, campaign limits, and message-frequency requirements, and must pause affected communications when it cannot reliably honor a recipient's request or meet these requirements. #### 5. AI disclosure and voice use Customer must disclose AI or automated interaction where required by law or applicable provider terms or needed to prevent deception. Customer must not falsely present an automated agent as a human or use a synthesized or imitated voice without the rights and permissions required for that use. AI responses and transcripts may contain errors. Customer must test its agents and provide human review appropriate to the consequences of a communication, including statements about prices, contracts, eligibility, or a person's rights. Customer must not configure an agent to make commitments beyond the authority Customer has granted it. #### 6. Recording and transcription Customer controls whether call recording is enabled, using the recording options available for its configuration. Customer is responsible for making sure its configured greeting contains the required recording disclosure and for any confirmation it gives about that disclosure. Customer must ensure that legally sufficient notice and any required consent are obtained before initiating recording or transcription, taking into account the locations of the participants and the requirements applicable to the call. Enabling recording and confirming a greeting do not establish that notice was delivered or consent was obtained. Customer must not use recording or transcription when the available options and Customer's own procedures cannot satisfy those requirements. Customer must limit access to recordings and transcripts, avoid collecting unnecessary sensitive information, and use available deletion options when information is no longer needed. Retention is governed by the Agreement, the [Privacy Policy](/legal/privacy-policy), and supported configuration options. #### 7. Carriers, providers, and connected services Calls and messages may depend on telecommunications carriers, speech or AI providers, and connected services. Their coverage, registration, filtering, usage limits, outages, and policies may affect availability, delivery, and quality. Delivery and recipient response are not guaranteed. Customer is responsible for permissions and settings in services it connects or controls. Applicable charges are described in the Agreement and, for Customer's separately contracted services, the relevant provider agreement. #### 8. Emergency and restricted uses The Services are not an emergency service. Customer must not use them to place or receive emergency calls, provide emergency dispatch or triage, or represent that an agent can provide emergency assistance. Customer must direct people who need emergency assistance to the appropriate emergency service. Customer must not use these features for unlawful telemarketing, spam, harassment, fraud, unlawful surveillance, or unauthorized impersonation. Section 4 of the [Acceptable Use Policy](/legal/acceptable-use-policy) governs high-impact and regulated decisions made using these features, including when AgentShelf's written approval is required and the safeguards that apply. AI communications must not be the sole basis for a decision affecting a person's material rights or opportunities. #### 9. Privacy, restrictions, and assistance Customer must provide appropriate privacy notices and obtain the rights needed to process and share communication content, recordings, transcripts, and recipient information. The Privacy Policy and any applicable DPA govern AgentShelf's handling of personal information. AgentShelf may restrict, suspend, or disable affected communications, with or without notice, when reasonably necessary to address abuse, protect people or the Services, comply with law, or meet carrier or provider requirements. For product or configuration assistance, contact support@agentshelf.ai. For legal, privacy, abuse, or security matters, contact legal@agentshelf.ai. #### 10. Relationship to other terms This Schedule supplements the [Platform Terms](/legal/terms-and-conditions), [AI and Product Schedule](/legal/ai-and-product-schedule), and Acceptable Use Policy. Section 1 of the Platform Terms of Service or, if Customer has an executed Enterprise MSA, that agreement sets this Schedule's priority among the documents forming the Agreement. Updates to this Schedule follow Section 22 of the Platform Terms or that Enterprise MSA. --- ## Professional Services Terms - Route: https://agentshelf.ai/legal/professional-services-terms - SEO Title: Professional Services Terms | AgentShelf - SEO Description: Read the terms for AgentShelf implementation, development, consulting, and managed services. - Currently effective text: October 1, 2026 - Dated text: https://agentshelf.ai/legal/professional-services-terms/effective/2026-10-01 - Previous effective dates: https://agentshelf.ai/legal/professional-services-terms/history ### Professional Services Terms **Effective Date:** October 1, 2026 **Last Updated:** October 1, 2026 These Professional Services Terms (these "Services Terms") govern implementation, configuration, integration, migration, development, website builds, training, consulting and expressly ordered hosting or managed services (collectively, "Professional Services") supplied by Agentshelf Inc ("AgentShelf") to a business or organization ("Customer"). They apply only when expressly incorporated into an accepted Order or SOW for those services (an "Engagement"). They do not themselves purchase a service or authorize a charge. #### 1. Application and contract priority These Services Terms supplement the [Platform Terms of Service](/legal/terms-and-conditions) and their applicable incorporated documents, or an executed Enterprise MSA that expressly incorporates these Services Terms (the "Agreement"). Capitalized terms not defined here have their meanings in the Agreement. For Professional Services, an Order must be an order form or statement of work ("SOW") that identifies the Engagement, incorporates these Services Terms, and is signed by authorized representatives of both parties, including by electronic signature. Customer accepts these Services Terms by signing that Order. Publication, access to the Legal Center, Platform signup, checkout or continued use alone does not constitute that acceptance. The Agreement's contract-priority rules control. Subject to those rules, an Order's express engagement-specific scope, commercial terms, deliverable rights, acceptance, warranty and termination provisions control over inconsistent defaults here, and these Services Terms control their professional-services subject matter over inconsistent general Platform Terms. An executed DPA controls its personal-data processing subject matter. An executed Enterprise MSA controls priority and amendments where applicable. These Services Terms do not create a separate indemnity, liability cap or dispute regime, expand payment authorization, or alter Customer Content or Output rights. Those matters change only through the Agreement's applicable express amendment and acceptance requirements. #### 2. Orders and scope Each Order will identify the services and intended deliverables, fees and billing method, service period or milestones, material Customer dependencies, acceptance criteria where applicable, and any included support or hosting. Section 7 governs deliverable ownership and licenses unless the Order states otherwise. Invoice deadlines, commitments, renewal and any cancellation or acceleration terms are stated in the Order. Only expressly ordered services are included. Proposals, demonstrations, roadmaps and informal discussions do not expand an Engagement. A fixed fee covers only its agreed scope and assumptions. Time-and-materials estimates are budgeting estimates, not fixed prices or guarantees of completion; any expressly accepted spending ceiling remains binding. AgentShelf is not required to continue work beyond an approved ceiling without an approved increase. Training and advisory services purchase professional time and expertise, not a particular operational or commercial result. Maintenance, new features, content updates, monitoring, third-party fees and post-project support are excluded unless expressly included. Purchasing an Engagement does not purchase a Platform subscription, Credits, Marketplace rights, voice or messaging service, or a third-party license. #### 3. Delivery and Customer cooperation AgentShelf controls its delivery methods, personnel and work sequencing, subject to the Order, agreed security requirements and applicable law. Services are delivered remotely unless the Order provides otherwise. AgentShelf may replace personnel with comparably qualified personnel; no particular individual is guaranteed unless expressly agreed. Each party will designate a project contact. Commercial amendments require the authority and approvals specified in the Order and Agreement. Customer will timely provide accurate requirements, content, decisions, testing, personnel and lawful access reasonably needed for the Engagement, including domain, DNS and connected-account access where relevant. Customer is responsible for rights, licenses, notices and consents for its materials, instructions and deployments. It must disclose material regulatory, industry, security and residency requirements before contracting. Undisclosed requirements do not become included services or agreed certifications. Customer will maintain appropriate backups, access controls and deployment safeguards for Customer-controlled systems. Dates identified as estimates are not guaranteed deadlines. AgentShelf is not responsible for delay or nonperformance to the extent caused by Customer's unmet dependencies, unauthorized changes or third parties outside AgentShelf's contractual responsibility. AgentShelf may pause affected work and reschedule personnel. Such a delay does not excuse fees due or extend a purchased service period. Additional fees or revised commitments require accepted Order terms or a written change order. #### 4. Changes and additional work Changes to scope, deliverables, assumptions, schedule, fees, material staffing requirements or processing restrictions require a written change order accepted by authorized representatives of both parties under the Order's amendment process. AgentShelf has no obligation to begin changed work before that approval and may pause affected work while a change is assessed. An Order may authorize a designated contact to approve additional hours or tasks in writing at already agreed rates and within stated limits. That approval authorizes only the identified work and resulting fees. Routine feedback, a support request or acceptance of a deliverable does not authorize additional billable work. AgentShelf may decline requests outside scope. Correction of a valid acceptance rejection or an express warranty nonconformity is not an additional chargeable scope change. An enhancement or changed preference is not a defect merely because Customer requests it during acceptance or warranty review. #### 5. Fees and payment protections Customer will pay the fees, taxes and approved expenses stated in the Order. Time-and-materials charges are based on work performed within the authorized scope at agreed rates; fixed-fee, milestone, retainer and reserved-capacity charges follow the accepted billing schedule. Monthly installments do not turn an expressly accepted fixed commitment into a month-to-month engagement. Payment is not contingent on an unpurchased feature, Customer's business results or a third party paying Customer. Invoice payment periods and any late charges are stated in the signed Order or SOW or executed Enterprise MSA. Customer will promptly describe an invoice dispute in writing with supporting details, pay undisputed amounts when due and cooperate in resolving the disputed portion. Travel, lodging and other out-of-pocket expenses require prior written approval and will be reasonably documented. An agreed price excludes applicable taxes unless the Order states otherwise; taxes legally due will be identified on the invoice, excluding taxes based on AgentShelf's net income. Customer pays AgentShelf unless it separately contracts with another provider. Platform subscriptions and Engagement charges remain governed by their own accepted payment terms even when shown on the same Order. A combined summary does not merge invoice streams designated as separate in the Order. A saved payment method, these Services Terms or approval of work alone does not authorize automatic collection. Automatic payments require the applicable affirmative authorization for the disclosed charges and timing. #### 6. Retainers and purchased hours A retainer reserves the availability, time and effort described in the Order; it is not a promise to complete unlimited requests or achieve a particular result. Services are scheduled subject to the agreed service period, delivery hours and reasonable personnel availability. Urgent, after-hours and on-call support are included only if expressly purchased. Included retainer hours expire at the end of their applicable service period and do not roll over, accumulate, transfer or convert to cash unless the Order expressly provides otherwise. Prepaid blocks and packaged services have the consumption period expressly stated in their Order. Customer's failure to request or attend available services does not alone create a refund or extend that period. Additional hours require the approval described in Section 4 and are outside the retainer unless expressly included. Preparation, meetings, analysis and documentation count as professional time when reasonably undertaken within the ordered scope. Customer-delay or missed-session charges apply only if disclosed and accepted in the Order. Discounts apply only to the services and periods expressly identified in the Order. They do not automatically carry into an extension, renewal, additional service or additional hours unless the Order expressly includes them. A fixed-term Engagement expires without automatic renewal unless its Order expressly establishes the renewal terms and applicable payment authorization. #### 7. Work product and intellectual property **Customer materials and Outputs.** Customer retains its supplied materials and the Customer Content and Output rights granted by the Agreement. Customer permits AgentShelf to use those materials only as authorized by the Agreement and needed for the Engagement. Their inclusion in a report, configuration or deliverable does not transfer them to AgentShelf or permit unrelated reuse. **AgentShelf ownership by default.** "Work Product" means reports, designs, documentation, code, configurations and other materials created or supplied by AgentShelf for an Engagement, excluding Customer Content, Outputs and third-party materials. AgentShelf retains its rights in Work Product unless the Order expressly assigns designated deliverables. AgentShelf also retains its Platform, pre-existing materials, reusable tools, templates, generic components, methods, improvements and know-how ("AgentShelf Materials"). Work commissioned or paid for by Customer is not automatically a work made for hire or an assignment. **Default paid-use license.** Upon payment of all amounts due under the applicable Order, AgentShelf grants Customer a perpetual, worldwide, non-exclusive, royalty-free license to use, reproduce, modify and maintain that Work Product for Customer's business purposes, including public display and deployment on Customer's websites or other customer-facing channels within the Order's scope. Customer may allow its service providers to exercise those rights solely on its behalf, subject to appropriate confidentiality protection. This does not license standalone resale or distribution of AgentShelf's reusable tools or Platform source code. Transfer is permitted only with an assignment allowed by the Agreement. **Express assignments.** If an Order expressly identifies deliverables created specifically and exclusively for Customer as assigned "Customer Deliverables," AgentShelf assigns its rights in those deliverables upon payment of all amounts due under the applicable Order, excluding AgentShelf Materials and third-party materials. Embedded AgentShelf Materials are licensed under the paid-use license above to the extent necessary to exercise the assigned rights. File formats, source files and handoff items must be identified in the Order; an assignment does not transfer Platform source code, internal repositories or unrelated development materials. **Retained and third-party rights.** AgentShelf may reuse its own general technology, skills and know-how and develop similar services for others, but not Customer's Confidential Information, Customer Content, Outputs or exclusively assigned Customer Deliverables. AgentShelf will obtain from personnel and Delivery Partners the rights necessary to grant the expressly agreed rights. Third-party and open-source components remain subject to their licenses. No party transfers rights it does not hold. Continued access to hosted services requires the applicable active service agreement; a perpetual Work Product license does not include perpetual hosting, maintenance or model access. #### 8. Deliverable acceptance Acceptance applies only to deliverables designated for acceptance, not to recurring availability, time-based advice or hosting unless the Order states otherwise. Customer has ten business days after delivery, or the different period stated in the Order, to accept or give written notice describing a material failure to meet the agreed scope or acceptance criteria. "Business day" means Monday through Friday, excluding United States federal holidays. AgentShelf will use commercially reasonable efforts to correct a valid nonconformity and resubmit the affected portion. A deliverable is accepted upon Customer's written confirmation, production use other than testing, or expiry of the review period without a valid written rejection. Minor defects that do not materially impair agreed functionality do not prevent acceptance but remain subject to any express warranty. A corrected portion receives the same review period, limited to the identified nonconformity and changes introduced by its correction. Previously accepted unaffected portions are not reopened. #### 9. Professional services warranty AgentShelf warrants that paid Professional Services will be performed in a professional and workmanlike manner by appropriately skilled personnel and materially conform to the applicable Order. Customer must notify AgentShelf in writing of a material nonconformity within thirty calendar days after performance or, for a deliverable subject to Section 8, within thirty calendar days after acceptance. A timely valid acceptance rejection remains subject to Section 8 even before acceptance. For a valid claim, AgentShelf will, at its option and expense, correct the affected deliverable, reperform the affected services, or terminate the nonconforming portion and refund fees paid attributable to that portion. If AgentShelf elects correction or reperformance but cannot materially cure the nonconformity within a reasonable period, Customer may terminate that portion and receive that refund. These are Customer's exclusive Professional Services warranty remedies, subject to non-excludable legal rights and any expressly controlling Order or Enterprise MSA. This warranty does not cover a nonconformity caused by Customer's materials or instructions, unauthorized modifications, use outside the agreed scope, or third-party products outside AgentShelf's contractual responsibility. These Services Terms do not guarantee revenue, conversion, search ranking, regulatory compliance, uninterrupted availability, error-free software or accurate AI Outputs. Advisory services are not legal, tax, financial or regulated professional advice unless expressly agreed through an appropriately qualified engagement. This section governs Professional Services warranties only. The Agreement's other disclaimers and limitations remain in force. No uptime commitment or service credits arise without an expressly agreed SLA. #### 10. Confidentiality and approved data use The Agreement's confidentiality, security, privacy and data-processing obligations apply throughout the Engagement. Customer will identify intended systems, data categories and processing restrictions before access is granted. Customer will grant only the access the work requires and is responsible for authorizing credentials and production changes. The Agreement's data-use and no-training commitments for Customer Content and Outputs apply to Professional Services. Approved AI use remains subject to the AI and Product Schedule, agreed provider restrictions and required authorizations, including any Contributor Model opt-in. Where required by law or the agreed processing arrangements, the parties must execute a DPA before the relevant processing. Return, deletion and incident notice follow the Agreement, applicable DPA and law. #### 11. Hosting and managed services Hosting, maintenance and managed operations apply only to the systems, tasks and service period identified in the Order. The Order identifies the included operations, including any agreed backups, restoration, monitoring, content changes and transition support. AgentShelf is not required to operate an unlisted system or provide an unpurchased support level. Customer remains responsible for its business content, lawful deployments, domains and third-party accounts under its control. Unless expressly agreed, a website build does not include ongoing hosting or maintenance, and a hosting purchase does not include a new build. Changes affecting an integration, third-party platform or model may require an approved scope change. #### 12. Delivery partners and independent contractors AgentShelf may use qualified affiliates, contractors and Delivery Partners and remains responsible for their performance to the same extent as its own under the Agreement. AgentShelf will require them to comply with appropriate confidentiality, security and data-protection requirements. AgentShelf manages its personnel and partner relationships and is responsible for their compensation and applicable employment obligations. They are not Customer's employees or agents and have no authority to amend Customer's contract or collect payment from Customer. Customer may specify outcomes and reasonable access and security requirements but does not assume employer functions. Staff augmentation or direct Customer supervision requires a specifically agreed arrangement. Customer will direct commercial and scope instructions through AgentShelf or the contacts expressly authorized in the Order. #### 13. Expiry suspension and termination An Engagement starts and ends as stated in its Order. Customer may not cancel an express fixed commitment for convenience unless its Order grants that right. Expiry of a fixed term creates no renewal or new commitment by itself. Any agreed renewal, extension, notice period or revised price must follow the Order and the Agreement's acceptance requirements. Either party may terminate an affected Engagement for a material breach not cured within thirty calendar days after written notice, or immediately if it cannot be cured, unless a controlling Order or Enterprise MSA sets a different process. AgentShelf may suspend affected work as the Agreement provides, including for nonpayment, unlawful activity or a security threat. Customer remains responsible for fees properly earned or due, approved additional work, applicable taxes and approved non-cancellable commitments. Future committed fees, early-termination charges or acceleration apply only as expressly disclosed and accepted in the Order, not by implication from these Services Terms. No future commitment is payable for a portion validly terminated for AgentShelf's material breach, terminated by AgentShelf without cause, or covered by an express refund remedy, subject to the Agreement and applicable law. Fees for services performed, completed milestones and reserved service periods made available are non-refundable except under the Agreement, an express Order remedy or mandatory law. If AgentShelf terminates without cause or Customer validly terminates for AgentShelf's uncured breach, unused prepaid fees attributable to the terminated portion will be refunded. A warranty refund follows Section 9. On termination, AgentShelf will stop affected work and provide paid-for Work Product and work in progress in their then-current form under the agreed rights. Additional migration, retraining, replacement-provider support or other transition work requires agreed scope and fees. Termination does not revoke an assignment or perpetual license already earned by payment; its use remains subject to its scope and restrictions. Payment, confidentiality, intellectual-property rights, indemnities, liability limits and other obligations intended to survive continue under the Agreement. #### 14. Risk allocation and disputes The Agreement's indemnities apply only within their stated scope. Ordering Professional Services, identifying a deliverable or assigning Work Product does not expand the Platform Terms' infringement indemnity to commissioned work, Outputs, generated code or third-party materials. No additional indemnity is created here. The Agreement's exclusions and single aggregate liability limit apply to Professional Services, warranties, confidentiality, privacy, security and subcontracted performance to the extent stated there and permitted by law. These Services Terms create neither a second cap nor an uncapped professional-services obligation. Customer's payment and indemnity obligations remain subject to the Agreement's treatment of them. Governing law, venue, informal dispute resolution and any separately agreed arbitration follow the Agreement without a new dispute regime. Non-excludable legal rights remain in force. #### 15. Updates and notices The dated Services Terms accepted for an Engagement apply to it. Updates follow Section 22 of the Platform Terms or an executed Enterprise MSA's controlling notice, acceptance and amendment provisions, and do not amend a signed Order. Current and dated versions are published in the [AgentShelf Legal Center](/legal). Contractual notices to AgentShelf must be sent to **legal@agentshelf.ai**, unless an executed agreement specifies another method. Customer notices use the legal-notice contact designated in the Order or the Agreement's applicable fallback. Project communications and support requests do not replace contractual notice. Product support is available at **support@agentshelf.ai**.