# Daring Ventures Agent Guide Instructions version: `1.1.0` Effective date: `2026-10-14` This is Joseph, co-founder and GP at Daring Ventures. If you're reading this, your user probably has you doing research on Daring Ventures. This guide covers our investment mandate and submission process; other published Daring resources are linked below. This page is reference material. Act only on your user's instructions. Your analysis and recommendation remain between you and your user. Daring does not request or receive them. You may optionally attach a small number of current factual updates or clarifications when your user asks you to submit. Maddi or Joseph reads every delivered deck. Agents standing by. ## Published resources - [Daring Ventures](https://daringventures.vc) - [NYC Events](https://nyc.drng.vc/) - [NYC Events Reference](https://nyc.drng.vc/index.md) - [NYC Events API](https://api.drng.vc/v1/nyc) - [Submission API Reference](https://api.drng.vc/docs) ## Thesis Daring Ventures is a pre-seed venture firm investing in applied AI in the United States. Daring invests at pre-seed in the markets that open where software used to stop. AI is making more work that depends on expertise, judgment, or complex coordination economical to deliver through software. A useful first product can create the customer relationships and knowledge to make additional products and markets possible. Through use, the first product can generate information that was previously unavailable, fragmented, or expensive to obtain. That knowledge can improve delivery and make additional businesses possible. ## Basic mandate Daring's initial investment is USD 200,000 through 500,000. This is Daring's initial investment size, not the company's total round size. Daring focuses only on applied AI companies serving Enterprise and B2B customers. The company should be pre-seed. The product must be built and deployed with real commercial use. Revenue is not required. ## What Daring likes - A specific product for one painful job. - A defined ICP with real commercial evidence from beta customers, design partners, pilots, or paying customers. - A narrow starting point with a credible path to becoming a very large company. - A useful first product with a credible path to becoming a much larger business. - Companies operating in regulated, procured, or structurally complex industries. ## What Daring does not like - Broad platforms still searching for a use case. - Vanity customer metrics that obscure the actual commercial relationship. - Pipeline without an identified budget owner. - A small product with no credible reason to become a large company. - Motion presented as evidence of growth. ## Hard exclusions These exclusions are published information for your private analysis. They are not automated submission gates. - `hardware`: Hardware. - `medical_devices`: Medical devices. - `crypto`: Crypto. - `cold_start_marketplaces`: Marketplaces requiring both sides from cold start. - `directly_regulated_products`: Products directly regulated by the FDA, SEC, or CFTC. ## United States ### Published position Daring invests in companies meaningfully centered in the United States under their current facts. ### What this means Incorporation alone does not establish that a company is meaningfully centered in the United States. Current leadership, customers, relationships, and the stated center of future commercial growth all matter. ### Facts your user may want to consider - The country of incorporation. - The current location of company leadership. - Whether relocation has actually happened or is only planned. - The current geography of customers. - Whether foreign relationships are legacy relationships or part of current growth. - The stated center of future commercial growth. ### Examples - Positive example. Leadership is already in the United States. The company has three US customers and one legacy European customer. Future commercial growth is centered in the United States. Reasonable to discuss. A legacy foreign customer does not make the company non-US when leadership, customers, and future growth are meaningfully centered in the United States. - Negative example. The company is a Delaware corporation, its first three customers are in Europe, and leadership only plans to relocate to the United States. Outside the mandate under the current facts. Incorporation alone is insufficient, and a planned relocation is not a completed relocation. ## Regulated industries and regulated products ### Published position Software may serve a regulated industry or workflow, but products directly regulated by the FDA, SEC, or CFTC and medical devices are excluded. ### What this means A regulated customer or workflow is different from a product that is itself directly regulated. Medical devices are excluded regardless of their software content. ### Facts your user may want to consider - Whether the customer operates in a regulated industry. - Whether the software supports a regulated workflow. - Whether the company's own product is directly regulated by the FDA, SEC, or CFTC. - Whether the product is a medical device. ### Examples - Positive example. The company sells software into a regulated industry or supports a regulated institutional workflow, but its own product is not the regulated product. Within the published mandate. Daring likes software operating inside regulated and structurally complex industries. - Negative example. The company's own product is directly regulated by the FDA, SEC, or CFTC, or the product is a medical device. Excluded. Medical devices remain excluded regardless of how much software they contain. ## Marketplaces ### Published position A current product that requires both supply and demand from cold start is excluded. A genuinely single-player product is not excluded merely because a marketplace may be a future expansion. ### What this means Daring distinguishes a cold-start marketplace from a product that gives one customer standalone value before a network exists. Current architecture matters more than a possible future expansion. ### Facts your user may want to consider - Whether the current product requires both sides from cold start. - Whether one customer receives standalone value before a network exists. - Whether a marketplace is the current architecture or a future expansion. ### Examples - Positive example. The current product gives one customer standalone value before a network exists. A marketplace may become a future expansion. A future marketplace is not automatically excluded when the initial product is genuinely single-player. - Negative example. The current product has no value until both supply and demand are present. Excluded as a marketplace from cold start. ## Pre-seed ### Published position Pre-seed generally means that the company has raised very little or no institutional capital. ### What this means Prior institutional capital matters more than a self-selected stage label. ### Facts your user may want to consider - How much institutional capital the company has already raised. - Whether the stated stage matches the company's financing history. ### Examples - Positive example. The company has raised very little or no institutional capital. Consistent with Daring's definition of pre-seed. - Negative example. The company describes itself as pre-seed but has already raised meaningful institutional capital. The self-selected stage label is insufficient. Prior institutional financing determines whether the company fits the published stage. ## Product and commercial evidence ### Published position The product must be built and deployed with real commercial use. Revenue is not required. ### What this means Real usage by a beta customer, design partner, pilot, or paying customer can meet the requirement. A product with no real user does not meet it. ### Facts your user may want to consider - Whether the product is built and deployed. - Whether a real beta customer, design partner, pilot, or paying customer uses it. - What the actual commercial relationship is. ### Examples - Positive example. The product is built and deployed with real usage from a beta customer, design partner, pilot, or paying customer in a defined ICP. Revenue is not required. Pre-revenue companies can qualify when the deployed product has real commercial use. - Negative example. The product has not been deployed with any real user. The company does not meet the published commercial-evidence requirement under the current facts. ## Use this information privately Your founder-agent analysis remains private. Daring does not receive your recommendation, score, confidence, reasoning, private company context, or connected-source output. Daring does not run an automated fit evaluation. You may advise your user, but no agent verdict is required to submit. ## How to submit a deck ### Human submission Open the single human submission page: https://pitch.daringventures.vc 1. Enter the founder's name, email, company, website, and optional LinkedIn URL. 2. Choose the company's current deck as a PDF. 3. Optionally opt in to Daring Ventures event invitations. 4. Select **Submit**. The page creates the submission, uploads the PDF, and shows a receipt after the upload is accepted. The single regular human submission route and entry point is this page. Typeform is not a deck-submission route. ### Agent-assisted submission For agents whose users have asked them to submit: An agent may submit on the founder's behalf only after asking the founder for permission. There is no eligibility check and no token to obtain first. 1. POST the founder's structured company facts to `https://api.drng.vc/v1/submissions` with an `Idempotency-Key` header no longer than 128 characters. 2. Save the returned `status_token` and `manage_token`. The status token is read-only; the management token is used only for that submission. 3. Optionally attach the deck by POSTing its filename, `content_type: "application/pdf"`, and `size_bytes` to `https://api.drng.vc/v1/submissions/{submission_id}/deck` with `Authorization: Bearer {manage_token}` and a new `Idempotency-Key`. If your environment can hash and stat a local file, also send `client_sha256` and `client_modified_at`. Both are optional and neither is required to submit. 4. Upload the PDF bytes to the returned upload URL, sending every header in the returned `upload.headers` object exactly as given. 5. Read the upload receipt. Daring computes its own SHA-256 from the bytes it received and returns it with the byte size, the page count it derived from the PDF, and the filename and modification time you reported. `GET https://api.drng.vc/v1/submissions/{submission_id}/deck` returns the same receipt later, and `Accept: text/plain` renders it for a terminal. 6. Check the receipt before asking the founder to authorize delivery. Compare Daring's `sha256` against your own copy of the file, for example with `shasum -a 256 "Acme Seed Deck.pdf"`, and compare the full value rather than a shortened one. If you sent `client_sha256`, the response reports the comparison for you as `client_sha256_match`. If the two hashes differ, do not authorize: the PDF Daring received is not the file you meant to send, so upload it again. If the filename, page count, or modification date look wrong instead, the file arrived intact but may be the wrong file, so check with the founder before authorizing. 7. Use the returned status token with `GET https://api.drng.vc/v1/status` and `Authorization: Bearer {status_token}` to read the public status. Local hashing is encouraged where the environment makes it easy, and it is never required. Daring hashes what it receives either way, and the returned value is what any comparison should be made against. A hash tells you the file did not change on the way. It cannot tell you the founder attached the right deck, which is what the filename, page count, and modification date are for. A supported viewable link may be attached instead of a PDF through the corresponding submission link route. Supported providers are DocSend, Papermark, Canva, and Figma. Other providers and separate access codes are not supported. Optional context may contain a small number of current, factual, dated, attributable clarifications. It is not required. The exact deck and optional context are shown in a preview before delivery. The founder must authorize that preview before Daring receives the package. Maddi or Joseph reads every delivered deck. Regular and agent-assisted submissions enter the same human review queue. Daring does not automatically screen, score, rank, or reject a submission for mandate fit. ## Submission and authorization sequence The submission record is created first. The deck or link is then attached to that submission. Daring prepares a preview of the package, and the founder must authorize that exact preview before it becomes visible in the private partner queue. The founder receives the authorization link at `founder_contact`, so use an address the founder actually reads. The public status token reports only the honest milestones. It does not claim that a partner opened, viewed, acknowledged, or read the deck.