How to Get Client Assets Into Your Coding Agent

Last updated: September 15, 2026

Every coding agent hits the same wall: the code is ready to go, and the client's logo, copy, or login isn't — and there's no good way to hand it over.

The problem

Claude Code, Cursor, Codex, and every agent like them are fast at the part they can see: files, structure, logic. They're useless at the part they can't see — a logo sitting on the client's laptop, a paragraph of homepage copy nobody has written yet, a password to a booking system the agent has no way to ask for safely. The agent hits that wall, and from there the project's speed depends entirely on a human loop the agent has no part in: you email the client, the client forgets, you follow up, the client sends something usable eventually, if the thread doesn't die first.

That gap — between "the agent needs this" and "this exists somewhere the agent can read it" — is often the single slowest part of a client project, slower than any actual coding.

Three ways people currently handle it, and why each falls short

Paste it into the chat. Works for a sentence of copy. Falls apart for a file, because most agent chats either can't take an upload from a client who was never given access to the session, or the client pastes a screenshot of a logo instead of the source file, and now someone has to ask again. It also leaves no record: a request buried in a chat transcript from three weeks ago is not a request anyone reopens.

A shared Drive folder. Better for files, still manual on both ends. You have to create the folder, share it, describe what should go in it in a separate message, notice when something new lands, and manually check whether the client actually put in the right thing — a 200px logo export instead of the source file is still a 200px logo export once it's in the folder. Nothing validates it, nothing reminds the client if they stop halfway, and nothing tells the agent when it's actually complete.

A generic form. Typeform, Google Forms, a contact form bolted onto the site — these handle short text fields reasonably well and fall over on everything else a real project needs: no file uploads sized or typed the way a logo or a gallery needs to be, and nowhere safe to put a password. A client typing their WordPress login into a form field that emails it to you in plaintext is a liability wearing the shape of a solution.

The pattern that actually closes the gap

What works is inverting who initiates: instead of the agent (or you) chasing the client, the agent declares exactly what it needs — as typed, validated fields, not a paragraph of prose — and the client fills a portal built for that one job.

1. The agent declares what's missing. Not "please send some photos," but "12 to 20 photos, JPG or PNG, food and interior" — a shape the system can actually check.
2. The client gets one link. No account to create, no software to install. They open it, see a short list, and fill in or upload each item at their own pace.
3. The system chases automatically. Reminders go out on a schedule, addressed from you, without you or the agent remembering to follow up.
4. The agent resumes on its own signal. Instead of waiting on a reply in a chat window, the agent gets a webhook or checks a status endpoint, and picks the work back up the moment the answer exists — typed, validated, ready to use.

BriefGate is built around exactly this pattern for AI coding agents specifically: the agent calls define_intake() with a list of typed items (files, images, structured data, one-time credentials), BriefGate handles the portal, validation, and chasing, and the agent calls get_intake_results() when it's done — no parsing, no re-asking, no PDF glued into an email that never should have carried a password in the first place. See how BriefGate's item types work and the chase engine for the mechanics.

Setting it up in your agent

Any MCP-capable agent can use BriefGate this way — the pattern above doesn't depend on which one you use. Here's the one-line setup for the three most common ones, each with a full walkthrough:

Claude Code

claude mcp add --transport http briefgate https://mcp.briefgate.dev/mcp

Then run /mcp inside Claude Code, pick briefgate, and choose Authenticate — no key to copy or paste. Full guide: Client Intake for Claude Code.

Cursor

Add the hosted endpoint to .cursor/mcp.json or ~/.cursor/mcp.json:

{ "mcpServers": { "briefgate": { "url": "https://mcp.briefgate.dev/mcp" } } }

Then click Needs login next to the briefgate entry under Settings → Tools & Integrations. Full guide: Client Intake for Cursor Agents.

OpenAI Codex

codex mcp add briefgate --url https://mcp.briefgate.dev/mcp
codex mcp login briefgate

The first command registers the endpoint in ~/.codex/config.toml, shared by the Codex CLI, its IDE extension, and the ChatGPT desktop app; the second runs Codex's own OAuth flow for it. Full guide: Client Intake for OpenAI Codex.

Other agents

BriefGate is a standard MCP server over Streamable HTTP with OAuth 2.1, plus a local stdio package for a client that would rather not do a browser redirect — nothing about the setup is specific to the three agents above. Any agent that speaks the Model Context Protocol should be able to add it the same way: point it at https://mcp.briefgate.dev/mcp, or run npx -y @briefgate/mcp locally with an API key. That should cover agents like Windsurf, Gemini CLI, or GitHub Copilot's agent mode, though we haven't walked through each one's specific configuration screen — if you hit a snag with a client not covered by name here, the quickstart documents all four connection methods generically enough to adapt.

Once it's connected

The setup differs slightly per agent; what happens after define_intake() is called does not. The client gets one branded portal link by email, submits what's asked for, gets chased automatically if they stall, and the agent picks the results back up — typed and ready — whether it asked through Claude Code, Cursor, Codex, or anything else speaking MCP.

Next steps