AI Agents Meet Real Estate Media: Preparing for the Astra Era

The Shift: From Models That Describe Software to Agents That Operate It

Until recently, an AI model's relationship with your property software was advisory. It could tell you what to write in the CRM. It could not open the CRM.

That boundary moved in September 2026. OpenAI's GPT-6 Astra, released on 3 September, is built around computer use — the claim that anything you can do on a computer, it can do for you — and it scores 72.6% on the OSWorld 2.0 computer-use benchmark, averaging roughly 40 minutes per task. Google's separately named Project Astra, a DeepMind research prototype available to trusted testers, points at the same destination from a different direction. The direction of travel across the industry is agents that act.

For property media specifically, this changes who pushes the buttons. A listing shoot has always been a sequence of software operations: upload, select, stage, enhance, convert, label, publish. Those operations are now automatable end to end, which raises a design question most proptech teams have not answered yet — what does your stack need to look like for an agent to drive it safely?

What an Agent-Driven Media Pipeline Looks Like

Concretely, here is the loop an agent runs for one listing:

Step	What the agent does	What it calls
1. Intake	Reads the new listing record, pulls the photo set	Your CRM or DAM
2. Triage	Sorts photos: stage, enhance, re-shoot, discard	Vision-language reasoning
3. Brief	Decides room type, style and target buyer per photo	Its own reasoning, plus your style guide
4. Render	Submits one job per photo	An image API
5. Wait	Receives webhook callbacks, or polls	The same API
6. Verify	Compares output against source for structural drift	Vision-language reasoning
7. Publish	Writes results back, applies disclosure labels	Your CRM and portal feed
8. Report	Logs cost, failures, images charged	Your accounting

Steps 2, 3, 6 and 8 are where an agentic model genuinely earns its keep. Step 4 is where it hands off, because agentic models do not render images — an important limitation covered in more detail in "Can GPT-6 Astra Do Virtual Staging?".

The important architectural point: the agent should call an API, not click through a web app. Computer use is a compatibility layer for software that has no API. When an API exists, using it is faster, cheaper, deterministic, and — the part that matters at 3am — debuggable.

Worked Example: An Agent Staging a Listing Through an Image API

This example uses the Roomagen API because we can document its exact shape; the pattern generalizes to any job-based image API.

Step 1 — the agent submits one job per photo. Authentication is a single header. Every job is one image in, one image out, charged immediately.

curl -X POST https://api.roomagen.com/api/v1/jobs \
  -H "X-Api-Key: rmg_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: listing-8842-photo-03" \
  -d '{
    "tool": "virtual-staging",
    "image_url": "https://cdn.yourapp.com/listings/8842/photo-03.jpg",
    "options": { "style": "scandinavian", "roomType": "living-room" },
    "webhook_url": "https://yourapp.com/hooks/roomagen"
  }'

The response returns before generation finishes:

{
  "job_id": "3f1c9d4e-5b2a-4c8e-9f10-7d6a2b3c4e5f",
  "status": "processing",
  "images_charged": 1
}

Three details matter more for an agent than for a human integrator:

• Idempotency-Key is the safety rail. An agent that loses its place and retries will otherwise pay twice. With a stable key derived from your own record — listing ID plus photo ID — a replay re-returns the original job instead of creating a new one.
• images_charged is returned on creation, so the agent can account for spend in the same turn it spends it, rather than reconciling later.
• tool is just a slug. The same call shape runs day-to-dusk conversion, item removal or image enhancement; GET /api/v1/tools returns the authoritative list with each tool's cost in images. An agent should fetch that list rather than hard-coding slugs it might hallucinate.

Step 2 — the agent receives the result by webhook. When the job finishes, the API POSTs the completed job to your endpoint, with an event field added:

{
  "job_id": "3f1c9d4e-5b2a-4c8e-9f10-7d6a2b3c4e5f",
  "tool": "virtual-staging",
  "status": "completed",
  "images_charged": 1,
  "result_urls": ["https://api.roomagen.com/api/uploads/9c2f7a10-render.jpg"],
  "error": null,
  "created_at": "2026-09-06T09:14:02.114Z",
  "completed_at": "2026-09-06T09:14:39.902Z",
  "processing_ms": 37788,
  "event": "job.completed"
}

Verify the signature before you trust a byte of it. The delivery carries X-Roomagen-Event, X-Roomagen-Timestamp and X-Roomagen-Signature: v1=<hex>, where the digest is an HMAC-SHA256 over {timestamp}.{raw body} using your whsec_ secret:

const crypto = require("crypto");

function verify(rawBody, headers, secret) {
  const ts = headers["x-roomagen-timestamp"];
  const expected =
    "v1=" + crypto.createHmac("sha256", secret).update(`${ts}.${rawBody}`).digest("hex");
  const got = headers["x-roomagen-signature"];
  if (got.length !== expected.length) return false;
  if (!crypto.timingSafeEqual(Buffer.from(got), Buffer.from(expected))) return false;
  return Math.abs(Date.now() / 1000 - Number(ts)) < 300;
}

Compute the digest over the raw body bytes, not re-serialized JSON, and reject timestamps older than about five minutes.

Step 3 — polling as the fallback. Webhooks fail; agents that depend on them exclusively stall silently. GET /api/v1/jobs/{id} returns the same object, so a supervisor loop can reconcile anything that has been processing too long:

