What Agentic Workflows Change About Problem Solving

Jack Dorsey, on Sequoia's podcast in April 2026, used the phrase every company can now be a mini-AGI. I do not love the grand framing, but there is a practical idea underneath it: agentic workflows change how technical problems get broken down, tested, and shipped.

The useful part is not the slogan. The useful part is the operating pattern: small briefs, specialized agents, explicit evals, and a human review loop that makes the final judgment.

The useful claim

A software project takes inputs: user pain, data, constraints, logs, tickets, screenshots. It turns those inputs into decisions: architecture, UI, tests, deployment shape. Then it produces outputs: code, documentation, runbooks, shipped product.

What changed is that some of the middle work can be delegated to agents. One agent can inspect logs. Another can draft tests. Another can build a UI variant. Another can summarize tradeoffs. None of that removes judgment, but it changes where the builder spends attention.

That is the practical bar: can the system read the context, perform a bounded step, expose its reasoning, and give you something reviewable? In many domains, the answer is already yes.

What it looks like in practice

This is not theoretical. Run parallel agents against tight briefs: Claude Code, Codex, Gemini CLI, Snowflake Coco. Keep the streams bounded, and a pattern shows up quickly.

The brief becomes the unit of work. The better the brief, the better the output. Vague asks produce average code. Concrete asks produce reviewable work.

Parallelism needs clean interfaces. Agents are useful in parallel only when the seams are obvious. Data ingest, UI shell, eval harness, and docs can often move separately. A tangled feature cannot.

Review becomes the bottleneck. The agent can write a lot of code. The scarce skill is knowing what to accept, what to reject, and what to ask for next.

Experiment cost drops. A prototype that used to take a weekend can become an evening. That makes it rational to test more ideas before committing to one.

That is the useful version of the idea. The work changes because the cost of trying, testing, and revising goes down.

What does not change

Three things stay exactly as they were.

The problem still has to matter. A fast build around a weak problem is still a weak product. Agents do not create demand. They only reduce the cost of reaching a working answer.

Taste still matters. When you can produce three variants of a feature in an afternoon, the question is not can I build this. The question is which version is right. Without strong opinions about quality, you ship variations of mediocrity.

Accountability stays human. The agent can generate code, tests, summaries, and traces. The builder still owns the outcome. "The AI did it" is not a reason.

What builders can practice

The skill is concrete.

Write briefs that are small enough to test. Create evals before asking for implementation. Keep a decision log so context survives the session. Review the output like a senior engineer, not like a person impressed that code appeared.

The best prompt is not magic language. It is a clear contract: here is the goal, here are the constraints, here is the input, here is the output, here is how I will know it works.

My pragmatic take

Dorsey's framing is grand. The day-to-day version is more boring and more useful: agentic engineering changes the problem-solving loop. Implementation gets cheaper. Judgment gets more important. The builder who learns to specify, test, and review well gets leverage.

That is the opportunity. Not replacing engineering, but moving more energy into the parts that actually determine quality: problem framing, eval design, architecture, and taste.

The models are good enough to make this worth practicing now.