Building and editing graphs with Penny.

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.

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.

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.

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.

#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 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.

#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.

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 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.