cs.AIAug 28, 2026

String: An Agentic OS Where Every App Is a Markdown File

Authors: Jookyung Song, Nojun Kwak, Simyung Chang

Organizations: Seoul National University & H1R.AI · Seoul National University

Read PDF
Ask AI
Cite

Copy citation

DOINot available for this paper

Abstract

LLM agents have become a new class of software user, but every surface they work through was designed for someone else. Pages are built for human eyes, which can skim and ignore; tool schemas for programs, which pay nothing to carry definitions they never call. An agent has neither luxury: it re-reads, and pays again for, everything it is shown on every turn. We present String, an open-source runtime that gives this user an interface of its own and treats the job as an operating-systems problem. Tool knowledge moves out of the agent's context and into a common layer that renders it back one view at a time as Markdown. A single SFMD (String-Flavored Markdown) document declares an application's views, typed actions, navigation, and credentials, and the runtime handles discovery, validation, execution, state, and secrets behind two core verbs: /open to see and /act to do. Web and app turn out to be two renderings of one architecture: an SFMD site serves styled HTML to browsers and the raw document to agents, so one grammar reaches apps, files, shells, and the web, even legacy HTML, with no per-site integration. Views stay partial by design, and the staging is causal: disclosing one tier of detail a single turn too early costs up to 23 accuracy points, while proper staging drops wrong-action selection from 28% to 2%. Privilege follows provenance: a remote page may call HTTP but never the shell, and caller-supplied text never expands a stored secret. On an 87-task benchmark that pairs each task with curated skills, operationalizing those procedures as on-demand String apps yields comparable aggregate success across six models from frontier to small (+1.3pp) while using 33.5% fewer tokens among completed episodes, and the resident interface stays a constant 53 tokens at any catalog size. We report the design, the evaluation, and what three months of production use taught us.

Figures & tables

Figure 1: String in one view: the agent loop (command →\to partial Markdown view →\to next: hint →\to result), and the runtime that gives every surface—apps, files, web, shells, peers—one uniform grammar (P2), with views kept deliberately partial (P1) and shell execution reserved for local content.
OS conceptString constructRealized as
Process / address spaceTopicper-topic doc, history, vars; serialized execution
Syscall interfaceSlash commands∼\sim 20 verbs; one MCP tool {topic, cmd}
Filesystem & pagesSFMD documentsblock-addressable; partial views (P1)
IPCWebhook inboxappend-only messages, never executed; explicit ack
Package manager/installatomic staging; (namespace, name) identity
PermissionsProvenance boundary (P2)local ⇒\Rightarrow shell ++ HTTP; remote ⇒\Rightarrow HTTP only
Table 1: The OS analogy, made concrete. Each row is an enforced mechanism, not a metaphor.
ModelNo skillsSkillsStringΔ\Delta vs. Skills (pp)Token cut mean/median
GPT-5.551.5%67.3%68.5%+1.2+1.237.4% / 27.2%
DeepSeek V4 Pro26.9%50.1%50.9%+0.8+0.844.3% / 41.1%
Kimi K2.633.4%54.0%53.2%−0.8-0.839.2% / 36.1%
Claude Opus 4.845.7%54.1%57.8%+3.7+3.728.7% / 26.4%
Claude Sonnet 4.633.5%47.2%48.2%+1.0+1.021.7% / 19.2%
Claude Haiku 4.58.8%30.1%32.1%+2.0+2.029.6% / 28.4%
Table 2: SkillsBench (87 tasks, 3 runs per model–task pair; all conditions run on the OpenHands harness, as in the original benchmark). Operationalizing the benchmark’s curated procedures as executable String apps yields comparable aggregate success while cutting tokens among completed episodes by 21.7–44.3%.
Appendix figures & tables3 assets

Supplementary material from the paper’s appendix.

Appendix

Figure 2: Human view (rendered HTML, left) vs. agent view (partial Markdown rendered by String, right) of the same SFMD page.
Figure 3: A String app and what the agent sees (schematic). Left: the SFMD source of marker (PDF →\to Markdown): frontmatter, page, one fenced act block wrapping a local script. Right: the agent-visible view—the page and an invocable signature; interpreter, script path, and argument plumbing never render (P1, P3).
ModelSuccess (pre →\to post)Generated tokens/task (pre →\to post)Token cut
Qwen3.5-4B12/20 →\to 14/20 (60% →\to 70%)345.5 →\to 122.064.7%
Gemma 4-E4B13/20 →\to 16/20 (65% →\to 80%)182.8 →\to 38.678.9%
Qwen3.6-27B17/20 →\to 17/20 (85% →\to 85%)419.2 →\to 201.551.9%
Gemma 4-31B16/20 →\to 18/20 (80% →\to 90%)200.2 →\to 43.778.2%
Appendix
Table 3: Success and mean generated tokens per task before/after fine-tuning on String trajectories (20 held-out tasks).
More in this topic

