Artifacts & Codebase Understanding

When an Antigravity agent works, it does not just produce code. It produces Artifacts: tangible, reviewable deliverables like implementation plans, file diffs, terminal output, screenshots, and browser recordings. Artifacts are how the agent communicates its reasoning and progress. They are also how you provide feedback -- you leave comments on an Artifact and the agent incorporates them without stopping its execution flow.

The other side of this is the codebase understanding engine: how Antigravity builds a deep model of your project so agents can reason about it without you explaining the architecture every time.

What you'll learn

• Artifacts are the agent's deliverables: plans, diffs, screenshots, logs, and browser recordings
• You review and give feedback on Artifacts, not on individual tool calls or raw agent output
• The deep codebase understanding engine lets agents navigate large projects without per-session setup
• Feedback is iterative -- leave a comment on a plan Artifact and the agent revises before executing

The problem

Working with a coding agent that only produces text output is like code review with no diffs. You read the agent's summary ("I added the endpoint and it works") and hope it is accurate. You scroll through tool-call logs to verify what actually happened. If something is wrong, you prompt the agent to fix it, and it starts over from scratch. There is no persistent artifact to review, annotate, or reference later.

Artifacts solve this by making the agent's work visible, reviewable, and commentable. You do not verify by reading logs. You verify by reviewing the plan, checking the diff, opening the screenshot.

What Artifacts look like

Artifact type	What it contains	When the agent produces it
Plan	Step-by-step breakdown of the task: what the agent will do, in what order, with what tools	Before touching any code. This is your approval gate
Code diff	The actual file changes, with the same context you would see in a pull request	After writing code, before moving to the next step
Terminal output	Results of commands the agent ran: test runs, builds, installs	After each terminal operation
Screenshot	A browser capture showing the rendered result of a UI change	After frontend work, as verification
Browser recording	A video of the agent navigating the application, clicking through a flow	For complex UI interactions where a screenshot is not enough
Task list	A living checklist of subtasks, updated as the agent progresses	Throughout execution, to track completion

Build it: the Artifact review loop

Here is the interaction pattern you will repeat throughout your Antigravity sessions:

1. You give the agent an objective:
   "Add rate limiting to the API endpoints"

2. Agent produces a Plan Artifact:
   - Which endpoints to modify
   - Which rate limiting library to use
   - How to configure limits per endpoint
   - How to test

3. You review the Plan:
   - If the approach is correct, approve it
   - If something is wrong, leave a comment:
     "Use token bucket instead of fixed window for limits"
     "Skip the health check endpoint"

4. Agent revises the Plan based on your feedback (still no code written)

5. After Plan approval, agent writes code and produces a Code Diff Artifact

6. You review the diff. Can leave inline comments on specific lines

7. Agent runs tests and produces a Terminal Output Artifact (test results)

8. If applicable, agent captures a Screenshot Artifact of the rate-limited endpoint response

9. The conversation preserves all Artifacts for future reference

This loop is the defining pattern of working with Antigravity. It is closer to reviewing a pull request than to pair programming.

The deep codebase understanding engine

Antigravity's agents do not start every conversation with a blank slate. The platform builds a semantic understanding of your codebase: which files import from which, how modules connect, where tests live, which patterns are used for routing, authentication, and configuration.

This happens automatically. You do not need to generate index files or maintain a knowledge base though you can supplement it with GEMINI.md context files for project-specific conventions. The agent uses this understanding when it plans tasks, so it can say "I will add the rate limiter middleware to the existing auth middleware chain" rather than "I need to find where middleware is configured."

The engine currently works best on common architectures and frameworks. Highly unconventional project structures may confuse it. In those cases, a GEMINI.md file explaining the layout is effective.

What goes wrong

Mistake	How you notice it	The fix
Skipping plan review	Agent implements something you did not want, wastes time on wrong approach	Always review the Plan Artifact. Reject if the approach is wrong. This is the cheapest time to correct course
Approving a diff without reading it	Bugs or bad patterns sneak in; you catch them days later	Review diffs the same way you review a colleague's PR. Leave inline comments
Not using Artifact feedback	You type a new prompt instead of commenting on the Artifact; the agent loses context	Comment on the Artifact directly. The agent sees the comment in relation to the specific output it produced
Assuming codebase understanding is perfect	Agent makes incorrect assumptions about your project structure or conventions	Add a GEMINI.md file with project conventions. The agent reads it on every session

Confirm it worked

Start a conversation and ask the agent to plan a small feature:

"Plan an implementation for adding request logging middleware to this project. 
Produce a Plan Artifact but do not write any code."

The agent should produce a Plan Artifact that:

1. Identifies where middleware is configured in your project
2. Proposes a specific implementation approach
3. Lists which files will be modified
4. Describes how it will verify the change

Review the Plan Artifact. Leave a comment if something is wrong. Verify the agent sees your comment and adjusts the plan.

Then tell the agent to proceed. It should produce a Code Diff Artifact, execute the changes, and produce a Terminal Output Artifact showing the result.

If the full loop (plan, review, execute, verify) completed with Artifacts at each stage, the Artifact system is working.

Next: Browser-in-the-Loop