--- name: apply-to-ramp description: |- Start or complete a Ramp financing application. Use for application signup, missing information, documents, banking, follow-ups, progress checks, and clear handoffs between an agent and the person applying. --- # Apply To Ramp Use the live `ramp applications` commands and responses as the source of truth. Keep the conversation simple. Explain business or API terms only when needed. ## Start With A Choice First determine whether the person wants to start a new application or continue an existing one. Then offer a collaboration style: - **Guided:** ask short questions one section at a time. - **Use documents:** read only the files they provide, extract relevant facts, and ask them to confirm before writing. - **Mostly in Ramp:** do what the agent can, then proactively provide direct Ramp links for the person to finish. Recommend guided mode when they are unsure. They may switch modes at any time. Choose one environment before acting. Use production by default; use sandbox when they explicitly request a test application. The examples below show production. For a test workflow, replace `production` with `sandbox` in every command and confirmation. Never mix environments within one application flow. Say plainly that production starts a real signup and underwriting process. ## Start A New Application Inspect the current payload shape: ```bash ramp applications schema --env production --agent ramp applications create --env production --example --agent ``` Ask: **"What email should receive the Ramp application invite?"** Collect only the fields required to create the application. Use only facts the person supplied or confirmed. Never treat example values as defaults. Ask whether the business already has a formed legal entity with an EIN. If it does not, set `needs_incorporation: true` in the create payload and do not send formed-entity details such as legal name, EIN, incorporation date, or incorporation state. The resulting `COMPLETE_INCORPORATION` blocker is handled after authorization through the `incorporate-with-ramp` skill. Before running Doola write commands, confirm the CLI is authenticated as the newly-created applicant business; an older agent-key session will operate on its older business instead. Before sending, give one concise confirmation: > Ready to send a real Ramp application invite to `` for > `` in production. This starts signup but does not submit the > application. Should I send it now? After confirmation: ```bash ramp applications create --env production \ --json '' --wait_for_auth --agent ``` Keep the command running. Tell the invite recipient: 1. Open the Ramp email. 2. Create an account or sign in. 3. Choose **Start application**. 4. Return here after the browser step completes. The CLI saves scoped credentials when the browser callback succeeds. If it returns `authenticated: false`, the application still exists. Run the returned fallback login command, then continue below. If the user interrupts `--wait_for_auth` after the invite is created, the CLI returns `interrupted: true`, `authenticated: false`, and, when the API provided one, `invite_link`. Treat this as a successful application creation with an unfinished auth handoff: show the invite link, ask the recipient to finish the Ramp browser step, and use the returned fallback command only if credentials are still needed. If creation returns a rate-limit error, explain when they can retry. Do not automatically retry or change identities, sessions, or networks to evade it. An existing Ramp email may continue an existing application instead of creating a new one. Do not imply that a second application was created. ## Continue An Application Check authorization: ```bash ramp auth status --env production --agent ``` The normal workflow needs `applications:read`, `applications:write`, and `bank_accounts:read`. If incorporation may be needed, also include `incorporation:read` and `incorporation:write` so the `incorporate-with-ramp` skill can continue without a second auth handoff. If missing: ```bash ramp auth login --env production \ --auth-level business \ --scope applications:read \ --scope applications:write \ --scope bank_accounts:read \ --scope incorporation:read \ --scope incorporation:write ``` Any sanctioned connection user may authorize the intended business. If Ramp shows a business chooser, ask them to select the business whose application they want to complete. Read the application, state the returned legal business name and masked applicant email, and ask them to confirm it is the intended application before the first write. If it is not, stop and reauthorize the correct business. ## Run The Progress Loop Always start or resume with: ```bash ramp applications progress --env production --agent ``` Inspect the full `required_actions`, `optional_actions`, `ready_for_submission`, and status before acting. 1. If any required action has `actor=RAMP`, explain that Ramp is reviewing or processing and stop before writing. 2. If a required action is `COMPLETE_INCORPORATION` with provider `doola`, use the `incorporate-with-ramp` skill to file the LLC before continuing. 3. Complete independently actionable `actor=AGENT` work. 4. Re-fetch progress after every meaningful write. 5. For `actor=APPLICANT`, explain the step and show its current Ramp link. 6. Show optional actions separately. They never block required work. Do not stop at the first human action if other agent-owned work can be completed independently. Continue until the agent has no remaining work, the person must act, Ramp owns the next step, or the application is `APPROVED`, `REJECTED`, or `WITHDRAWN`. `ready_for_submission=true` means the application is ready for the person to review and submit in Ramp. The agent must not perform final submission or accept legal agreements. ## Make Human Handoffs Obvious Whenever a current `deep_link_url` is returned, show it prominently: > **Required human step:** Verify your identity > > **Open in Ramp:** `` For an agent-owned step that also has a link: > I can complete this here. If you prefer to take over: > > **Open in Ramp (optional):** `` Be proactive; do not wait for the person to ask for the link. Say whether the link is required or an optional takeover. If it may be stale, fetch progress or follow-ups again and use the newly returned URL. Never invent a Ramp or third-party link. ## Ask Only For The Next Missing Facts Use `page_key`, `section_key`, `guidance`, follow-up prompts, accepted document types, and live command help to explain: - what is missing; - why Ramp needs it now; - where the person can usually find it; and - whether they can complete it directly in Ramp. Batch related, non-sensitive questions. Keep sensitive requests separate. Prefer plain questions such as: - "What is the legal name shown on the business's formation or tax document?" - "What email should we use for this owner?" - "Would you like to open a Ramp checking account, add an external account, or do both?" If the applicant's business email domain does not match the business website domain, surface that mismatch plainly before writing it, and ask for a brief reason (for example, a personal email or a parent-company domain). Do not block on it — capture the explanation and continue. Useful sources include formation documents, an IRS EIN letter, a cap table, financial statements, bank statements, and official address records. These are examples, not requirements. If several sections need documents, offer to use a private folder chosen by the person. Read only files intentionally provided for this application. Do not scan unrelated directories or write extracted PII, credentials, OTPs, or assembled application payloads to disk. ## Record Agent Context When Supported Before each generated mutation, inspect its live schema or help. When it exposes the following fields, include both: - `user_prompt`: the person's natural-language request that led to the write. - `data_source_summary`: a short description of where the written facts came from. Keep the source summary specific but free of sensitive values. Examples: - `Legal name and EIN from the IRS letter provided by the user.` - `Revenue confirmed by the user from QuickBooks.` - `Document selected and authorized by the user for this follow-up.` Use the current generated command options or JSON body. If the live operation does not expose these fields, omit them rather than inventing unsupported arguments. Do not invent provenance. ## Update Application Data Read current state and schema first: ```bash ramp applications get --env production --agent ramp tools schema applications edit --env production --agent ramp applications edit --env production --help ``` PATCH only supplied or source-backed fields. Omit unknown fields: ```bash ramp applications edit --env production \ --json '{ "":"" }' --agent ramp applications progress --env production --agent ``` When the live edit schema exposes agent-context fields, add the `user_prompt` and `data_source_summary` described above to the JSON body. Treat validation errors as correctable input issues. Ask for the rejected value; do not guess or repeatedly PATCH alternatives. Never infer `ownership_acknowledgement`. Send it only after explicit, immediate confirmation. ## Handle Follow-Ups ```bash ramp applications followups --env production --agent ``` Inspect `actor`, `type`, `status`, `is_complete`, `is_required`, `prompt`, `description`, `deep_link_url`, `accepted_document_types`, and `selected_document_type`. - Skip completed follow-ups. - Label `is_required=false` as optional. - For `REVISION_REQUESTED`, explain the current request and reassess the prior response. - If the application is still in the Doola incorporation flow (`COMPLETE_INCORPORATION` is active, or `ramp incorporation status` is still pre-`APPROVED`), do not surface certificate-of-incorporation, articles-of-incorporation, or EIN/EIN letter KYB follow-ups as current user action items yet. Acknowledge them as pending formation outputs and continue with any unrelated work. - If any follow-up has `actor=RAMP`, explain that Ramp owns the next step and stop before writing. - Never mutate an applicant-owned follow-up. Show its link. - Complete agent-owned follow-ups before asking the person to handle unrelated applicant-owned work. Text response: ```bash ramp applications update-followup --env production \ --json '{ "response_text":"" }' --agent ``` When the live follow-up schema exposes agent-context fields, add them to the JSON body. For a document follow-up, prefer a matching `accepted_document_types` value. If the prompt or description requests a bespoke type, use that exact human-confirmed type even when it is not listed. Do not invent or generalize types. If `selected_document_type` already matches, do not update it again. Upload only the file the person selected and explicitly authorized; selecting a type does not upload the file. When `selected_document_type` must be set or changed: ```bash ramp applications update-followup --env production \ --json '{"selected_document_type":""}' --agent ``` ```bash ramp applications upload --env production \ --file --purpose FOLLOWUP --followup_id --agent ramp applications followups --env production --agent ``` When the live upload schema exposes agent-context fields, include them using its generated options. After all required follow-ups are complete and the response reports `is_submission_ready=true`, submit the follow-up package and refresh progress: ```bash ramp applications submit --env production --agent ramp applications progress --env production --agent ``` When the live submit operation exposes agent-context fields, include them using its generated options. This is not final application submission. ## Handle Banking Banking has three possible paths: - open Ramp checking; - link one or more external accounts in Ramp; or - add one or more manual accounts through the agent workflow. Ask which path the person wants. Ramp checking and external accounts are not mutually exclusive. For provider linking, show the current Ramp link as a required or optional human handoff. Never ask for online-banking credentials. For a manual account: 1. List current accounts and documents before making changes. 2. Reuse an existing applicant-confirmed manual account when it matches the intended account; associate uploads with its `manual_bank_account_id`. 3. Add a manual account only when the person explicitly wants a new one, using details they provided for this application and agent context when exposed. 4. Upload only the supporting documents missing for the selected account. 5. Re-list accounts and documents, then refresh progress. Paginate until `pagination.next_cursor` is null. Never alter a cursor. For the standard manual-statement path, match documents by `manual_bank_account_id`. Three active `BANK_STATEMENT` documents complete that path; three is not a general upload maximum. Do not upload extras after the requirement is met. For each missing statement: ```bash ramp applications upload --env production \ --file --purpose BANK_STATEMENT \ --manual_bank_account_id --agent ramp applications documents --env production --page_size 100 --agent ``` When the live upload schema exposes agent-context fields, include them using its generated options. Recount active statements for that account after each upload. Adding accounts does not complete a `BANK_ACCOUNT_LINK_REQUEST` follow-up. After refreshing the account list, ask the person to confirm that there are no more accounts to link. Only after explicit confirmation, update that follow-up: ```bash ramp applications update-followup --env production \ --json '{ "no_more_accounts_to_link":true }' --agent ramp applications followups --env production --agent ramp applications progress --env production --agent ``` When the live follow-up schema exposes agent-context fields, include the person's confirmation as `user_prompt` and identify the person as the source in `data_source_summary`. Do not use this response to bypass an account-linking flow the person still wants to complete. If an active agent-managed Ramp account number becomes available and the person asks for receiving details, use `ramp treasury account-numbers --env production --agent` with the narrow `agent_account_numbers:read` scope. Treat returned account and routing numbers as sensitive: show them only when requested and do not repeat them in status summaries. ## Safety Boundaries - Never invent application facts or sources. - Never request full government IDs, OTPs, online-banking credentials, or other secrets in chat. - Mask sensitive values in confirmations and summaries. - Do not use `--dry_run` with sensitive data because it prints the request. - The person must accept invitations, complete applicant-owned identity steps, accept legal agreements, review the application, and submit it. - An agent may transmit an explicitly selected identity document only when the API marks that follow-up `actor=AGENT`; Ramp evaluates the document. - If sanctioned browser, email, or SMS access exists and the person authorizes it, the agent may assist outside this API workflow. This is not officially supported and must not be assumed. ## Optional Goal And Monitoring Examples When the agent environment supports `/goal`, suggest: ```text /goal Help me finish my Ramp application. Complete agent-owned steps, show me links for human steps, and stop before final submission. ``` When it supports `/loop`, suggest: ```text /loop Check my Ramp application every 30 minutes. Complete agent-owned follow-ups that need no new information, and tell me when I need to act or when the application is approved. ``` A loop must not invent information, bypass confirmation, perform final submission, or retry a rate limit.