Docs / Core Concepts / Trained Tasks

Trained Tasks

Trained Tasks carry forward context from every past execution — so your agent's critical tasks never start from zero.

What are trained tasks?

A trained task carries forward context from every past execution. Your agent’s critical tasks never start from zero.

The first time a crm-agent runs a task against a CRM, it connects, authenticates, and fetches data. Fine, that works. The fiftieth time, it already knows the rate limits, the field naming quirks, the optimal batch size — because every previous run taught it something. Training is scoped to each subagent’s domain — a crm-agent builds CRM execution memory, a billing-agent builds payment execution memory.

Training builds two kinds of knowledge:

  • Tool knowledge — What Ploton has learned about working with a tool. API endpoints, auth flows, data formats, pagination patterns, rate limit behavior, required scopes. Built from real interactions, not just docs.
  • Execution memory — What actually happened in past runs. Which OAuth scopes were needed, which field mappings resolved edge cases, which retry strategies recovered from failures, what batch sizes performed best under load.

This isn’t a cache. It’s institutional knowledge that compounds over time.

How tasks get trained

A brand-new tool starts with baseline knowledge: the subagent knows the service’s API, auth requirements, and data model. That’s enough to run tasks. But every execution teaches the subagent something new, and that context carries forward.

Run 1:
  Task connects to the CRM → OAuth flow → fetches contacts → success
  Learned: OAuth required scopes [contacts.read]

Run 5:
  Task reuses known scopes → skips discovery → 40% faster
  Learned: Rate limit is 100 req/10sec for this tier

Run 20:
  Task hits a schema change → adapts field mapping → recovers
  Learned: Field "lifecycle_stage" renamed in the latest API version

Run 50:
  Task knows optimal batch size (100), common field mappings,
  typical failure patterns, and fastest recovery paths
  → Handles edge cases automatically that would have failed on run 1

This learning is automatic. You don’t configure it, tune it, or maintain it. Tasks get better as a side effect of running.

flowchart TD
    A[Run 1: First execution] -->|Learns auth scopes| B[Run 5: Skips discovery]
    B -->|Learns rate limits| C[Run 20: Handles schema drift]
    C -->|Learns failure patterns| D[Run 50+: Deep context]
    D --> E[Handles edge cases<br/>that would fail on Run 1]

    style A fill:#1a1630,stroke:#FF5F56,color:#e8e0f0
    style B fill:#1a1630,stroke:#FACC15,color:#e8e0f0
    style C fill:#1a1630,stroke:#FACC15,color:#e8e0f0
    style D fill:#1a1630,stroke:#50FA7B,color:#e8e0f0
    style E fill:#1a1630,stroke:#50FA7B,color:#e8e0f0

What training captures

Each subagent maintains three layers of training for its tools:

Baseline tool knowledge

The static foundation. API endpoints, request/response schemas, auth protocols, supported operations. This is what the subagent knows about a tool before any task has ever run against it.

Execution memory

The dynamic layer, built from real task execution:

  • Successful strategies and the contexts where they worked
  • Failure patterns and the recovery approaches that fixed them
  • Performance characteristics (rate limits, optimal batch sizes, latency profiles)
  • Service-specific quirks (undocumented behavior, version-specific edge cases)

Adaptation patterns

General strategies for handling common failure classes:

  • Token expiry — Detect, refresh, and resume without restarting the task
  • Rate limiting — Back off based on observed limits, not just documented ones
  • Schema drift — Detect field changes and try mapping to known equivalents
  • Service outages — Tell the difference between transient failures (retry) and hard failures (escalate)

How tasks become trained

A tool is a raw capability — a CRM API, a payment API, a database. Training is what accumulates when a subagent runs tasks against that tool.

Every tool starts as a connector. As tasks run through a subagent, the experience — what worked, what failed, how to recover — becomes training scoped to that subagent’s domain. Trained Task = task + context from every past execution within the subagent’s domain.

The point: for your critical tasks, your subagents never start from scratch. A task routed to crm-agent benefits from everything previous CRM tasks have learned. Same goes for any subagent, not just popular services with pre-built integrations.

Pre-trained tools

Ploton ships pre-built subagents with pre-trained tools for popular services (CRMs, payment processors, storage, messaging, databases). These come with tool knowledge built in and get better with execution memory from your tasks.

See Tools: Built-in tools for the full list.

Custom training

You can deploy custom subagents with training for your own internal services, proprietary APIs, or specialized workflows. Custom training follows the same architecture — tool knowledge plus execution memory — but you provide the initial knowledge about your service.

See Registering Custom Tools for the full guide.

Next steps

Previous Workflows Next Webhooks