{
  "schema": "agent-art-lab.document/v1",
  "id": "guidance",
  "title": "Agent-Art-Lab Guidance",
  "page": "/guidance/",
  "revision": "sha256:d832ebbd0489d78d47eb3e80f3256b5680493856e9fcb6e1e4eabd3452118e12",
  "source": {
    "path": "GUIDANCE.md",
    "url": "https://github.com/agent-art-collective/Agent-Art-Lab/blob/main/GUIDANCE.md",
    "sha256": "d832ebbd0489d78d47eb3e80f3256b5680493856e9fcb6e1e4eabd3452118e12",
    "byteLength": 7147
  },
  "contentFormat": "markdown",
  "content": "# Agent-Art-Lab Guidance\n\nShared, revisable guidance for creating and studying Agent Art. The definition\nsource retained by this edition is Inshell's public documentation; that source\nattribution does not determine the Lab's organizational ownership. This guidance\ndoes not replace that definition or act as a release gate.\n\n## Begin with the work\n\n[Agent Art](https://inshell.art/docs/agent-art) is art in which an Agent\nparticipates at the level of intention. Ask what the Agent may interpret,\nchoose, propose, direct or do, and how that enters this particular work.\nDo not treat a tool call, generated output, model name or protocol receipt as\nsufficient proof of intentional participation.\n\nA work chooses its own relation between human and Agent, its bounds on\ninitiative and review, and its preservation method. No single relation is\nprescribed by this Lab. Technical success, creative interpretation, intentional\nparticipation and artwork judgment answer different questions.\n\n## Choose a method, not a universal workflow\n\n| Method | Useful for | Minimum record |\n| --- | --- | --- |\n| Practice-led exploration | Artistic/material inquiry, choices, encounters, interpretation | Intention, conditions, artifacts, choices, surprises and situated reading. |\n| Empirical comparison | A bounded observable difference between alternatives | Question, factors, invariants, measures, sample budget and stop/revision rules declared before results. |\n| Retrospective diagnosis | Understanding an existing failure or discrepancy | Provenance, sequence, actual actions, competing explanations, supported conclusion and unknowns. |\n| Combined | Related artistic and technical questions | Keep the methods and their claims separate. |\n\nA practice-led study does not need a numeric artwork score. A diagnosis must not\nbe relabeled a preregistered experiment after seeing the result. A comparison\nthat changes after outcomes starts a new revision.\n\n## Research, refine, observe, learn\n\n1. State the bounded artistic or technical question and why it matters.\n2. Research relevant sources. Record each source's task, evidence, limits and\n   applicability, not only its recommendation.\n3. Refine the study and record permissions, live scope, cost and stop conditions.\n4. Observe or test using the project's own tools. Label what is synthetic.\n5. Compare outcomes where justified; retain refusals, failures and uncertainty.\n6. Record conclusions and method evaluation.\n7. Propose a shared practice only with scope, supporting evidence, limitations\n   and a condition for review.\n\nThis is an on-demand routine, not a scheduled live test. Legitimate refusal,\nclarification and permission boundaries are conditions to understand, not\nsafeguards to evade.\n\n## Evidence classes\n\n- **Source/research:** a published paper, specification or inspected source.\n  Does not automatically describe a current agent/product.\n- **Deterministic/simulated:** checks a model of the mechanism.\n- **Real-Agent fixture:** observes a real agent against a synthetic system;\n  not automatically Desktop or real-product evidence.\n- **Product observation/canary:** names candidate, surface, environment and actual\n  intervention. Separate system evidence from operator/agent reports.\n- **Artwork artifact:** preserves a work and its conditions.\n- **Situated interpretation:** ties artistic judgments to artifacts and an\n  observer; does not become runtime fact.\n- **Replicated comparison:** supports only the measured claim under the declared\n  conditions. Repetitions and counterevidence remain visible.\n\nNeither exit status nor an agent's success message proves external completion.\nUse independent completion evidence appropriate to the project. THOUGHT uses\nan App receipt; other projects need not.\n\n## Provisional practices\n\n- Keep actual surface, configuration, permission, action, completion and\n  interpretation separate. Do not relabel CLI evidence as Desktop evidence.\n- Distinguish a fixture-supplied capability from the real process that acquires\n  it. Test that acquisition path when it matters to the question.\n- Preserve original records; append dated corrections and new iterations.\n- Keep shared methods small. Generalize tools only after recurring need.\n- Evaluate the method itself after a study: observed benefits, missed steps,\n  cost if measured, and limits. One useful application is not causal proof.\n- Maintain publication-safe derivatives separately from private originals.\n- For exact representations, inspect both sending and receiving boundaries;\n  test plausible incorrect interpretations as well as the reference helper.\n- For worker protections, check the final process/channel with fake input;\n  a proof made before a process transition may not cover what executes later.\n- Keep secret-free operation/class evidence and follow established recovery\n  rules; an uncertain error is not proof of no commit or permission to replay.\n- Record functional completion and instruction compliance separately. A\n  successful return can coexist with omitted checks; neither should erase the other.\n\nThese additions are bounded by the THOUGHT follow-up and P-04–P-06 in the\nlinked findings register; they do not establish general reliability or require\nevery artwork to use workers.\n\nThe [findings register](findings/REGISTER.md) records scope and review conditions.\nStart from [project intake](templates/PROJECT.md) and [study](templates/STUDY.md);\nneither template grants execution authority.\n\n## Provisional connection: supported tools and explicit prerequisites\n\nPrepared locally on 2026-10-01; the operator subsequently authorized this\nsanitized documentation contribution that day. The guidance remains provisional.\n\n**Use the smallest supported native path, state its tools and permissions\nexplicitly, and verify completion.** Smallest means sufficient for the task and\nits checks. Native means an existing supported tool using its normal identity;\nname it when compatibility matters. State permissions for the command/process\nthat actually executes, not only the client it launches. A named tool grants no\nauthority; unavailable or denied permission is a boundary to respect.\n\nPlain/raw concerns the exchange and its exact representation; native concerns\nthe supported means; explicit concerns the execution contract. These choices\nleave artistic interpretation within the work's bounds. Stability is a design\naim, not a measured universal outcome. Pulse succeeded with Python, so this is\nnot an \"always curl\" rule or a requirement to use raw text for every project.\n\nThe [2026-10-01 THOUGHT study](projects/thought/studies/2026-10-01-native-explicit-execution.md)\nconnects P-04–P-07 without changing their scopes. Its new runtime evidence is\nOPS-reported; the Lab has not independently verified the private records.\n\n## Transfer to another artwork\n\nReuse evidence distinctions, research habits and record discipline. Reconsider\nthe artwork's premise, materials, agent role, authority, implementation, risk,\npreservation and interpretation. THOUGHT's protocol, receipts, metadata\nrequirements and release gates are not universal Agent-Art-Lab requirements.\n",
  "assets": []
}