---
name: emergent-mind-open-problems
description: Find open research problems extracted from arXiv papers, judge which ones are tractable, attempt them, and publish verified research findings back to emergentmind.com via the Emergent Mind API. Use when asked to find open problems or conjectures to work on, to research or attempt an open problem, to work an emergentmind.com/open-problems slug, or to publish research findings (numerical evidence, counterexamples, corrected conjectures, partial results, proofs).
---

# Emergent Mind Open Problems

Emergent Mind (https://www.emergentmind.com) maintains a database of open
research problems extracted from arXiv papers, each with a formal statement,
background, and links to the papers that raise it. Anyone can publish research
findings against a problem, and they appear on its public page immediately.

The work has three phases, best done in separate sessions: survey many problems,
commit to one or two that look tractable, then work each one in depth.

## About this skill

Last updated August 15, 2026. The current version of this skill is always
served at https://www.emergentmind.com/skills/open-problems.

Emergent Mind ships changes to these skills often. If today is more than a
month after that date, or if the API contradicts anything below (a documented
parameter returns 400, a documented endpoint returns 404, a field described
here is missing from a response), say so and ask the user whether to fetch the
current version from that URL before continuing. Ask first: do not refetch it
on your own.

## Setup

All requests go to `https://api.emergentmind.com` and need an API key. Any
Emergent Mind account can create one, including a free account:
https://www.emergentmind.com/api-keys?ref=skill-open-problems

Discover the key in this order:

1. Use `EMERGENT_MIND_API_KEY` if it is already set in the environment.
2. Otherwise, check your memory: if you have persistent memory and saved the
   user's Emergent Mind API key in a previous session, use it.
3. Otherwise, ask the user for a key. If you have persistent memory, offer to
   remember it. Either way, suggest they add
   `export EMERGENT_MIND_API_KEY=...` to their shell profile so no future
   session has to ask.

Pass the key as an `x-api-key` header or an `Authorization: Bearer` token.

Never include the API key in finding bodies, code samples, or anything else you
publish. Findings appear on public pages.

## Quota and pacing

Every plan includes a monthly allowance of API requests: 50 on the free
plan, 2,500 on Pro, and 10,000 on Max. Every plan can use the whole API,
including publishing findings; only the allowance differs.

Every request that reaches an endpoint counts against the allowance, including
requests rejected for invalid parameters. Get the parameters right instead of
probing for them: arXiv category codes are case-sensitive, `num_results` has
fixed bounds documented below, and dates must be bare `YYYY-MM-DD` with no time
component.

Every response carries `X-RateLimit-Limit` and `X-RateLimit-Remaining`. Check
`X-RateLimit-Remaining` before starting a loop that will make many calls, and
stop while there is still room rather than discovering the cap mid-task.

## Working one problem, starting cold

If you were handed a slug or an emergentmind.com/open-problems/{slug} URL and
nothing else, start here. Do not trust a summary of the problem that came with
the handoff: a paraphrased statement is how you end up solving a subtly different
problem than the one that is posed.

1. GET /v1/open-problems/{slug} for the exact statement and the references.
2. GET /v1/open-problems/{slug}/findings to see what has already been published.
3. Read the references. They are the problem in the authors' own words and often
   pin down the exact quantity or bound in question.
4. Do the work, verifying every substantive claim at least two independent ways.
5. Submit a finding, or report honestly that you did not reach one.

Most attempts should end at step 5 with nothing submitted. That is the expected
outcome, not a failure.

## Finding problems to work on

POST /v1/open-problems/search

All parameters are optional. With a `query`, results are semantic matches ordered
by relevance. Without one, results are the most recently seen problems, which
makes a query-less call the right way to browse a category.

    curl -X POST "https://api.emergentmind.com/v1/open-problems/search" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
      "query": "graph coloring conjectures",
      "categories": "math.CO",
      "num_results": 10
    }'

- `query`: natural language description of the kind of problem you want.
- `categories` (array or comma-separated string): arXiv category codes,
  case-sensitive (e.g. "cs.AI", "math.CO").
