# Building and editing graphs with Penny

> Brief a new workflow, target changes in an existing graph, check inputs and wires, and test the intended output with Penny.

Source: https://kaitoi.io/docs/studio/penny-graphs/
Section: Kaitoi Studio / Penny
Written for: Anyone building or changing a Studio graph with Penny.
Last reviewed: 2026-10-24

---

Penny can inspect the current graph, find available nodes, add and connect
steps, and change existing inputs. A useful request describes both the result
you want and the work Penny may change. Review the graph itself and its run
evidence before treating the request as complete.

## Start in the intended project

Open the project and use **Assistant** in the graph toolbar. Check the active
conversation and graph before referring to earlier work. For composer,
model, and conversation controls, see [Working with Penny](/docs/studio/penny/).

To preserve an original, use **Save As before editing** and work in the copy.
Duplicating a Penny conversation does not duplicate its graph. Autosave may
already include edits by the time you decide to make a copy; see
[Saving and recovery](/docs/studio/saving-and-recovery/).

Before changing inputs, check evaluation settings: eligible nodes in Auto can
run after edits. Use Manual on affected nodes when you want to choose when to
test, and state the execution boundary in your brief.

## Brief a new workflow

Describe the inputs you already have, the logical stages, the final outputs,
and the settings you want to adjust later. Include dimensions, formats,
variation counts, and acceptance criteria when they matter. For example:

> Build a workflow from my reference image to a square image and a short
> caption. Keep the reference as an input I can replace. Expose the output
> size as a control. Use available nodes where possible. Build only; do not
> run nodes. List the nodes and connections you created and anything missing.

Ask Penny to inspect the current catalog rather than assuming a node name or
provider exists. Availability can depend on your account and configured
services. When a required operation is missing, decide whether to choose a
different available step or have Penny create a custom node.

## Define one edit and what must stay

Select a small set of relevant nodes and name the exact target in the brief.
For duplicate labels, ask Penny to identify the node IDs first. A large
selection has bounded initial context; do not assume every selected node is
fully described to the assistant.

> Change only B, the Resize node, from 768 to 1024 pixels wide. Keep its image
> input connected to A and its output connected to C. Preserve the separate
> caption branch D. Do not create replacement nodes or run the graph. Report
> the actual settings and connections after the edit.

Selection gives Penny context. It does not prevent tools from editing other
nodes. State the preserved scope explicitly and check the resulting graph.
For a multi-step change, ask Penny to complete and report one useful stage at
a time.

## Compare the graph before and after


**Before:** A feeds B, B feeds C, and A also feeds the separate caption branch
D. B's width is 768. **After edit:** B's width is 1024; the same four nodes and
three connections remain. D is unchanged. C still shows an earlier preview:
no new run has verified the edited width.

This conceptual graph uses illustrative node labels and authored kite
artwork, not a Studio screenshot or a node catalog schema. Switching states
changes only this illustration.

*Figure: Compare a narrow input edit with the connections and earlier output that remain unchanged.*

Check node identity, values, wire endpoints, and any additions or removals.
A changed label is not a new implementation. A successful input update is
not evidence that the whole request succeeded; some tool operations can
report partial results.

## Distinguish values, wires, and node code

| Intended change                    | What to ask for and inspect                                                                        |
| ---------------------------------- | -------------------------------------------------------------------------------------------------- |
| Change a manual setting            | Name the node, input or control, value, and units. Verify the saved value.                         |
| Use another node's result          | Identify both nodes and the actual output and input pins. Verify the new wire.                     |
| Replace a wire with a manual value | Ask to disconnect that input and set its value. Check both actions.                                |
| Change the operation itself        | Specify whether to configure an existing node, replace it, or edit a custom node's implementation. |

A connected input gets its value from its source. Changing the manual value
alone does not remove the wire or make that value take precedence. Ask Penny
to inspect actual pin names and types before connecting nodes; similar
labels do not guarantee a compatible connection. See
[Graphs and nodes](/docs/concepts/graphs-and-nodes/).

## Choose an existing node or a custom node

Use an available node when its operation and controls fit. If you need custom
behavior, describe the inputs, editable controls, outputs, and failure cases.
State whether Penny should modify an existing custom node or create another
one, and which connections must survive.

Review the generated interface and implementation warnings. Creating or
saving code does not prove it runs correctly. Test a small example before
depending on its output. Available code-editing tools vary by surface and
account; a phone does not expose every desktop tool.

## Check structure and readiness

Ask Penny to inspect the changed nodes and use its graph validation tool.
Read both errors and warnings. Its structural checks can flag missing
required values, connections referring to missing nodes, and isolated nodes.
An intentionally separate node can be valid for your workflow despite an
isolation warning.

Validation does not execute the graph or prove that every pin, provider
credential, file, or generated result is usable. Check reference files,
provider access, model settings, and required inputs before a test. Ask Penny
to list anything it could not verify.

## Decide whether edits may trigger execution

Use **Manual** evaluation for affected nodes when you want to control testing.
Eligible unlocked nodes in **Auto** can run in response to input changes.
Also state **“Build only; do not run nodes”** in the request and inspect the
evaluation settings. See [Runs](/docs/concepts/runs/) for Auto, Manual, and
locked-node behavior.

Building can still use a paid assistant model. Before authorizing expensive
work, ask for an estimate and check the intended provider and output count.
A budget in a message is not an enforced spending cap, and unknown pricing
does not mean free execution. See [Credits and billing](/docs/reference/credits/).

## Test the smallest useful target

Name the node to run and the inputs to use. Running a target includes its
required upstream dependencies; it does not mean every branch of the project
will run. Clean upstream results may be reused. Locked nodes have separate
cache behavior, so inspect them before drawing conclusions from a test.

## Compare test scopes


The cases are independent. Assume A has a valid clean cache, B was edited,
C is affected by that edit, and B and C are unlocked in Manual mode. The
separate caption branch D is outside each test. **Inspect only:** read an
existing result without starting a run. **Test B:** reuse A and execute B;
C and D are outside the run. **Run C:** reuse A and execute B and C; D is
outside the run. A reused result is not a fresh execution.

This is an execution-scope concept, not a live plan, cost estimate, or promise
of success. The controls run no nodes.

*Figure: Compare inspecting an earlier result, testing an edited step, and running its final downstream output.*

Testing an intermediate step does not verify its downstream final output.
When the intermediate result is correct, test the intended final target and
inspect its actual media or value. Your graph's locks, dirty state, inputs,
and cache availability can change what executes.

## Read evidence before calling it finished

Ask Penny to separate **changed**, **executed**, **reused**, **failed**, and
**not verified**. An existing preview can be older than the current settings.
Reading a cached output does not rerun its node. A report for requested
targets does not prove that every upstream node executed afresh.

Check the final dimensions, format, content, and other acceptance criteria.
Keep useful media through [Files and results](/docs/studio/files-and-results/)
and save the intended graph through the project's save controls. A
conversation summary is not a media backup.

## Recover from a partial change or failed test

Stop an active Penny request before issuing a conflicting one. Inspect which
nodes and wires actually remain; an error is not a guarantee that all earlier
changes were undone. **Stop Agent** does not undo completed edits or reverse
provider usage. Inspect graph execution separately if a run already started.

Give Penny the error, target node, last successful output, and the change that
preceded it. Ask for a diagnosis and a narrow fix, then repeat only the useful
test. A retry can repeat provider work. If you need the original graph,
return to the copy or saved recovery point you preserved before editing.