Shared foundations & methods

Agent-Art-Lab Guidance

Shared, revisable guidance for creating and studying Agent Art. The definition source retained by this edition is Inshell's public documentation; that source attribution does not determine the Lab's organizational ownership. This guidance does not replace that definition or act as a release gate.

Begin with the work

Agent Art is art in which an Agent participates at the level of intention. Ask what the Agent may interpret, choose, propose, direct or do, and how that enters this particular work. Do not treat a tool call, generated output, model name or protocol receipt as sufficient proof of intentional participation.

A work chooses its own relation between human and Agent, its bounds on initiative and review, and its preservation method. No single relation is prescribed by this Lab. Technical success, creative interpretation, intentional participation and artwork judgment answer different questions.

Choose a method, not a universal workflow

Method Useful for Minimum record
Practice-led exploration Artistic/material inquiry, choices, encounters, interpretation Intention, conditions, artifacts, choices, surprises and situated reading.
Empirical comparison A bounded observable difference between alternatives Question, factors, invariants, measures, sample budget and stop/revision rules declared before results.
Retrospective diagnosis Understanding an existing failure or discrepancy Provenance, sequence, actual actions, competing explanations, supported conclusion and unknowns.
Combined Related artistic and technical questions Keep the methods and their claims separate.

A practice-led study does not need a numeric artwork score. A diagnosis must not be relabeled a preregistered experiment after seeing the result. A comparison that changes after outcomes starts a new revision.

Research, refine, observe, learn

  1. State the bounded artistic or technical question and why it matters.
  2. Research relevant sources. Record each source's task, evidence, limits and applicability, not only its recommendation.
  3. Refine the study and record permissions, live scope, cost and stop conditions.
  4. Observe or test using the project's own tools. Label what is synthetic.
  5. Compare outcomes where justified; retain refusals, failures and uncertainty.
  6. Record conclusions and method evaluation.
  7. Propose a shared practice only with scope, supporting evidence, limitations and a condition for review.

This is an on-demand routine, not a scheduled live test. Legitimate refusal, clarification and permission boundaries are conditions to understand, not safeguards to evade.

Evidence classes

  • Source/research: a published paper, specification or inspected source. Does not automatically describe a current agent/product.
  • Deterministic/simulated: checks a model of the mechanism.
  • Real-Agent fixture: observes a real agent against a synthetic system; not automatically Desktop or real-product evidence.
  • Product observation/canary: names candidate, surface, environment and actual intervention. Separate system evidence from operator/agent reports.
  • Artwork artifact: preserves a work and its conditions.
  • Situated interpretation: ties artistic judgments to artifacts and an observer; does not become runtime fact.
  • Replicated comparison: supports only the measured claim under the declared conditions. Repetitions and counterevidence remain visible.

Neither exit status nor an agent's success message proves external completion. Use independent completion evidence appropriate to the project. THOUGHT uses an App receipt; other projects need not.

Provisional practices

  • Keep actual surface, configuration, permission, action, completion and interpretation separate. Do not relabel CLI evidence as Desktop evidence.
  • Distinguish a fixture-supplied capability from the real process that acquires it. Test that acquisition path when it matters to the question.
  • Preserve original records; append dated corrections and new iterations.
  • Keep shared methods small. Generalize tools only after recurring need.
  • Evaluate the method itself after a study: observed benefits, missed steps, cost if measured, and limits. One useful application is not causal proof.
  • Maintain publication-safe derivatives separately from private originals.
  • For exact representations, inspect both sending and receiving boundaries; test plausible incorrect interpretations as well as the reference helper.
  • For worker protections, check the final process/channel with fake input; a proof made before a process transition may not cover what executes later.
  • Keep secret-free operation/class evidence and follow established recovery rules; an uncertain error is not proof of no commit or permission to replay.
  • Record functional completion and instruction compliance separately. A successful return can coexist with omitted checks; neither should erase the other.

These additions are bounded by the THOUGHT follow-up and P-04–P-06 in the linked findings register; they do not establish general reliability or require every artwork to use workers.

The findings register records scope and review conditions. Start from project intake and study; neither template grants execution authority.

Provisional connection: supported tools and explicit prerequisites

Prepared locally on 2026-10-01; the operator subsequently authorized this sanitized documentation contribution that day. The guidance remains provisional.

Use the smallest supported native path, state its tools and permissions explicitly, and verify completion. Smallest means sufficient for the task and its checks. Native means an existing supported tool using its normal identity; name it when compatibility matters. State permissions for the command/process that actually executes, not only the client it launches. A named tool grants no authority; unavailable or denied permission is a boundary to respect.

Plain/raw concerns the exchange and its exact representation; native concerns the supported means; explicit concerns the execution contract. These choices leave artistic interpretation within the work's bounds. Stability is a design aim, not a measured universal outcome. Pulse succeeded with Python, so this is not an "always curl" rule or a requirement to use raw text for every project.

The 2026-10-01 THOUGHT study connects P-04–P-07 without changing their scopes. Its new runtime evidence is OPS-reported; the Lab has not independently verified the private records.

Transfer to another artwork

Reuse evidence distinctions, research habits and record discipline. Reconsider the artwork's premise, materials, agent role, authority, implementation, risk, preservation and interpretation. THOUGHT's protocol, receipts, metadata requirements and release gates are not universal Agent-Art-Lab requirements.