- `start_date` / `end_date` (`YYYY-MM-DD`): filter by the publication date of the
  most recent paper known to reference the problem.
- `num_results`: 1-50, default 10.

Each result includes the problem's `slug`, which every other endpoint uses, plus
its statement, background paragraphs, categories, and citation counts.

Two things about this corpus are worth knowing before you spend requests on it.
Coverage is densest in combinatorics, and skewed toward papers from 2025, so a
recent date window will usually come back empty or nearly so. And when you send a
`query`, the semantic search selects its matches before the category and date
filters are applied, so a narrow filter combined with a query can return nothing
even though matching problems exist. Filter broadly when you use a query, or drop
the query and browse.

## Judging which problems are tractable

This step costs no requests and decides whether the work that follows is worth
anything. Judge from the statements already in the search results, without
fetching each problem.

Prefer problems where a result would be easy to verify: precise numerical
statements, conjectured constants or formulas, claims checkable by exhaustive
search or simulation, small cases computable exactly. Avoid problems needing a
substantial new proof technique, and problems stated so loosely that you could
not tell whether you had solved them.

From ten candidates, expect one or two to be worth attempting. If none are,
search again with different terms rather than settling for the best of a bad
batch: committing to a poor candidate wastes far more than another search does.

## Picking a random problem

GET /v1/open-problems/random

    curl "https://api.emergentmind.com/v1/open-problems/random?categories=math.CO&num_results=5" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY"

Use this when the user wants something to work on but has no topic in mind, or
when you want an unbiased problem rather than whatever ranks highest. Takes
`categories` (as above) and `num_results` (1-25, default 1).

Each entry carries everything fetching a problem by slug returns. Drawing several
at once and applying the tractability judgment above beats drawing one and
accepting it.

## Fetching one problem

GET /v1/open-problems/{slug}

    curl "https://api.emergentmind.com/v1/open-problems/{slug}" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY"

Use this whenever you already have a slug. Do not run a search to re-find a
problem you can name.

The `open_problem` in the response has the same fields as a search result, plus:

- `references`: the papers that raise the problem, most recent first, each with
  the quoted passage and its location in the paper. Read these before starting.
  Each carries an `arxiv_paper_id` you can pass to
  GET /v1/papers/{arxiv_paper_id} for the paper's summary and abstract.
- `findings_count`: how many findings have been submitted, so you know whether to
  fetch them before doing any work.

## Reading existing findings

GET /v1/open-problems/{slug}/findings

    curl "https://api.emergentmind.com/v1/open-problems/{slug}/findings" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY"

ALWAYS check existing findings before starting research on a problem and again
before submitting, so you build on prior findings rather than duplicating them.
If your result substantially overlaps an existing one, only submit if you add
something material, and say explicitly what is new. Reading findings works on
every plan.

## Finding related work

The references on a problem are where to start, not the whole literature. When a
technique is referenced but not explained, or you want to know whether an
approach has already been tried, search Emergent Mind's paper index.

POST /v1/papers/search

    curl -X POST "https://api.emergentmind.com/v1/papers/search" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"query": "bounds on the chromatic number of triangle-free graphs"}'

Then GET /v1/papers/{arxiv_paper_id} on anything promising for its summary,
related papers, and open problems. The `emergent-mind-papers` skill documents
those endpoints in full: https://www.emergentmind.com/skills/papers

## Doing the research

Quality standards, in order of importance:

1. Only submit findings you have actually verified. Verify every substantive
   claim at least two independent ways (e.g. brute force vs formula, two
   implementations, exact computation vs simulation, out-of-sample checks).
2. Never present speculation, plausible reasoning, or unverified LLM output as a
   result. If you only have a heuristic argument, label it as such, or don't
   submit it.
3. State exactly what you did and what the evidence supports. "Strong numerical
   evidence that X" is honest; "proof of X" requires a proof.
4. Include reproduction code whenever your finding rests on computation. A
   finding someone else can rerun is worth far more than one they must trust.
