agent-native-redesign

Files (1)

• SKILL.md

SKILL.md (first lines)

# Agent-native redesign

Explore how the subject should work if intelligent execution were an abundant resource. Question structures inherited from scarce human attention, expensive coordination, earlier model capabilities, and historical implementation choices. Design around the desired outcome, with agents able to perform sustained work and use feedback to improve results.

## Establish the subject and outcome

Infer the subject from the active conversation and relevant available artifacts. Use the current project as the subject when the conversation does not identify a different one. Honor the user's additional focus and constraints. Inspect enough context to ground the analysis; do not default to analyzing a repository when the conversation concerns a different process or scenario.

Briefly state what is being redesigned, who benefits, and what successful results look like. Proceed on a reasonable stated interpretation; ask a focused question only when the subject or a consequential ambiguity cannot be resolved from context.

Understand the current path from input to outcome: decisions, execution, handoffs, information, and feedback. Ground claims about the current system in observed evidence, and label inferred explanations for why it was designed that way.

## Separate inherited assumptions from necessary conditions

Find the assumptions that materially shape the current approach. For each important assumption, connect its original rationale to the structure it created, then examine whether that rationale still applies under abundant agent capacity.

Useful lenses include:

- Human attention and coordination: queues, batch schedules, role boundaries, manual handoffs, sampling, and work left undone because individualized handling was too expensive.
- Earlier capability limits: tiny task boundaries, rigid categories, shallow context, or mandatory human interpretation that may reflect outdated beliefs about models and agents.
- Historical implementation: interfaces, architecture, organizational ownership, or compatibility choices treated as requirements without examining the outcome they serve.
- Access to information and action: knowledge trapped in people's heads, chat threads, or interfaces; missing machine-accessible state and feedback that prevent agents from completing work independently.

Distinguish a necessary outcome or obligation from its present implementation. An approval procedure can be redesigned while preserving the accountability it serves. Explain which apparent constraints could change and what would make that change legitimate; do not assume every inherited choice is obsolete or silently discard a confirmed requirement.

## Design the ideal operating model first

Treat agent availability and token budget as effectively unlimited for this thought experiment. Temporarily set aside sunk costs, migration effort, and attachment to existing interfaces. Explore what becomes worthwhile when each case can receive sustained attention, multiple approaches can be explored, and work can continue between human interactions.

Describe the best end-to-end arrangement for the outcome. Reconsider product shape, process, responsibilities, system boundaries, and interfaces where they matter. Avoid stopping at adding an assistant to each existing step; identify steps or handoffs that can disappear, merge, or become continuous.

Make the proposed operation concrete:

- What starts or sustains the work, and what context and state are available?
- What can agents decide and execute, and what remains with people or ordinary software?
- How are results checked against the real outcome, and how do failures lead to correction, recovery, or a justified human decision?
- What defines completion or continued monitoring, and what prevents an unproductive loop from running indefinitely?

Use ordinary software for predictable execution where it fits. Choose agent roles and coordination only where they improve the outcome; more agents are not themselves a measure of success.

Keep this ideal-design pass separate from the feasibility pass below. If the ideal depends on an unverified capability or a negotiable constraint, name that dependency instead of either suppressing the idea or pretending the dependency is solved.

## Explain the improvement and test the limits

Compare the proposed operation with the current one using dimensions relevant to the outcome: quality, coverage, delay, throughput, unattended completion, and human effort per completed case. Explain the mechanism behind each claimed gain. Use estimates only with stated assumptions; do not invent numerical improvements.

Test what happens as work and agent capacity grow. Identify the new bottleneck: human review, shared state, coordination, external services, physical execution, or feedback quality. If doubling output requires doubling human supervision, explain the remaining limit to automation and how the design might reduce it. Do not promise proportional scaling just by adding agents.

Abundant tokens do not supply missing facts, permissions, reliable judgment, zero latency, or unlimited external capacity. Examine these dependencies after developing the ideal. When feasibility depends on a claim about current models or tools, verify it against recent primary evidence or a representative experiment where available; otherwise mark it unverified. Neither inherited pessimism nor confidence that agents will somehow manage is evidence.

Identify the assumption whose failure would most seriously undermine the redesign. Propose the smallest representative test, including an observable success criterion and what result would require changing or abandoning the proposal. Avoid validating only easy cases or treating agent self-reports as proof of external success.

Add a practical entry point or migration path when useful, while keeping it distinct from the ideal destination. The abundant-budget premise guides the design; actual experiments and implementation stay within the user's requested scope and available resources.

## Present a concrete redesign

Respond in the user's language and scale the detail to the subject. Make these points easy to find without imposing a long report on a small question:

- **Inherited assumptions:** the consequential constraints to challenge, their evidence, and what changes when they are relaxed.
- **Ideal operation:** how work moves from input to verified outcome, including agent, software, and human responsibilities.
- **Improvement and limits:** why this produces better outcomes, more automation, or greater scale, and where the next bottleneck lies.
- **Critical validation:** the most consequential uncertainty, the smallest useful test, and the recommended next step.

Connect recommendations to this subject's actual work. A list of AI features or renamed human roles is insufficient. If the current structure remains appropriate after scrutiny, say which assumptions survived and where abundant agents would add little value.

For example, a support operation organized around weekly ticket triage might be redesigned around continuous case resolution: agents gather context, take permitted actions, verify whether the user's problem was resolved, and follow up on unfinished cases. People handle exceptions requiring their judgment or authority. The design must explain how resolution is observed and whether human effort per resolved case falls as volume grows; replacing each triage role with an agent does not answer those questions.

From jtsang4/efficient-coding, MIT.

More from jtsang4/efficient-coding