How to prompt advanced AI models: the Before‑Astra / After‑Astra framework
Giant procedural prompts made sense when the model was the weak link. It isn't anymore.
By Bryan Fikes · Bonsai Marketing Company · September 8, 2026
Video
The companion film is in final review.
It will appear here on release.
We stopped writing instructions. We started writing missions.
For three years, good prompting meant compensating for a model that couldn't hold a whole problem in its head. You supplied the procedure because it couldn't derive one. That was the right move then, and it is the wrong move now.
Every step you prescribe is a step the model can no longer optimize. On a system that can plan, browse, run checks and operate software, a rigid procedure written before anyone looked at the data is a ceiling — not a guardrail. So we invert it: hand over approved knowledge, a clear outcome, real success criteria and hard constraints, then let it choose the path. And then — this is the part people skip — verify what came back.
We taught ourselves to think for the model.
Do this first. Then do this.
Format the output exactly like that.
Never do this — under any circumstances.
Here are nine examples to follow.
Adopt this persona. Use this tone guide.
Here is the checklist. Here is the fallback plan.
It worked. It worked because the model genuinely couldn't carry the problem, so we carried it for them. But look at what that prompt actually is: it is scaffolding for a system that wasn't strong enough to stand on its own. Keep the scaffolding after the building is finished and it stops holding things up. It starts blocking the doors.
The scaffolding became the ceiling.
Published product facts, verified against OpenAI's announcement on 2026-09-08. Everything below is Bonsai Marketing's own operating practice, not an OpenAI recommendation.
You decide the method in advance and encode it. The model executes your plan. Quality is capped by how good your plan was before you saw the data — and by how much of it you remembered to write down.
You decide what "done and correct" means, and supply the knowledge and the guardrails. The model derives the method after looking at the data. Quality is capped by how precisely you defined success — and how honestly you verified the result.
Stop writing instructions. Write a mission.
The business outcome — not the task, and not the method.
The conditions that must be true for this to count as done.
Approved knowledge and verified sources. Gaps get flagged, never filled with invention.
Protect production. Protect secrets. No unsupported claims. Simplest reliable path.
Note what is absent: there is no procedure. No step list, no formatting drill, no worked examples. Those are the parts a capable model should be deriving, not receiving.
ASTRA MISSION OBJECTIVE [the business outcome you want to exist when this is done — not the task, not the method] SUCCESS [the conditions that must be true for this to count as done] - [outcome 1] - [outcome 2] - [outcome 3] AUTHORITATIVE CONTEXT Use approved company/client knowledge and relevant verified sources. Where a fact is not in the approved knowledge, verify it or flag it. Do not fill gaps with plausible invention. CONSTRAINTS Preserve production systems. Do not invent facts, locations, credentials, or results. Protect secrets. Use the simplest reliable path. EXECUTION Own the problem. Choose the best approach. Use tools only where they genuinely help. Do not stop for minor ambiguity — state the assumption and continue. Deliver the completed outcome, not a plan to produce it.
A roofing company in Sonoma County.
Same business, same goal, same model. The only variable is how the work was framed.
- —Research 10 competitors
- —Find 20 keywords
- —Write five city pages
- —Optimize the headings
- —Create the schema
- —Review the Business Profile
- —Build title tags
- —Check mobile
- —Run QA…
Every line is a guess about the right method, written by someone who hasn't looked at the data yet. Why ten competitors? Why five city pages? Because it sounded like enough.
Become the strongest locally relevant roofing search asset in the target county, and generate qualified calls.
Accurate service and city coverage · technically sound local SEO · a real Google Business Profile strategy · strong entity signals for AI search · production-ready pages · verified tracking.
Approved services, service area, proof, offers, reviews, differentiators, verified business facts.
No invented locations. No unsupported claims. No fabricated authority. Nothing destructive in production.
Then you let it determine the execution plan. The plan it builds is usually better than the checklist — because it is built after looking at the data instead of before.
This is the difference between task micromanagement and outcome definition. The first constrains the work to your prior assumptions. The second constrains it to your actual requirements — which is what you wanted to constrain all along. More on how we run this for local businesses: local SEO in Sonoma County.
COMPLETION PASS Verify the work just produced, adversarially. Assume it is wrong. 1. OBJECTIVE — was the stated objective actually achieved? 2. GAPS — what remains incomplete, stubbed, or skipped? 3. FACTUALITY — is every claim supported, or merely plausible? Name any claim you cannot source. 4. IMPLEMENTATION — is it real and running, or described? Distinguish "written" from "verified working". 5. TESTING — were meaningful tests actually run? Show the output. 6. READINESS — is this safe to put in front of a client or in production? Then report, in this shape and nothing longer: STATUS [complete | complete with exceptions | blocked] DELIVERED [what actually exists now] VERIFIED [what was genuinely tested, and how] EXCEPTIONS [what is missing, wrong, or unproven] NEXT BEST ACTION [the single highest-value next move]
Autonomy without verification is another failure mode.
A capable model handed a vague objective will produce something confident, well-structured and completely wrong — and it will look finished. Autonomy raises the ceiling on quality and it raises the cost of an unchecked answer at the same time.
So the verification pass runs separately, adversarially, and assumes the work is wrong until shown otherwise. The two distinctions that catch the most: factual versus plausible, and implemented versus described. Nearly every silent failure we have caught lives in one of those two gaps.
It reports in four lines, and one of them is Exceptions. A pass with an empty exceptions line, every time, means the verification isn't working.
The knowledge base becomes the truth.
The prompt becomes the mission.
- 01Discover
- 02Verify
- 03Structure
- 04Approve
- 05Build
- 06Deploy
- 07Improve
The better the model becomes, the more valuable trusted business knowledge becomes.
This is the counterintuitive part, and it is the whole reason we structured the agency this way. A stronger model does not reduce your need for accurate, approved, structured information about your business. It multiplies it — because the model is now good enough to act on whatever you give it, including the wrong things, quickly and convincingly.
The model supplies reasoning and execution. It cannot supply your real service area, your actual offers, your proof, or which claims you are entitled to make. When reasoning becomes abundant, the scarce input is verified truth about your business. That is what we build first, and it is why the foundation assessment comes before any production work.
The objections worth answering.
Does this mean prompt engineering is dead?
No — it moved. The craft used to live in procedure: the steps, the formatting rules, the examples. On a model that can plan its own approach, the craft lives in the framing instead: how precisely you define the outcome, how well-sourced the knowledge you hand it is, and how honestly you verify what comes back. That is still engineering. It is just pointed at a different part of the problem.
Is a short prompt always better than a long one?
No, and this is the most common misreading. The Before-Astra prompt is often long — the success criteria and the approved knowledge can run for pages. What gets cut is the procedure: the step-by-step method, the formatting drills, the redundant examples. You are trading instructions for context. Length is not the variable; the ratio of context to procedure is.
What actually changed with GPT-6 Astra?
OpenAI released GPT-6 Astra on September 3, 2026, with roughly a million tokens of context and a design aimed at operating software rather than only answering questions — browsing, inspecting screens, running checks, working through multi-step tasks. Those are the published product facts. The prompting framework on this page is not an OpenAI recommendation; it is how Bonsai Marketing has adapted its own workflow to a model with those capabilities.
Isn't giving a model this much autonomy risky?
It is, if you stop there. Autonomy without verification is a new failure mode, not an improvement — a confident, well-formatted, entirely wrong deliverable. That is the whole reason for the After-Astra pass: a separate verification run that asks whether the objective was met, whether claims are factual or merely plausible, whether the implementation is real or described, and whether meaningful tests were actually run. The autonomy is only safe because the verification is not optional.
Why does a knowledge base matter more with a stronger model, not less?
Because a stronger model is better at using whatever you give it — including the wrong things. The model supplies reasoning and execution. It cannot supply your service area, your real offers, your pricing, your proof, or which claims you are legally able to make. When the reasoning gets cheap, the differentiator is the quality of the verified business knowledge feeding it. That is why our sequence is discover, verify, structure, approve, and only then build.
How do I start without rebuilding everything?
Take one task you already delegate to AI and rewrite the prompt once. Delete every step-by-step instruction. Replace them with the objective, the success criteria, the approved facts, and the guardrails. Run it, then run a separate verification pass on the output. Compare that against what your old procedural prompt produced. One task is enough to see whether the pattern holds for your work.
Turn AI from a chatbot into an operating system for your business.
The framework on this page only works on top of verified business knowledge. That is what we build — the approved facts, the structure, and the systems that run on them.