async function waitForJob(jobId) {
  for (;;) {
    const res = await fetch(`https://api.roomagen.com/api/v1/jobs/${jobId}`, {
      headers: { "X-Api-Key": process.env.ROOMAGEN_API_KEY },
    });
    const job = await res.json();
    if (job.status !== "processing") return job;
    await new Promise((r) => setTimeout(r, 3000));
  }
}

Typical completion is 20–60 seconds, so poll every 2–5 seconds and treat anything past a few minutes as stuck rather than slow.

Step 4 — errors the agent must branch on. Every non-2xx response is { "error": { "code", "message", "doc_url" } }. Branch on code, never on message — human-facing text changes, codes do not. The ones an autonomous run will actually meet: invalid_tool (a hallucinated slug), invalid_image and image_fetch_failed (a source URL your CDN would not serve), webhook_url_rejected (a private or loopback destination), payload_too_large, insufficient credits, and rate limiting. An agent without an explicit branch for each of those will retry blindly and burn credits.

Why Agents Need Deterministic Tools, Not Chat Interfaces

The uncomfortable truth of agent-driven media: the bottleneck is not model intelligence, it is tool determinism. An agent is only as reliable as the interfaces it operates, and the properties that make an interface agent-friendly are unglamorous:

• Idempotency, so a retry is free rather than billable.
• Stable machine-readable error codes, so failure handling is a branch and not a guess.
• A discovery endpoint listing valid tool slugs and costs, so the agent verifies rather than assumes.
• Push notification with a signature, so completion does not depend on the agent staying awake.
• Cost reported in the response, so spending is observable per action.
• A published failure policy, so the agent knows whether a failed render costs money.

A chat UI has none of these. This is why "the agent will just use our web app" is a plan that demos well and operates badly: every UI change breaks the run, nothing is idempotent, and a failure looks like a screenshot rather than a code.

The Failure Modes Nobody Budgets For

Prompt injection through your own inbox. Reported testing puts Astra's indirect prompt-injection success rate at about 8.5% on Gray Swan's IPI Arena — an improvement over the 27% reported for its predecessor, and still roughly one hostile document in twelve. A property agent reads emails, PDFs and portal listings written by strangers. Assume some of them contain instructions aimed at your agent, and never give the same agent both untrusted input and unsupervised authority to publish or pay.

At-least-once webhook delivery. Webhook delivery is at-least-once by design: a handler that times out after doing its work will be retried, so consumers must de-duplicate on job_id and keep handlers idempotent. Roomagen's retry schedule is up to five attempts over roughly 36 minutes; an agent must not treat the first delivery as the only one.

No ordering guarantees. Do not assume a webhook arrives after your own POST has returned, and do not assume job A's callback precedes job B's. Write state machines that tolerate arrival in any order.

Cost runaway. A confused agent can loop. One retry storm across a 60-photo shoot is a real invoice. Set a hard spend cap, check the balance endpoint before batch runs, and alert on unusual job creation rates.

Silent structural drift. The output is a valid image and the job says completed, but a window moved. Nothing in the pipeline errors. Only a verification step catches this — either a human, or an agent comparing output against source and flagging differences.

Disclosure that nobody applied. When a human edits a photo, a human remembers the disclosure rule. When an agent does it at 4am, only code remembers. Bake labeling and original-image retention into the pipeline itself — see the MLS and AB 723 disclosure guide.

The Agent-Readiness Checklist for Proptech Teams

Score your own stack. Each unchecked item is a place an autonomous run will break.

1. Does every system in the pipeline have an API? Anything that only has a UI will be operated by computer use — slower, costlier, more fragile.
2. Are write operations idempotent? Can the same request be replayed without double-charging or duplicating a record?
3. Do your integrations return machine-readable error codes, not prose?
4. Is there a discovery endpoint an agent can query for valid options rather than guessing?
5. Are webhooks signed, and do you verify signatures over raw bytes with a constant-time comparison?
6. Do your webhook handlers de-duplicate and tolerate out-of-order arrival?
7. Is there a polling fallback for every push channel?
8. Is spend observable per action and capped per period?
9. Are untrusted inputs isolated from credentials that can publish, pay or contract?
10. Is disclosure enforced in code rather than in a person's habit?
11. Is there an audit trail linking every published image to the job that produced it, the source photo, and the agent run that requested it?
12. Is there a documented stop condition — what makes a run halt and wake a human?

Teams that can tick 10 of 12 today are in a position to hand a media pipeline to an agent. Teams below that number should fix the integration surface first; a smarter model will not compensate for a stack that cannot be safely automated.

What Still Belongs to a Human

Three things, and they are not going to move soon.

Representation decisions. Whether a staged photo fairly represents a property is a judgment with legal and ethical weight. An agent can flag; a person should decide.

Client-facing exceptions. When a seller is unhappy with how their home was rendered, the answer is a conversation, not a retry.

Spend authority. Automate the work, not the budget. A hard cap enforced outside the agent's control is the cheapest insurance in this entire architecture.

The Bottom Line

The Astra era does not mean models will make your listing photos. It means models will operate the tools that make them, which puts the pressure on the tools rather than the intelligence.

Property teams that get value from this shift will be the ones whose media stack is API-first, idempotent, signed, observable and capped — the same qualities that make a system pleasant for human engineers, now enforced by an operator that never gets tired of retrying. If you are wiring an agent to an image pipeline, the Roomagen API documentation has the full request and webhook specification, and the API overview covers pricing and available tools.

Model capabilities, benchmark scores and pricing in this article reflect published reporting as of September 2026. API request shapes reflect Roomagen API v1 at the time of writing; check the documentation for the current specification.