CognitiveKernel-Pro: A Deep Research Agent That Runs Generated Python in the Open

What CognitiveKernel-Pro is trying to solve

Deep research agents are usually described through their benchmark scores, with the training pipeline kept private. CognitiveKernel-Pro goes the other way. The README frames the project as two things at once: an agent that uses as many free tools as possible, and a fully reproducible open-source SFT training recipe that the authors state outperforms RL-based models such as WebDancer and WebSailor without any RL. The paid dependency is named explicitly: the Google Search API, which the README says can be replaced with the free DuckDuckGo API. That single sentence tells you who the project is for. It is aimed at teams that want to reproduce or extend a research agent pipeline on a small budget, not at teams that want a managed search endpoint with an uptime number attached. The repository also ships data and model weights on Hugging Face under the CognitiveKernel organisation, including a query set, an SFT set, and a Qwen3-8B-CK-Pro model, which is consistent with the claim that the recipe is meant to be rerun rather than read.

The agent is a configuration dictionary, not a config file

The mechanism visible in the README is a single Python dictionary passed on the command line, and the values in it map onto object attributes. The commented-out block in the README describes the rule directly: the dictionary is applied through a class called KwargsInitializable in utils.py, and the mechanism is assignment to __dict__, so nested keys reach nested objects. The example shows a CKAgent with a model key, a max_steps key, and a web_agent key whose own model, model_multimodal and web_env_kwargs keys each carry a call_target or a web_ip. That means the same string, for example gpt:gpt-4o-mini or an http:// URL ending in /v1/chat/completions, is the whole model selection layer. There is no schema file and no validation step described. A typo in a nested key is a silent no-op rather than an error, which is a real cost of this design and worth knowing before you spend an afternoon debugging a model that was never actually swapped.

Getting it running: dependencies, web engine, and the test invocation

The README recommends python3.12 and splits installation into two pip commands. The first pulls boto3, botocore, openai, duckduckgo_search, rich, numpy, openpyxl, biopython, mammoth, markdownify, pandas, pdfminer-six, python-pptx, pdf2image, puremagic, pydub, SpeechRecognition, bs4, youtube-transcript-api, requests, transformers, protobuf, langchain_openai and langchain. The second adds selenium, helium and smolagents. The web engine is Playwright-based and started by a shell script: ck_pro/ck_web/_web/run_local.sh on Linux, run_local_mac.sh on macOS. On Linux the system packages are poppler-utils, default-jre, libreoffice-common, libreoffice-java-common, libreoffice and ffmpeg; on macOS the equivalent is brew install --cask libreoffice plus poppler and ffmpeg. The test invocation exports PYTHONPATH, sets WEB_IP to a local port such as localhost:3001, sets LLM_URL to a vllm endpoint or to a gpt: or claude: shorthand, and builds MAIN_ARGS as that nested dictionary. The command itself is NO_NULL_STDIN=1 python3 -u -mpdb -m ck_pro.ck_main.main --updates "${MAIN_ARGS}" --input ... --output ..., with the README noting that -mpdb can be dropped to run without the debugger and that removing --input lets you type a task on stdin.

The sandbox warning is the most important line in the README

Both platform sections carry the same note in capitals: it is recommended to run this program in a sandbox because the generated Python code is directly executed and there are currently no safety checkings. The README then gives the hardening steps it considers adequate, which are blunt. On Linux it writes a sudoers rule denying all sudo, chmods it to 440, removes the user from the sudo group, and renames the host to localhost. On macOS it does the same rule, removes the user from the admin group with dseditgroup, and sets the hostname with scutil. This is a research posture, not a production one. Removing sudo from a user does not confine a process that can already read the filesystem it runs on, and the README does not claim otherwise. If you are evaluating this for anything that touches untrusted web pages or user-supplied tasks, the correct reading is that isolation is your responsibility and the repository does not provide it. That limitation alone decides the deployment question for many teams.

Two training paths, and the difference between them

The README describes an SFT recipe as the headline result and an RL recipe as the follow-up. The SFT path is presented as fully reproducible and as beating RL-based models without RL. The RL path is a specific algorithm the project calls subgoal-GRPO, added in an April 2026 manuscript update. The distinction matters for cost. An SFT run is a single supervised pass over the released CognitiveKernel-Pro-SFT data. A GRPO run needs rollouts, reward computation and repeated sampling, which is a different order of GPU time and engineering. The README does not publish a hardware bill for either, so treat the SFT path as the one you can plan for and the subgoal-GRPO path as the one you should prototype on a small slice first. The project also points to related work from the same group, including WebAggregator for synthesising agent data and two accepted papers on verification and critical step optimisation, which suggests the training side is where the group's effort is concentrated.

Where it stops being the right tool

The repository has no releases. The default branch is main and the last push is dated 2026-04-29, so the practical upgrade path is pulling main and reading the diff, not bumping a version pin. The licence field resolves to NOASSERTION, meaning the repository does not declare a recognised licence identifier; the README's MIT badge is commented out in the source, which is a signal that the licence question was left open rather than settled. Do not assume permissive terms from the presence of a badge-shaped comment. There is also no homepage listed. If your requirement is a stable dependency with a changelog and a support channel, this is the wrong shape of project, and the absence of releases will show up the first time a main-branch change breaks your MAIN_ARGS dictionary. The other case to avoid is latency-sensitive serving: the flow here is a browser server plus a model endpoint plus generated code execution, and the README gives no throughput figures at all.

How it differs from a general agent framework

A general-purpose agent framework such as smolagents, which appears in this project's own dependency list, gives you a library of agent abstractions and leaves the environment to you. CognitiveKernel-Pro inverts that. The environment is the product: a Playwright web server started by run_local.sh, document converters for PDF, PPTX, Excel, audio and video pulled in as flat pip dependencies, and a research task loop driven by ck_pro.ck_main.main. The agent is not a general assistant you point at arbitrary tools; it is a deep research loop with a browser and a file agent wired in through the same configuration dictionary. That is why the free-tool constraint makes sense here and would be odd in a general framework. It also means swapping out the web server for a different browsing backend is not a supported operation described anywhere in the README, so evaluate the browser layer as fixed.

What to check before you commit

Read the licence file in the repository rather than the README badges, because NOASSERTION is what the metadata reports and the MIT badge is commented out. Confirm your model server actually speaks the chat completions schema, since the example points call_target at a URL ending in /v1/chat/completions and the gpt: and claude: shorthands are shown as alternatives rather than defaults. Run the ck_main/_test example before touching the GAIA evaluation zip, because the test path is the shortest loop that exercises the web server, the model endpoint and the dictionary plumbing together. And budget for the sandbox as a separate work item, not a line in the setup script. The README's own hardening steps are a starting point for a research box, and it says so.

Editorial conclusion

Adopt CognitiveKernel-Pro if you are training or evaluating research agents and can give the Playwright web server its own sandbox, since the README states the generated Python is executed directly with no safety checking. Do not adopt it as a hosted search product or as a drop-in replacement for a managed research API; there are no releases, no versioned packages, and the licence field resolves to NOASSERTION, so commercial reuse needs its own legal read. Before anything else, confirm the licence text in the repository, check which of the two run_local scripts matches your platform, and verify that the model endpoint you point call_target at actually serves the chat completions schema the example assumes.

Official sources

1. Issues
2. README
3. Tencent/CognitiveKernel-Pro on GitHub