Lindy Performance TuningSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: lindy-performance-tuning
description: 'Optimize Lindy AI agent execution speed, reliability, and cost efficiency.

  Use when agents are slow, consuming too many credits,

  or producing inconsistent results.

  Trigger with phrases like "lindy performance", "lindy slow",

  "optimize lindy", "lindy latency", "lindy speed".

  '
allowed-tools: Read, Write, Edit
version: 1.20.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags:
- saas
- lindy
- performance
compatibility: Compatible with AI coding agents that can read Markdown and analyze workflow measurements
---
# Lindy Performance Tuning

## Overview

Improve a Lindy workflow through controlled, workspace-specific experiments. Measure
the current workflow in Tasks, preserve approval and security boundaries, change one
variable, run the same sanitized fixture/eval cohort, and keep the change only when
predeclared latency, quality, reliability, and cost criteria pass.

## Prerequisites

- Lindy workspace with active agents
- Access to agent Tasks tab (view step-by-step execution history)
- A representative, data-minimized fixture set and offline eval cohort
- Permission to inspect Tasks and restore a saved version
- An owner-approved list of invariants: confirmations, authorization, redaction,
  retention, and side-effect limits

## Instructions

### Step 1: Define the Experiment Contract

Before editing, record:

- one workflow class and representative sanitized fixtures;
- the exact variable to change and why it should help;
- baseline sample window and sample count;
- duration median/p95, outcome ratio, eval score, and workspace-reported usage/cost;
- acceptance and rollback thresholds; and
- security/approval invariants that must remain unchanged.

Use the Tasks view and Get Task Details to identify the slowest or least reliable
block. Do not infer universal latency or credit values from this skill.

### Step 2: Save a Rollback Point

Open Version History and identify the last known-good version. Record its timestamp
or label. Restoring a version creates a new editable version; it does not erase the
current history. Keep production activation and side-effecting actions unchanged
until the candidate passes the evaluation lane.

### Step 3: Choose One Variable

Prioritize the measured bottleneck:

| Bottleneck | Symptom | Fix |
|-----------|---------|-----|
| AI step dominates duration/usage | One step is the measured hotspot | Compare one available model/configuration while holding prompt/tools fixed |
| Repeated reasoning steps | Same context is processed repeatedly | Test a single structured step while preserving required checks |
| Broad autonomous scope | Variable paths or tool calls | Narrow skills and define measurable exit conditions |
| Knowledge retrieval dominates | Too many/large results | Reduce result scope while measuring answer quality |
| Independent list work is sequential | Per-item waiting dominates | Test a bounded loop and respect downstream rate limits |
| Trigger volume is noisy | Many irrelevant tasks | Add a precise trigger filter and verify recall |

Do not remove confirmation, authorization, validation, redaction, audit, or fallback
steps merely to improve speed. Model availability, behavior, and pricing change; use
the models currently offered in the workspace and compare them on the same cohort.

### Step 4: Make the Candidate Change

Example: consolidate repeated reasoning without exposing customer data.

Before:

```
Step 1: Classify a sanitized support fixture
Step 2: Extract approved routing fields
Step 3: Draft an internal response recommendation
```

Candidate:

```
Step 1: Return validated JSON containing classification, approved routing fields,
        and an internal response recommendation
```

Use placeholders or synthetic data in fixtures:

```json
{
  "classification": "technical",
  "productCode": "PRODUCT-A",
  "issueType": "access",
  "recommendation": "Send the approved access troubleshooting guide."
}
```

Exclude names, email addresses, full messages, account numbers, credentials, and
unnecessary conversation history. Keep any external communication in draft or Ask
for Confirmation mode while testing.

### Step 5: Run the Same Evaluation Lane

1. Run offline evals against the same selected historical/reference tasks. Lindy
   documents these evals as simulation that does not execute real actions.
2. Use the Test Panel only with test data and sandbox/test integrations. Lindy
   documents Test Panel actions as real, including API calls and side effects.
3. Inspect candidate Tasks/Get Task Details for duration and failures.
4. Compare the same metrics and cohort definition to baseline.
5. Reject the candidate immediately if any security/approval invariant changed.

### Step 6: Decide and Roll Out

Accept only when every predeclared criterion passes. Example decision policy:

| Gate | Example criterion selected before the run |
|---|---|
| Quality | Eval score is no lower than baseline |
| Reliability | Failure ratio does not exceed the agreed tolerance |
| Performance | Candidate p95 improves by the agreed minimum |
| Cost | Workspace-reported usage/cost does not regress beyond tolerance |
| Safety | Confirmation, permissions, redaction, and audit evidence are unchanged |

Roll out gradually, watch Tasks against the same thresholds, and restore the saved
version if a rollback criterion fires. Then change the next variable in a new
experiment; never combine results from several simultaneous edits.

## Optimization Patterns

### Prefer Deterministic Actions for Predictable Fields

Replace AI-powered fields with **Set Manually** mode when values are predictable:

| Field | Instead of AI Prompt | Use Set Manually |
|-------|---------------------|------------------|
| Slack channel | "Post to the support channel" | `#support-triage` |
| Internal category | "Choose an appropriate queue" | `support-triage` |
| Sheet column | "Determine the right column" | Column A |

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.