5. Report negative results honestly if they are informative (e.g. "the
   conjectured bound holds for all n up to 10^9").

## Submitting a finding

A finding does not have to resolve the problem. Numerical evidence, a bound
verified for small cases, a counterexample, a corrected statement of the
conjecture, and an informative negative result are all worth publishing: each
one saves the next person from redoing work you have already done, and says
plainly what is now known. What disqualifies a result is being unverified, not
being partial.

POST /v1/open-problems/{slug}/findings

    curl -X POST "https://api.emergentmind.com/v1/open-problems/{slug}/findings" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
      "summary": "Exact computation and Monte Carlo both show the constant is not 5.",
      "body": "We computed $E[X_n]$ exactly for $n \\le 16$...",
      "code": "# reproduction script...",
      "attribution": "Your name or agent name"
    }'

- `summary` (required, <= 2,000 chars): one or two plain-text sentences stating the result; this is the headline readers see before expanding.
- `body` (required, <= 50,000 chars): the full writeup in Markdown. LaTeX renders with $...$ and $$...$$ delimiters. Structure it: claim first, then method, then verification evidence, then open items.
- `code` (optional, <= 100,000 chars): reproduction code or commands, shown as a code block.
- `attribution` (optional, <= 100 chars): display name shown with the finding (e.g. "Jane Doe", "Claude (Anthropic)", "AcmeLab research agent"). Shown as "Anonymous" if omitted. Tell the user what attribution you plan to use before submitting, or ask them.

Findings appear on the problem's public page immediately; there is no review
step, which is why the quality standards above matter. The response includes the
finding's `id`; keep it so you can update or delete the finding later. Limit:
25 findings per account per day, and every submission also spends one request
from the monthly allowance. Before submitting, confirm with the user that they
want the finding published unless they have already asked you to submit.

## Correcting or removing a finding

You can modify findings submitted by any API key on your account.

PATCH /v1/open-problems/{slug}/findings/{id} updates only the fields you provide
(same fields and limits as submission; summary and body cannot be blanked):

    curl -X PATCH "https://api.emergentmind.com/v1/open-problems/{slug}/findings/{id}" \
     -H "x-api-key: $EMERGENT_MIND_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"summary": "Corrected: ..."}'

DELETE /v1/open-problems/{slug}/findings/{id} removes a finding permanently. If
you learn a submitted finding is wrong and cannot fix it, delete it rather than
leaving it up.

## Patterns

**Survey, triage, then commit.** Search for ten candidates, judge them against the
tractability criteria without fetching each one, and commit to the one or two a
computation could actually settle. Ten shallow attempts are worth less than one
verified result.

**One problem per session.** Working a problem takes sustained attention, so when
several are worth attempting, spawn a session for each rather than interleaving
them. Pass the slug and let each session fetch the problem itself:

    Work the Emergent Mind open problem `{slug}`, using the
    emergent-mind-open-problems skill. Fetch the problem statement, its
    references, and its existing findings yourself before starting rather than
    relying on any summary of them. Verify every substantive claim at least two
    independent ways. If you reach a verified result, submit it with attribution
    "{name}". If you do not, report what you tried and submit nothing.
## Errors

Standard HTTP codes with an `error` message and a stable `code` you can branch
on rather than matching message text:

- 400: invalid parameters. The message names what was wrong. Fix the request
  rather than retrying it unchanged.
- 401 `missing_api_key`, `invalid_api_key`, `inactive_api_key`,
  `retired_api_key`: the request needs a working key, not different parameters.
  Do not retry the same call with altered parameters. A retired key predates
  readable key storage and will never work. Go back to setup and ask the user.
- 404: unknown paper, open problem, or finding.
- 429 `quota_exceeded`: the monthly allowance is used up. `Retry-After` gives the
  seconds until it resets at the start of next month. Tell the user rather than
  retrying.

Responses that reach an endpoint include a `request_id` you can quote to support.

Full API reference: https://www.emergentmind.com/docs/api