Orchestrating AI is starting to feel like AGI
How I’m connecting research, design, and project files so AI can help carry a decision through the work.
The part that surprised me most about working with AI agents was how much time I had been spending explaining the work before I could do the work.
Copy the text. Find the image. Open the other project. Explain the brand. Find the spreadsheet. Remind the tool what I was trying to accomplish. Then take whatever it produced and move it somewhere useful.
Basic stuff, but there is a lot of it between having an idea and making the thing.
My background is in SEO, design, and digital marketing. That is the angle I am coming from here. What interests me is what happens when an agent can work with the actual files, standards, and research behind a project.
I can point it toward the material itself. The existing page. The approved assets. The brief. The workbook that records the plan.
That feels different.
That is what I mean by orchestrating the work: deciding what needs to happen, giving the agent the material it needs, and checking how that decision carries through the project.
Giving agents useful project context
A website is pages, components, images, styles, data, and decisions. Some decisions are written down. Others are buried in an existing page that already solves a similar problem.
If I am building something new, I may already have most of what I need. A useful layout in another project. The right image in a separate folder. A brief explaining the audience. A planning document recording what the page needs to say.
When those materials are accessible, I can ask an agent to inspect the existing pattern, use the approved material, follow the brief, and prepare the change.
I spend less time describing a hypothetical version of something I already have.
The context behind a project task
Of course, a folder full of files is not automatically good context. I still need to identify which material is current, what the agent should use, and where the instructions live. Access and instruction loading are separate choices; Anthropic’s project-context documentation explains that distinction.
The project can provide context. Someone still has to make that context useful.
Applying an SEO recommendation across the project
SEO makes this especially clear because a recommendation usually needs to travel.
Take a generic service-page refresh. The page gets impressions, but the content is vague about who the service is for. That is something worth investigating. It is not enough evidence, by itself, to know what to change.
I would look at the queries, the page, the audience, and what the business actually offers. If the problem is a mismatch between the page and the intent, that decision affects several parts of the work:
- The title and heading need to describe the same service clearly.
- The content needs to answer the questions that matter to that audience.
- The page layout needs to make those answers easy to find.
- The planning record needs to explain what changed and why.
An agent can help carry that direction through the relevant files. The useful output is a proposed page change, an updated record, and a short explanation I can inspect together.
What changes in a service-page refresh
The same pattern applies to other SEO work. A content inventory can become a set of page briefs. A migration plan can connect old URLs, proposed destinations, and redirect checks. A reporting task can bring the evidence together before I decide what deserves attention.
Those are different tasks. They need different instructions. But each benefits from keeping the research, implementation, and record of the work close together.
The mechanics still matter. Google’s guidance on descriptive titles and redirects is useful reference material. Changing a title does not let me choose exactly what Google will display. Filling out a redirect map does not prove the redirects work.
And files changed during one task do not stay synchronized forever. I need to know which record is authoritative and when it should be updated. Otherwise, I have made several versions of the same disagreement.
Knowing what to ask still matters
My experience does not become irrelevant because an agent can edit a title or build a page.
It helps me judge whether the title describes the right thing. Whether the page addresses the audience. Whether a design choice improves the experience or merely adds movement. Whether the research is relevant to the actual goal.
A tool can implement the wrong idea very efficiently.
I still have to recognize the wrong idea.
Consider two requests: “Improve the SEO” and “Review this service page against these queries, explain the gaps, and prepare changes using the site’s existing layout and voice.” The second gives me something I can evaluate.
That is why I am less interested in a perfect prompt than a clear brief, useful source material, and a standard I understand well enough to apply.
The agent can carry a decision further through the project. It does not relieve me of making a good decision.
Reviewing the changes
I want to understand what happened. What did it read? What changed? Which assumptions did it make? Did the important parts still work?
For a service-page refresh, that means reading the copy, checking the layout on a phone, and confirming that the form or next step still works. For a migration, it means checking the proposed destinations and testing redirects. A polished spreadsheet is only one part of that job.
The scope of the task should determine the amount of freedom I give it. A draft brief and a change to a live website deserve different levels of scrutiny.
Written instructions help describe the expected behavior. They are not enforced permissions or an approval gate. Those controls need to be configured separately, as the security documentation makes clear.
I want to spend less time moving the work between places and more time judging the work itself.
Building a workflow worth repeating
Once the material is connected, it is natural to start thinking about repetition.
Could an agent regularly compare a small set of pages with a defined standard? Gather the relevant evidence? Prepare a brief when something looks worth investigating?
That is the experiment I am interested in. Start with a bounded task whose output I know how to assess. Get that working. Then decide whether it deserves to run regularly.
A repeatable workflow with human review
- Gather evidenceThe agent collects the agreed inputs.
- Choose the taskI decide what matters and define the brief.
- Prepare the workThe agent proposes changes and records its assumptions.
- Review and releaseI check the result and decide what goes live.
More frequent output is not automatically more useful output. If I cannot explain why a proposed change matters, running the task every morning mostly gives me a longer review queue.
For SEO, that also means measuring honestly. A completed brief is an output. A released page is an output. What happens to search visibility, useful visits, and inquiries is a separate question.
I want to see the result. I also want to be careful about what I claim caused it.
Where I want to take this
I understand the temptation to reach for AGI as a description of the feeling. I have felt it myself.
But I do not need to settle that label to take the practical change seriously. A tool that works across the actual project changes how far I can carry an idea before the context gets lost.
There is still friction. The output still needs checking. Some tasks are easier to do directly. None of that cancels the useful part.
I can spend more of my attention deciding what should happen, and less of it rebuilding the explanation in every place the work needs to go.
The brief travels with the work. I stay responsible for the direction.
