> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atlasmeets.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build With An Agent

> Give these markdown files to your internal coding agent so it can scaffold the Atlas gateway for you.

## You do not have to build this by hand

Many teams will use an internal coding agent to create the first gateway.

That is a good fit for this contract.

If you are still deciding when to wire the gateway, read [Quickstart](/atlas/quickstart) first.

The common rollout is simple:

1. start with Atlas in meetings
2. let your own internal agent publish shared work into Atlas through the [Workspace API](/atlas/workspace-api)
3. connect the live gateway when Atlas should call tools during the meeting

The easiest way to do it is:

1. hand your agent a short brief
2. hand it the manifest checklist
3. hand it the acceptance-test file
4. ask it to produce a small HTTP service that matches the Atlas contract

## The builder pack

If you are reading the hosted docs, use these links directly.

These are plain markdown files you can copy into Claude, Codex, Cursor, or your own internal coding agent workflow:

* [gateway-builder-brief.md](https://raw.githubusercontent.com/abhishekloiwal/docs/main/templates/gateway-builder-brief.md)
* [gateway-manifest-checklist.md](https://raw.githubusercontent.com/abhishekloiwal/docs/main/templates/gateway-manifest-checklist.md)
* [gateway-acceptance-tests.md](https://raw.githubusercontent.com/abhishekloiwal/docs/main/templates/gateway-acceptance-tests.md)

If you want to inspect them in GitHub first:

* [templates/](https://github.com/abhishekloiwal/docs/tree/main/templates)

Use them in this order:

1. copy the three files into your own repo or prompt workspace
2. attach them to your coding agent
3. ask the agent to build the first small gateway
4. validate it in Atlas

## What the internal coding agent should build

The first version should be small:

* `GET /v1/manifest`
* `POST /v1/invoke`
* bearer auth
* one read-only action

For the manifest, tell the coding agent to keep `inputSchema` strict-safe from the start:

* root object schemas only
* `additionalProperties: false`
* `required: []` for no-input actions
* nullable required fields for optional params

Then add:

* one async action
* one approval-required action
* job status and cancel endpoints if needed

Later, you can also ask the internal coding agent to produce **debrief contract payloads** for completed work, so Atlas can present those results in a guided meeting. When you do, tell it to lead with the most important point, keep the delivery concise and actionable, and only add canvas pages that earn their place. For new builds, the cleanest way to deliver those debriefs is usually the [Workspace API](/atlas/workspace-api), not the older gateway-fed sync flow.

## The output you want from the coding agent

Ask for:

* a small runnable service
* the manifest
* one real read-only action
* curl examples
* tests for the manifest and invoke paths

In practice, the first good output is usually:

* a tiny FastAPI, Express, or similar HTTP service
* one real internal action, not a mock action
* clean bearer auth
* one manifest test and one invoke test
* curl commands that a human can run without guessing

## What not to ask it for first

Avoid asking the first version to:

* expose every internal API
* proxy raw downstream secrets
* add many actions at once
* add continuous background behavior

Start with a narrow contract that Atlas can validate and call cleanly.

If your internal coding agent starts dumping too many actions into the manifest, reset the scope and ask for a smaller first version.

## Recommended prompt

```md theme={null}
Build a small Atlas gateway that implements the hosted Atlas Gateway Contract v1.

Use the attached markdown files as the source of truth:

- gateway-builder-brief.md
- gateway-manifest-checklist.md
- gateway-acceptance-tests.md

Requirements:
- expose GET /v1/manifest
- expose POST /v1/invoke
- use bearer auth
- start with one read-only action
- keep the code simple and easy to extend

Deliver:
- the gateway service
- sample manifest output
- curl examples
- tests
```

## After it is built

Once the gateway exists:

1. register it in the Atlas dashboard
2. run the built-in sync check
3. run async and approval checks if you support them
4. test it in a real meeting

## If you do not need a live gateway

Some teams do not want Atlas to call tools during the meeting at all.

In that case, use the [Workspace API](/atlas/workspace-api) instead:

* your trusted internal agent can push shared skills into Atlas
* it can update shared agents
* it can upsert debriefs directly into the workspace

That is the better fit when the work already happened elsewhere and Atlas just needs the clean result.