Tool-Using Agents

Tool-using agents plan and act through external tools, APIs, software interfaces, and environments to complete tasks beyond language generation.

See all 290 papers

Explore similar work

CardsList
Feb 16, 2026

EmbeWebAgent: Embedding Web Agents into Any Customized UI

Most web agents operate at the human interface level, observing screenshots or raw DOM trees without application-level access, which limits robustness and action expressiveness. In enterprise settings, however, explicit control of both the frontend and backend is available. We present EmbeWebAgent, a framework for embedding agents directly into existing UIs using lightweight frontend hooks (curated ARIA and URL-based observations, and a per-page function registry exposed via a WebSocket) and a reusable backend workflow that performs reasoning and takes actions. EmbeWebAgent is stack-agnostic (e.g., React or Angular), supports mixed-granularity actions ranging from GUI primitives to higher-level composites, and orchestrates navigation, manipulation, and domain-specific analytics via MCP tools. Our demo shows minimal retrofitting effort and robust multi-step behaviors grounded in a live UI setting. Live Demo: https://youtu.be/Cy06Ljee1JQ

Chenyang Ma, Clyde Fare, Matthew Wilson +1

IBM Research Europe, UK · University of Oxford

Web AgentsTool-Using AgentsLLM Agent Harnesses
AskPDF
Jun 13, 2026

ToolMenuBench: Benchmarking Tool-Menu Filtering Strategies for Reliable and Efficient LLM Agents

Tool-augmented large language model agents increasingly operate over large tool libraries, but existing evaluations often focus on whether a model can call a tool correctly rather than how the visible tool menu shapes reliability, efficiency, and safety-relevant risk exposure. We introduce ToolMenuBench, a benchmark for evaluating tool-menu construction in multi-step LLM agents. ToolMenuBench varies tool-menu size, distractor type, state-dependent task structure, and risk exposure, and reports both filter-level and downstream agent metrics, including visible-tool count, risky-tool exposure, task success, wrong-tool calls, premature actions, and token usage. In a controlled evaluation across seven model backends, three tool-menu sizes, six filtering methods, and seven evaluation settings, CMTF improves task success from 32.1% under all-tools exposure to 85.7%, while reducing average token usage by roughly 98%. Causal minimal tool filtering achieves the strongest overall tradeoff, reducing visible tools, wrong-tool calls, premature actions, and risky-tool exposure relative to unfiltered exposure, lexical filtering, state-aware filtering, and broader causal-path baselines. ToolMenuBench provides a reusable evaluation framework for studying the agent-interface problem: which tools should be visible, when they should be visible, and under what cost or risk constraints.

Rahul Suresh Babu, Laxmipriya Ganesh Iyer

Independent Researcher United States of America

AI Agent ReliabilityTool-Use EvaluationTool-Augmented Language Model AgentsLLM Agent EvaluationAI Agent BenchmarksLLM Tool Use+2
AskPDF
Oct 16, 2026

Tool Recommendation for Multi-Step Agents: Finding Every Tool a Task Needs

A multi-step agent task fails when a single tool it needs is missing, yet the tools an agent may need are too many to list: the roughly 8,200 tools on the platform we study have definitions that together exceed the context window of any model we evaluate. We present Tool Recommendation, a deployed system that gives an agent all of them, hundreds of times more than a typical MCP server exposes, through a fixed interface of three tools. It runs at the gateway between agent and tools, executing every call under the end user's own credentials and checking it against the user's consent for each service and the tools the agent may use. We evaluate it on both a public retrieval benchmark and billed end-to-end session cost. On ToolRet, Tool Recommendation places every tool a query needs in the top ten 57% more often than BM25, a lexical ranking that commercial tool search offers, and compares favorably with published systems up to nine times its size. In paired multi-step workflows, its first recommendation covered every required tool in 93% of Codex sessions, and against a fixed list of 100 tools it cut input tokens by 17% with Codex and 40% with Claude Code and the total bill in all 14 runs, by up to 40%, with no change in task completion.

Sam Partee, River Stevens, Thierry Damiba +1

Tool Selection for Language Model AgentsTool Discovery for LLM AgentsLLM Agent Efficiency
AskPDF