<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>AstroDev</title>
    <link>https://astrodev.carlosarias.com/</link>
    <description>A sandbox instance of the AstroAgent platform for testing builds, agents, and deploys.</description>
    <language>en-us</language>
    <item>
      <title>Technical SEO Testing: Design an Experiment You Can Defend</title>
      <link>https://astrodev.carlosarias.com/blog/technical-seo-experiment-design</link>
      <guid isPermaLink="true">https://astrodev.carlosarias.com/blog/technical-seo-experiment-design</guid>
      <pubDate>Thu, 13 Aug 2026 00:00:00 GMT</pubDate>
      <description>Technical SEO testing done right: isolate one variable, run a control group, and prove your change moved rankings instead of a Google update.</description>
      <content:encoded><![CDATA[Technical SEO testing is the discipline of shipping a change so that you can prove it moved rankings, not just watch numbers move near it. The question every developer should be able to answer after a template or internal-linking change is blunt: did my change cause this, or did a Google core update, a seasonal swing, or a competitor's move happen to land in the same window? You defend the answer the way you defend any experiment. Isolate one variable, hold everything else stable, keep a comparable set of pages untouched as a control, and know in advance where the impact will surface. Everything below is how to build that experiment before you deploy it.
Why a before-and-after comparison is not evidence

A before-and-after SEO comparison feels like proof and almost never is. Search performance never changes in isolation: demand shifts, competitors move, other changes overlap the same period, and Google updates roll out on top of all of it (Search Engine Land, 2026). Any pre/post window is competing with every one of those forces for credit.

The algorithm-update problem alone is enough to invalidate most casual tests. Google's core updates are announced through its Search Status Dashboard with an explicit warning that the rollout may take up to two weeks, and recent ones have run 12 to 18 days (Search Engine Land, May 2026). Ship a change, watch traffic rise, and if a core update was rolling during that fortnight you have no way to separate your work from Google's from a single time series. A before-and-after chart records that something changed. It cannot tell you what.
Technical SEO testing starts with a hypothesis, not a change

Good SEO experiment design starts with a falsifiable prediction, written down before anything ships. State the metric, the direction, the magnitude, and the timeframe. "Adding contextual internal links from category hubs to product pages will lift impressions for those product pages by a measurable margin within four weeks" is a hypothesis. "Let's add some internal links and see" is a deploy.

The test of a real hypothesis is whether you can name the result that would prove you wrong. If any outcome can be spun as success, you have not designed an experiment, and you will read random noise as vindication. Decide the success threshold and the measurement window up front, in writing, so you cannot move the goalposts once the data lands. This is the same discipline that separates a controlled result from a story told after the fact.
Treatment and control groups without a split-testing platform

The gold standard is a split test: apply the change to a randomly assigned treatment set and leave a comparable control set unchanged, so external forces hit both groups equally and cancel out. Enterprise platforms do exactly this. SearchPilot, for instance, runs a causal model built on Google's own paper, "Inferring Causal Impact Using Bayesian Structural Time Series," forecasting what the treated pages would have done untouched and measuring the gap against reality (SearchPilot, 2026). That forecast-versus-actual framing is the whole game: it answers the causal question a raw before-and-after cannot.

Most teams do not have that infrastructure, and the honest fallback is matched page groups. Pick two sets of pages that are alike in template, content type, historical traffic, and seasonality; change one set, hold the other. It is less controlled than a true random split, but on a real site with a handful of page types it is often more realistic and less noisy (Search Engine Land, 2026). Sample size is where these tests quietly die: as a working rule you want a large group, on the order of a few hundred similar pages per group, and enough volume, at least 30,000 organic sessions a month across the test set, to detect a genuine effect at 95% confidence within a few weeks (Search Atlas, 2026). Below that, small samples do not fail loudly; they hand you noise you will misread as signal.

A control group only controls if it is genuinely comparable and genuinely untouched:
Same template and content type as the treatment pages, so a rendering or crawl difference is not baked in from the start
Comparable historical traffic and seasonality, matched on past performance rather than picked at random from a small pool
No leakage between groups, meaning the control is not internally linked to or from the treatment set in a way that spreads the change you are trying to isolate
A worked example: an internal linking test

Make it concrete with an internal linking test, one of the most common template changes a developer ships. Hypothesis: adding a "related products" module that links three contextually relevant items will increase impressions and clicks for the linked pages within four weeks. Treatment: 200 matched product pages get the module. Control: 200 matched product pages, same template, similar traffic, keep the module withheld for the test window.

The guardrail that makes this defensible is the leakage rule. If your treatment pages link into the control pages, you have handed the control the very signal you are testing, and both groups drift together. Keep the new links pointing only within the treatment cohort, or to pages outside both groups entirely. This is precisely where internal linking stops being an editorial nicety and becomes an engineering constraint, which is the same lens we brought to outbound linking as an authority signal: the behavior lives in a template, so its blast radius is a template decision, not a per-page one.
Where the impact actually surfaces

Here is the part an engineer's instinct gets right and a marketer's dashboard gets wrong: a technical change propagates in stages, and rankings are the last thing to move. A successful test typically shows up first in server logs and crawl rate, then in indexing, and only later in rankings and traffic (Search Engine Land, 2026). Measure only rankings at day three, see nothing, and you may kill a test that simply had not propagated yet.

So instrument the leading indicators in order. Watch crawl frequency and the crawl budget spent on the treatment set in your log files, confirm the changed pages are getting re-fetched and re-indexed, then let ranking and traffic accumulate over the full measurement window you committed to earlier. Combining signals also protects you from the reverse error: traffic can wobble for reasons unconnected to your change, so a single metric moving is weaker evidence than crawl, index, and rank moving together in the direction you predicted. Rank tracking in isolation is an unreliable narrator, a point that compounds now that AI surfaces sit above the results, which we covered in AI search visibility versus organic rankings.
Deployment isolation: hold the template stable

The single most common way an SEO test gets poisoned is a second change riding along in the same release. If you are testing an internal-linking module, do not also refactor the header, chase a Core Web Vitals number, or rewrite canonical logic in the same deploy. The moment two variables ship together, you can prove that something worked and never which thing. One variable per experiment is not a nicety; it is the entire basis for attribution.

Treat the test window as a template freeze. Version the template, gate the change behind a feature flag scoped to the treatment cohort only, and hold unrelated edits to the shared layout until the experiment closes. Phased rollouts fit this cleanly: introduce the change to one template, market, or category while comparable sections stay put, and those untouched sections serve as a temporary control while limiting deployment risk (Search Engine Land, 2026). The discipline is ordinary release engineering pointed at a search question: isolate the change, keep a clean comparison, and do not let unrelated work contaminate the result.

That is also why encoding these rules once, in the pipeline, beats trusting each deploy to remember them. A test that holds the template stable, keeps a matched control, and watches crawl before rank is one you can put in front of a client and defend line by line. If you are standing up a content platform and want experiment hygiene built into how pages ship rather than bolted on after, the rest of our engineering guides go deeper on the build patterns behind it.]]></content:encoded>
    </item>
    <item>
      <title>Outbound Linking Strategy for AI Search: Give to Get</title>
      <link>https://astrodev.carlosarias.com/blog/outbound-linking-authority-ai-search</link>
      <guid isPermaLink="true">https://astrodev.carlosarias.com/blog/outbound-linking-authority-ai-search</guid>
      <pubDate>Wed, 12 Aug 2026 00:00:00 GMT</pubDate>
      <description>An outbound linking strategy for AI search signals authority by joining the web's citation graph — stingy linking quietly undermines it.</description>
      <content:encoded><![CDATA[Your outbound linking strategy for AI search is an authority signal, not a leak. If your pages name their sources in prose but refuse to link them — to keep visitors on-site or hoard "link equity" — you are opting out of the exact citation behavior AI systems reward. Generous, well-marked outbound links tell both crawlers and language models that your content is verifiable and connected to trusted work. Stingy linking tells them the opposite, quietly, on every page you ship.

This matters more now than it did in the ten-blue-links era. Answer engines increasingly decide what to cite by reading the web as a graph of who vouches for whom, and a page that vouches for no one is a weak node in that graph.
The hypocrisy that gives the game away

There is a common pattern worth naming because so many sites do it. A page will write out a source in plain text — "according to Pew Research" or "a Stanford study found" — while deliberately leaving that reference unlinked. The claim borrows the source's credibility; the link that would let a reader verify it is withheld, usually to avoid "leaking" equity or losing the click.

This is the argument at the center of Andrew Boyd's piece, You Can't Demand the Click If You Won't Give the Link: publishers now loudly demand that AI platforms cite and link back to them, while routinely referencing other people's data and expertise without a single clickable link in return. You cannot ask AI systems to support the open web while refusing to participate in it yourself. Links are how a reader inspects a claim, recognizes original work, and finds the people doing real research. A page that names sources but never links them is performing citation without doing it.

The uncomfortable part for developers is that this is rarely a writer's choice. It is usually a template decision — a default set once, in a component or a house style, then repeated across thousands of pages. Which means it can be fixed once, in the same place.
Why your outbound linking strategy for AI search reads as trust

Search engines have treated outbound links as a signal for a long time, and the evidence is unusually clean for SEO. In a controlled experiment, Reboot Online built ten near-identical pages about a fabricated compound; five linked out to authoritative domains like Oxford and Cambridge, five did not. The pages that linked out ranked higher, the result held on a repeat run, and Rand Fishkin reviewed it as "as close to 'proof' as we get in the SEO world." Linking to credible sources marks your content as researched and topically connected, which is precisely what a relevance system wants to see.

AI answer engines extend this logic rather than discard it. During inference a model does not crawl your outbound links, so the mechanism is different: links help establish that your claims are verifiable across other sources and that your page sits inside a trusted authority cluster rather than off on its own. As AirOps puts it, outbound links do not make your content more extractable, but they do influence whether an engine cites you over an equally readable competitor. Membership in the citation graph is the differentiator when two pages are otherwise tied.

The "give to get" framing is not sentimentality about the open web. It is where the traffic went. In a Pew Research Center analysis of real browsing behavior, users clicked a link inside an AI summary in just 1% of visits where a summary appeared (Pew Research Center, July 2025). Being the cited source inside the answer is now the prize, and citation flows toward pages that behave like citing pages. We covered the broader shift in AI search visibility versus organic rankings; outbound linking is one of the levers that decides which side of that gap a page lands on.
Template-level decisions a developer can standardize

The reason this belongs to engineering, not editorial, is that outbound linking done by hand is inconsistent by nature. Encode it once and every page inherits the behavior. Four decisions are worth standardizing at the template layer.
Link every named source. If a source appears in prose, it gets a link. Make this a lint rule or an editorial gate, not a writer's discretion. The Search Engine Land external links guide treats relevant outbound links to authoritative sources as a baseline trust and context signal, not an optional extra.
Mark up external citations honestly. Use rel="noopener" for security on target="_blank" links, and reserve rel="nofollow" for genuinely untrusted or paid links rather than slapping it on every external link to hoard equity. Where you quote a source, the HTML cite attribute and  element make the reference machine-legible.
Open in the same tab by default. Forcing new tabs is a retention tactic that fights the reader. If your fear is losing the visitor, the honest fix is better content, not a trapped browser session.
Set a floor, not a ceiling. A researched long-form piece with zero outbound links should fail review. One or two solid references per major section is a reasonable default; the goal is genuine sourcing, not link stuffing.

This is the same principle behind encoding any quality rule into the pipeline rather than hoping each writer remembers it. As we argued in how context configuration shapes AI agent output, a rule that lives in the template or the role prompt applies uniformly across every run, while a rule that lives in someone's head applies unevenly and decays. Outbound linking is a textbook case: the correct behavior is simple, the discipline to apply it on every page is not, and a template supplies the discipline for free.
Why this compounds in AI-indexed content graphs

The payoff is not per-page; it accrues to the site over time. Each generously linked article is one more well-connected node, and AI systems building their internal picture of the web are reading those connections in aggregate. A site that consistently links out to primary sources reads as a hub that participates in the citation economy. A site that consistently withholds links reads as a dead end that takes credibility without extending it.

That reputation is sticky. Models and crawlers form a durable impression of a domain from the pattern across all its pages, so today's linking defaults quietly shape whether you are treated as a citable authority a year from now. The compounding runs in the wrong direction too: a template that strips or nofollows every external link does not sabotage one article, it sets the posture for the entire archive. Because the behavior is set in a template, the fix is also archive-wide — change the default and every future page, and often every rebuilt one, inherits the corrected behavior at once.

None of this replaces the fundamentals. You still need content worth citing, clean structure, and pages a model can chunk and quote. Outbound linking is the signal that decides between otherwise-equal pages, and it is one of the cheapest authority signals to get right because it is a one-time engineering decision rather than an ongoing editorial burden.

If you are standing up a content pipeline and want this baked in from the first post, make "link every named source" a gate rather than a guideline. For the wider set of AI-search and authority tactics this sits inside, browse the rest of our guides on AI search and content authority. The sites that treat generous, well-marked outbound linking as default behavior are the ones AI systems will keep citing, precisely because they are the ones still holding the web together.]]></content:encoded>
    </item>
    <item>
      <title>AI Search Visibility vs Organic Rankings: Ranked #1, Unseen</title>
      <link>https://astrodev.carlosarias.com/blog/ai-search-visibility-beyond-organic-rank</link>
      <guid isPermaLink="true">https://astrodev.carlosarias.com/blog/ai-search-visibility-beyond-organic-rank</guid>
      <pubDate>Mon, 10 Aug 2026 00:00:00 GMT</pubDate>
      <description>AI search visibility and organic rankings have split apart: a #1 ranking can sit below AI Overviews, ads, and SERP features before anyone scrolls.</description>
      <content:encoded><![CDATA[The gap between ai search visibility and organic rankings is now the most important thing to understand about shipping client sites: earning the #1 organic position no longer guarantees anyone sees it. A page can rank first and still open below an AI Overview, paid ads, and a stack of SERP features that fill the entire first screen. Ranking measures where you sit in a list. Visibility measures whether a human ever looks at that list. In 2026 those two numbers have come apart, and rank-tracking tools still report the first while your traffic reflects the second.
The ranking vs visibility gap is now measurable

The clearest evidence comes from click behavior when Google shows an AI-generated answer. In a Pew Research Center analysis of real browsing data, users clicked a traditional search result in only 8% of visits where an AI summary appeared, versus 15% of visits without one, and just 1% clicked a link inside the summary itself (Pew Research Center, July 2025). Users were also more likely to end their session on a page with a summary, 26% versus 16%.

Zoom out and the pattern holds. Roughly two-thirds of Google searches ended without any click as of early 2026, a figure that has climbed steadily for years (Search Engine Land, 2026). A separate controlled analysis isolated the AI Overview effect directly: when an overview was present, outbound organic clicks fell 39.8% (PPC Land, 2026). This is the zero-click search traffic problem stated plainly. Your rank did not move. The clicks did.
What sits above your #1 result

The rank-first position is real. It is just no longer the top of the page. On a modern results screen, an organic #1 can sit beneath several layers that push it down the page:
An AI Overview that answers the query in place, often citing sources without sending the click
Paid ads occupying the first two to four slots
Rich features such as People Also Ask, video carousels, local packs, and shopping units

Each layer pushes the first organic result further down. On a phone, that can mean two or three full scrolls before an organic link appears at all. This is the ranking vs visibility gap: the position is earned, but the real estate above it has been sold or automated away. As one analysis put it, your rankings are not telling you what your customers actually see (Search Engine Land, 2026).
AI search visibility vs organic rankings: the technical levers

Here is the part developers can actually act on. Whether a page gets lifted into an AI Overview or buried below it is not random, and it is not purely a function of rank. It is a function of how machine-readable and specific your content is. Three levers matter most.

First, structured data. Schema markup turns plain prose into explicitly labeled entities an AI system can extract and cite with confidence, rather than text it has to infer meaning from. Google's own documentation confirms structured data is eligible to feed rich results and its generative surfaces (Google Search Central). The link to AI citations specifically is more contested and worth stating honestly: pages cited by AI systems are roughly three times more likely to carry JSON-LD, but a controlled Ahrefs experiment that tracked 1,885 pages after they added schema found no meaningful citation uplift against matched control pages — evidence that markup correlates with, more than causes, being cited (Ahrefs, 2026). Treat schema as table stakes for machine readability and entity resolution, not a standalone growth lever. For most client sites this means shipping Article, FAQPage, BreadcrumbList, and Organization markup as a baseline, not an afterthought.

Second, heading hierarchy. AI systems chunk pages into passages before deciding what to quote. A clean, logical h1 to h2 to h3 structure gives the model clear passage boundaries and tells it which question each section answers. A flat wall of text or heading levels used for styling gives it nothing to grab.

Third, content specificity. Overviews tend to lift the sentence that answers a question directly, with a concrete number, definition, or step. Vague, hedged, "it depends" prose rarely gets quoted because there is nothing extractable in it. The pages that surface are the ones that state the answer plainly in the first line of a section, then support it.

These levers compound with, rather than replace, ranking. You still need to rank to be eligible. But among eligible pages, the structured and specific ones are the ones that get seen.
What this means for client sites you ship

Rank tracking alone will now mislead you and your clients. A dashboard showing "position 1" next to falling sessions is not a contradiction to be explained away; it is the expected outcome of an AI Overview answering the query inline before the ranked list ever gets a look. The honest metrics are impressions-to-clicks, presence in AI Overview citations, and share of the visible first screen, not the ordinal rank on its own.

The practical build response is to make every page maximally quotable by machines. That is largely a front-end and content-modeling problem, which is where an automated pipeline earns its keep. Consistent schema, disciplined heading structure, and answer-first writing are exactly the kind of rules you can encode once and apply to every article, rather than hoping each writer remembers them. How much of that quality is set before a single word is written is a point we made in how context shapes AI agent output: the configuration layer decides whether a page ships extractable or generic. If you are standing up a new site and want the baseline in place from the first post, the platform quickstart covers the initial setup, and the rest of our engineering write-ups go deeper on the build patterns behind it.

Ranking first was always a proxy for being seen. That proxy has broken. Build for the page a human and a model actually read, measure visibility instead of position, and treat every organic result as something that has to earn its way above the fold rather than assume the fold moved for it.]]></content:encoded>
    </item>
    <item>
      <title>AI Agent Context Configuration: How It Shapes Output Quality</title>
      <link>https://astrodev.carlosarias.com/blog/context-shapes-ai-agent-output</link>
      <guid isPermaLink="true">https://astrodev.carlosarias.com/blog/context-shapes-ai-agent-output</guid>
      <pubDate>Sun, 09 Aug 2026 00:00:00 GMT</pubDate>
      <description>AI agent context configuration — not the task prompt — is the primary lever for output quality. Mapped to AstroAgent's real artifacts.</description>
      <content:encoded><![CDATA[In a 2025 experiment published on Search Engine Land, the same strategic prompt was submitted to ChatGPT, Claude, and Gemini — each time with progressively richer business context about a regional HVAC company. With minimal context, each model diverged: one leaned toward audience discovery, another toward technical optimization, a third toward a governance-driven phased rollout. With full context — budget constraints, seasonal demand patterns, audience specifics — all three converged on recommendations that were specific, actionable, and directly relevant to the company's situation.

The implication for developers deploying AI agents is direct: ai agent context configuration is the primary variable controlling output quality, not the task prompt. The prompt tells the model what to do. Context tells it who it's doing it for, under what constraints, and with what priorities. Without that layer, the model fills the gaps with assumptions — and assumptions produce generic output.

This guide maps each context layer to the specific configuration artifacts in AstroAgent, showing what "richer context" looks like in a real deployment.
What the Search Engine Land Experiment Reveals

The experiment's design was simple: one assignment, three models, three context levels. At the minimal end, each model received only the task. At the maximum, the brief included the company's geographic focus, budget constraints, seasonal demand curves, and target audience specifics.

The divergence at the minimal end wasn't a failure of any individual model — each produced coherent output. The problem was that each model made different assumptions about what the business cared about, leading to recommendations that contradicted each other. A practitioner reading three such outputs would need to adjudicate between them, which is exactly the extra work that good context is supposed to eliminate.

With richer context, the recommendations converged and became substantially more actionable. The models weren't producing identical text — they were reasoning from the same business reality, and that alignment showed.

This pattern generalizes. Context engineering — the discipline of designing what information a model receives before it processes a task — has emerged as the production-relevant successor to prompt engineering. Where prompt engineering optimizes the instruction, context engineering optimizes the model's starting knowledge. Gartner's Innovation Insight on Context Engineering identified it as a key shift in AI application development — one of the more significant practitioner-facing findings from the analyst community through 2025 and into 2026.
AI Agent Context Configuration in AstroAgent: Three Layers

AstroAgent structures context across three distinct artifacts, each serving a different scope: identity, role, and operational parameters. Understanding which layer to modify — and why — is the practical translation of the SEL experiment's finding.
Identity: site.config.json

The highest-level context layer is business identity. site.config.json holds the fields that define who the site is and who it's for:

json
{
  "name": "AstroDev",
  "topic": "web development and the AstroAgent platform",
  "audience": "developers evaluating the platform",
  "author": {
    "name": "Carlos Arias",
    "longBio": "Carlos Arias builds AstroAgent, a platform where autonomous agents research, write, design, and QA a website end to end.",
    "jobTitle": "Founder & Engineer"
  }
}

Running configure.mjs stamps these values into the {{BUSINESS_DNA}} injection that appears in every content agent's system prompt. Every agent — content writer, researcher, page planner — sees the same identity layer before it processes a task.

The fields with the most leverage on output quality:
topic scopes what the researcher proposes and what the writer treats as in-bounds. Without it, agents fill in a subject area that may be technically coherent but editorially diffuse.
audience shifts register, assumed knowledge level, and decision frame. "Developers evaluating the platform" is a materially different instruction than "readers interested in AI."
author.longBio is the EEAT anchor. A bio that establishes domain expertise gives the writer a specific credibility frame; an empty bio means expertise is unspecified, and the agent writes accordingly.

Every field left blank is an assumption the model makes on your behalf.

If you're setting up an AstroAgent instance for the first time, the platform quickstart walks through the initial configuration steps before you reach this layer.
Role: agents/prompts/

The second layer is agent-level role context. Each agent carries a system prompt under agents/prompts/, defining scope, voice, and decision rules. The content-writer's system prompt begins:

You are a senior SEO/EEAT writer for {{SITENAME}} ({{SITEHOST}}){{AUTHORROLESUFFIX}}.
Write ONE article for {{AUDIENCE}} about {{TOPIC}}.

The role isn't cosmetic. It changes which decisions the model makes autonomously and which it defers. A writer told it is a "senior SEO/EEAT writer" for a developer-focused platform applies different citation standards, heading structure, and voice calibration than a writer with no role context at all.

AstroAgent ships neutral seed prompts from the engine at /www/astroengine. Each client repo keeps tuned copies in its own agents/prompts/, which take precedence over the engine seeds. The architecture is intentional: the engine knows how to run the pipeline; only the client configuration tells it what the site sounds like and what it will not publish.

This is where business-specific nuance belongs — content exclusions, citation requirements, voice register, how to handle contested claims, which secondary keywords to surface. Two or three specific sentences added to the role prompt here produce a more reliable change in output quality than equivalent effort spent on individual task prompts. The role prompt is per-agent; the identity layer is per-site. Both matter, and neither substitutes for the other.
Operational: agents/config.json

The third layer is operational configuration. agents/config.json carries the settings that govern runtime behavior: model assignments, SEO gate threshold, publishing rules, and editorial content mix.

json
"seo": {
  "minScore": 85,
  "blockApproveOnFail": true,
  "autoRevise": true,
  "maxReviseAttempts": 3
}

These parameters matter for a specific reason: they make quality criteria machine-readable. An agent configured with autoRevise: true and minScore: 85 will run the writer and SEO reviewer in a feedback loop rather than publishing a below-threshold draft. The model knows it's being graded and knows the passing mark — and that awareness influences how it approaches the task.

That explicit quality loop is not achievable through task-prompt instructions alone. "Write a high-quality article" gives the model no actionable target. An integer threshold does.

For a look at how the content pipeline uses this operational context during a writing run — from calendar drain to SEO gate to auto-publish — see how AstroAgent's content pipeline works.
What Richer Context Actually Changes

The SEL experiment demonstrated that enrichment produces convergence: models stop guessing and start reasoning from a shared business reality. The same pattern is observable in AstroAgent deployments when comparing minimal versus full configuration.

A content agent with minimal configuration — site name and URL, nothing more:
Proposes generic article topics ("5 Ways AI Can Help Your Business")
Writes in a neutral, category-agnostic voice that fits no reader precisely
Produces EEAT signals that are either absent or fabricated from the model's general training

The same agent after full configuration — completed site.config.json, tuned role prompt, explicit quality gate:
Proposes topics calibrated to the audience's decision context and prior knowledge
Adopts voice and register specific to the author's domain and the reader's frame
Anchors EEAT signals to the author's actual expertise, as declared in author.longBio

The task prompt is identical in both cases. "Write a 1,500-word guide on context configuration" is the same instruction either way. What changes is everything the agent knows before it starts writing.
Practical Steps for Configuring AI Agent Context

The configuration changes that produce the largest quality gains, in order of impact:
Complete site.config.json fully. Every empty field becomes an assumption. The audience, topic, description, and author.longBio fields inject directly into every agent's system prompt via {{BUSINESS_DNA}} and have outsized per-field impact.
Tune agents/prompts/ for your site, not just the engine's seeds. The seeds are correct but generic. Two or three specific sentences about content scope, voice register, or citation standards produce reliable changes in output tone and depth — changes that individual task prompts cannot maintain consistently across runs.
Set an explicit quality gate in agents/config.json. A numeric minScore threshold paired with autoRevise: true creates a self-correcting loop. The instruction "be thorough" cannot replicate what a machine-readable quality target does.
Be specific about audience. "Developers" is a category. "Developers evaluating whether AstroAgent is the right platform for an autonomous content pipeline" is a decision frame the model can reason against when choosing topics, examples, and depth of coverage.

The SEL experiment's finding generalizes: the prompt tells the model what to do; context tells it who it's doing it for. For AstroAgent deployments, completing the configuration layer — identity in site.config.json, role in agents/prompts/, operational parameters in agents/config.json — is not a one-time setup step. It is the mechanism through which the platform understands the business. Agents given rich, accurate context converge on useful output; agents given sparse context converge on assumptions, and assumptions produce work you have to redo.]]></content:encoded>
    </item>
    <item>
      <title>Welcome to your new site</title>
      <link>https://astrodev.carlosarias.com/blog/welcome</link>
      <guid isPermaLink="true">https://astrodev.carlosarias.com/blog/welcome</guid>
      <pubDate>Thu, 01 Jan 2026 00:00:00 GMT</pubDate>
      <description>A sample post so your blog builds out of the box. Edit or delete it once you add real content.</description>
      <content:encoded><![CDATA[This is a sample post included with the SeedProject base. It exists so the
blog, homepage, RSS feed, and sitemap all build before you've written anything.
Getting started
Edit site.config.json at the repo root with your site's name, URL, and author.
Run node scripts/configure.mjs to stamp that identity across the theme and engines.
Replace this post with your own content under app/src/content/blog/.

Each post is a folder with an index.mdx file and a cover image, using the
frontmatter fields defined in app/src/content.config.js.]]></content:encoded>
    </item>
  </channel>
</rss>