DEV Community: Konstantin Kolomeitsev

Cheaper Than Perplexity, but Local — and Works With Any Agent: Agent Browser Workspace

Konstantin Kolomeitsev — Wed, 04 Mar 2026 12:49:41 +0000

If you've used Perplexity Deep Research, you probably know two feelings at once:

1) "Wow, it really digs deep."
2) "Too bad I can't see what's happening inside, intervene, restart a step, or expand the search — it's a black box."

Agent Browser Workspace is not a "one-button SaaS". It's a local toolkit that gives any AI agent (Cursor, your own agent, an LLM orchestrator) a real browser for research.

It runs on your machine, through your Chrome, but in a separate profile. No Docker, no exotic environments.

TL;DR

Cheaper than Perplexity: on DeepResearch Bench we scored 44.37 (RACE overall) on Claude Haiku 4.5 — a model significantly cheaper than typical "frontier" stacks.
Local and transparent: a real Chrome right in front of you — you can stop it, log in, close a banner, restart a step, expand the search, refine the query. As many iterations as you need.
Not just deep research: also a tool for browser automation + content, form, and HTML data extraction.
Extensible: new sites are added as profiles in scripts/sites/*.json — selectors and controls live separately from code and prompts.

What's Inside?

Agent Browser Workspace is a repository with two layers:

1) Low Level (`utils/`)

utils/browserUse.js — control a real Chrome via Playwright: navigation, clicks, input, scrolling (including infinite scroll), screenshots, file and image downloads, JS execution on the page, tabs, CDP.
utils/getDataFromText.js — parse raw HTML without a browser: finds navigation, main content, forms, and converts content to Markdown.

2) High Level (`scripts/`)

Ready-made building blocks for a research pipeline:

getContent — save a page as Markdown + download images and rewrite links to local files.
getForms — find forms, classify them (search/auth/filter/contact/subscribe), and build ready-to-use CSS selectors for filling.
getAll — content + forms in one pass (single HTML snapshot).
googleSearch — step-by-step Google search: query → organic links → open → extract → close tab → pagination.

How This Beats a Typical Deep Research SaaS

1) You Keep Control

With SaaS deep research, you usually see a progress bar and a final result. Here it's different:

The browser is real — not a "virtual screenshot black box".
You can intervene: close a cookie banner, log in, confirm age, adjust a filter.
You can restart a specific step: open the next link, re-extract content, change the wait strategy (SPA/JS rendering), scroll through infinite scroll before extraction.
You can expand endlessly: "add 10 more sources", "double-check the numbers", "add a comparison table", "collect a list of alternatives", "follow the snowball of links".

Research becomes iterative. One failed step doesn't kill the whole process.

2) Artifacts and Reproducibility

Deep research isn't just the final text. It's also the evidence base:

links.json — a stable snapshot of Google results across all queries (you can continue later without re-running searches).
Downloaded pages in Markdown + images/ — sources stay on disk.
insights.md — a cumulative draft (in the RESEARCH.md methodology, this is part of the process).

3) Local, No Extra Infrastructure

No containers, no remote browsers, no special platforms:

npm install
npx playwright install chrome
npm run chrome (starts Chrome with CDP on port 9222)

Three commands — done. Details in INSTALLATION.md.

Extensibility: Site Profiles Instead of Hardcoding

A common pain point in browser agents — selectors break. Sites change their markup, and the agent starts guessing.

Here it's different — through site profiles:

scripts/sites/*.json stores selectors and "controls" (which elements matter, what to do with them).
Scripts return a site field, and the agent uses ready-made selectors without guessing.

Need to support a new site? Add a JSON profile. Google changed its markup? Edit scripts/sites/google-search.json instead of rewriting code.

DeepResearch Bench: Why Numbers Matter

When everyone claims "we have the best deep research", you need an external benchmark.
That benchmark is DeepResearch Bench (DRB) — 100 "PhD-level" tasks, two metrics (RACE/FACT), and a public evaluation methodology.

Links:

Official DRB site: deepresearch-bench.github.io
Repository: Ayanami0730/deep_research_bench

Numbers You Can Verify

On the official DRB page in the Main Results section for the "Deep Research Agent" category (RACE overall):

Gemini-2.5-Pro Deep Research: 48.88
OpenAI Deep Research: 46.98
Perplexity Deep Research: 42.25

And here's Agent Browser Workspace's result:

44.37 (RACE overall) — above Perplexity Deep Research, closer to OpenAI/Gemini, and running on Claude Haiku 4.5 (a model significantly cheaper than "frontier" stacks).

Results have been submitted to the leaderboard and are under review.

Why "44.37 on Haiku" Is More Than Just a Number

Most comparisons forget about cost and controllability.
Here you win on three fronts at once:

1) Quality close to the top (DRB overall near OpenAI/Gemini).
2) Lower cost (Haiku-class models).
3) Control and reproducibility — on your machine, with real artifacts (links.json + downloaded sources).

Try It in 5 Minutes

1) Install

npm install
npx playwright install chrome

2) Start a Local Chrome for the Agent

npm run chrome

3) Save Any Page as Markdown (with Images)

node scripts/getContent.js --url https://example.com --dir ./output --name page.md

4) Deep Research: Google → Open → Save Source

# Stable snapshot of search results (links.json)
node scripts/googleSearch.js "best AI newsletters 2026" --links --dir ./archive/my-research

# Open result 0 and save content
node scripts/googleSearch.js "best AI newsletters 2026" --open 0 --dir ./archive/my-research --name source-0.md

PDFs are supported too: if a .pdf shows up in the results, getContent/googleSearch automatically extract the text.

When a Site Looks "Empty" (SPA, JS Rendering, Lazy-Load)

The classic failure of "fast" web scrapers: the HTML arrives, but there's no content.

The project has an escalation path (details in AGENTS.md):

gotoAndWaitForContent() — wait for the DOM to stabilize after JS rendering
evaluate(() => document.body.innerText) — pull visible text directly
scroll({ times: N }) — load lazy content or a feed
screenshot({ fullPage: true }) — if text isn't accessible programmatically

The logic is simple: the page matters — don't skip it — escalate the extraction level.

Not Just Deep Research: Where Else It Helps

1) Product and Marketing Research

You can collect search results, lock down links.json, save 30–60 sources as Markdown, then ask the agent to "expand / compare / double-check / build a table" using local artifacts.

2) Web Routine Automation

3) Form Discovery and Ready-Made Selectors

getForms finds forms and fields, returns ready-to-use CSS selectors.
From there, the agent calls browser.fill() or browser.fillForm() without guessing.

Why "Local + Observable" Is a Big Deal

Closed deep research products work well when you need a quick answer.
But if you're working with research, business decisions, sources, verification, and iterations — you need a different mode:

observe,
pause,
fix obstacles,
restart steps,
add depth,
refine the report,
keep going until the result is right.

That's what Agent Browser Workspace is about.

Where to Read More

GitHub: k-kolomeitsev/agent-browser-workspace
Tool overview and working rules: AGENTS.md
Installation and QOL instructions (profiles/shortcuts/checks): INSTALLATION.md
Deep research methodology: RESEARCH.md

If you'd like to contribute to the open source project — here are the most impactful areas:

new and improved site profiles in scripts/sites/
better content extraction on tricky sites (SPA, paywall overlays, lazy rendering)
smarter form and field detection rules

Made it this far? Star the repo — it's the best way to help the project grow.

DSP (Data Structure Protocol): how to give LLM agents "long-term memory" of a large repository

Konstantin Kolomeitsev — Fri, 20 Feb 2026 13:42:49 +0000

There’s a pattern everyone who works with agents recognizes: the first 5–15 minutes are spent not on the task, but on “getting oriented.” Where is the entry point? Where do the dependencies come from? Why this library and not another one? Who considers this a public API? In a small project it’s annoying. In a large one, it becomes a constant tax on tokens and attention.

DSP (Data Structure Protocol) “externalizes the project map” — into a simple, versioned, language-agnostic graph that lives alongside the code and is available to the agent as persistent memory.

k-kolomeitsev/data-structure-protocol

The goal is phrased in the architecture like this:

1) Goal and scope

The goal of DSP is to store minimal, but sufficient context about a repository / artifact system as a graph “entities → dependencies / public API”, so that an LLM can:

- quickly locate the necessary fragments by UID,
- understand why entities exist and how they are connected,
- avoid having to load the entire source tree into the context window.

DSP is long-term memory and an index of the project for an LLM. At any time, the agent can run a project-wide search (grep), find the required entities by descriptions/keywords, and from the found UID expand the entire relationship graph: incoming dependencies, outgoing imports, and consumers via `exports`. This replaces the need to “remember” the project structure or load it in full — the entire project map is always available through `.dsp`.

What DSP is, in essence

DSP = an entity graph + the reasons behind connections

DSP is stored in the .dsp/ directory. Each “entity” gets a stable UID and a small set of files:

description: where it is (source), what it is (kind), why it exists (purpose).
imports: what this entity uses (UID references).
shared: what it exposes as a public API (exports).
exports/: a reverse index — who imports this entity and why (the why text next to each consumer).

In large systems, one detail matters especially: DSP captures not only “what depends on what,” but also why. This drastically reduces guesswork in refactoring, migrations, and legacy removal.

There are only two base entity types

Object: module/file/class/config/resource/external dependency — “everything that isn’t a function.”
Function: function/method/handler/pipeline.

Another bonus: DSP is language-agnostic. It works the same across TS/JS, Python, Go, infrastructure YAML, SQL, assets, and so on. The architecture also explicitly defines “import completeness”: if something is imported, it must exist in .dsp, including styles, images, JSON, wasm, and other artifacts. This matters more than it seems: agents more often lose not code, but resource dependencies.

Why UID is the central idea

DSP is built on identity by UID, not by path. A path is an attribute. A UID is an entity’s “identity.”

Renamed a file → run move-entity, the UID stays the same.
Moved code around / reformatted → the UID stays the same.
A UID changes only when the purpose (semantic identity) changes: the module truly became “about something else.”

To attach a UID to entities inside a file (exported functions/classes), DSP uses a simple marker comment @dsp <uid> right in the source code. It’s a pragmatic choice: it doesn’t depend on line numbers, works in any language, and is easy to find with grep.

How an agent “walks” DSP instead of endlessly reading code

A typical agent workflow in a DSP-based project looks like this:

Find an entity: search by keywords, or find-by-source by file path.
Understand the boundaries: read description, shared, imports.
Pull context in batches: instead of “give me the whole repo,” the agent fetches only the nodes it needs plus 1–2 levels of dependencies.
Estimate impact: who consumes the entity and why (get-parents / get-recipients), whether there are cycles, whether there are “orphans.”

Example commands (PowerShell style; the CLI is shipped inside the skill):

python .\.claude\skills\data-structure-protocol\scripts\dsp-cli.py --root . search "authorization"

python .\.claude\skills\data-structure-protocol\scripts\dsp-cli.py --root . get-entity obj-a1b2c3d4
python .\.claude\skills\data-structure-protocol\scripts\dsp-cli.py --root . get-children obj-a1b2c3d4 --depth 2

python .\.claude\skills\data-structure-protocol\scripts\dsp-cli.py --root . get-recipients obj-a1b2c3d4
python .\.claude\skills\data-structure-protocol\scripts\dsp-cli.py --root . get-path obj-a1b2c3d4 func-7f3a9c12

What the `data-structure-protocol` skill adds (and why it’s more important than it seems)

DSP architecture is a set of rules. But without discipline an agent can easily violate them: poke the code at random, drag half the repo into the context, forget to update the index, and break graph integrity.

The skill covers exactly the operational part:

It embeds an Agent Prompt: “before changing anything — find the entities; when creating — register; when importing — add why; when deleting — perform cascade cleanup.”
It provides reference materials in references/: the storage format, the bootstrap algorithm (DFS from entry points), the semantics of operations.
It ships a production-ready CLI scripts/dsp-cli.py that implements the operations from ARCHITECTURE.md and supports navigation/diagnostics (cycles/orphans/stats).

DSP becomes not a “document,” but a living contract that the agent executes while working — and keeps .dsp consistent without manual intervention.

Cost of adoption: bootstrapping a large project will be expensive

Yes. The initial bootstrap on a large repository is expensive — in time, attention, and tokens.

Why:

You need to identify the root entry points (and there are many in a monorepo).
You need to traverse dependencies depth-first (DFS) and record all reachable modules/files/resources.
For each node, you need to write a minimal, but precise purpose.
You need to fill in the reasons (why) for import edges in a disciplined way — otherwise half of DSP’s value disappears.
Sometimes you need to add @dsp markers in source files for exported entities (so the UID becomes an “anchor” in code).

On large systems, this can realistically be its own mini-project.

Why it pays off (and usually pays off faster than it seems)

The value of DSP is not “a pretty structure.” It’s in the economics of agent work:

Fewer tokens spent on orientation: instead of repeatedly “warming up” context, the agent reads short description/imports/shared/exports and pulls exactly the files that need to be changed.
Context doesn’t dissolve between tasks: .dsp is external memory that doesn’t depend on the current context window or the model’s “mood.”
Fast semantic lookup: search finds entities by keywords, and exports/ answers the question “why is this even here.”
Refactoring becomes safer: impact analysis gets cheaper — you quickly get all consumers of an entity and update them precisely.
External dependencies become transparent: external packages are captured as kind: external, without bloating the graph, but they remain navigable via the exports index.

And here’s an important point from the architecture — granularity control, so DSP doesn’t turn into a junk drawer:

10) Granularity and minimal-context policy

- Completeness at the file level, not at the code-within-file level. “Import completeness” (section 2) means that every file/module that is imported in the project must have an Object in `.dsp`. This is about files and modules — not about every variable inside a file. Within a single file, a separate UID is assigned only to an entity that is shared externally (`shared`) or used from multiple places. Local variables, internal helpers, private fields — remain part of the parent Object, without their own UID. If granularity keeps growing, something is being done wrong.

- Update consumers via `exports`. To update a library/module/symbol, it’s enough to open `exports` of the imported entity and get the list of importers (consumers) by UID, then update them precisely.

- Change tracking. `git diff` shows what changed — a new file was created, a function or object changed. The changed files are passed to the LLM to update DSP. Changes inside functions often don’t require updating DSP, because descriptions capture purpose, not implementation details — unless imports were added/removed.

This is what makes DSP viable over time: the index stays compact, and updates stay rare and meaningful.

When DSP really shines

Large monoliths and monorepos, where the context “never fits.”
Long-lived products, where agents will work for months and years, not just one sprint.
Teams that frequently do refactors/migrations/dependency replacements.
Projects with a complex resource layer (assets/configs/generation) that is hard for agents to keep in their heads.

Conclusion

DSP is an attempt to do for LLM agents what people have long done informally: keep a mental map of a system. Only instead of a head — a graph on disk; instead of “that’s how I remember it” — minimal descriptions, connections, and reasons; instead of “read the whole project” — targeted navigation from entry points.

Yes, bootstrapping a large project will be expensive. But if you truly plan to use agents systematically, this cost typically comes back through:

fewer tokens spent on orientation,
less context loss between tasks,
faster discovery of the needed modules/dependencies,
more predictable task execution (especially refactoring work).

Autonomous AI Employee

Konstantin Kolomeitsev — Tue, 14 Oct 2025 19:17:20 +0000

This is a repost of my article on LinkedIn.

The main dream of modern AI investors is an autonomous AI employee who can fully replace certain specialists and work without any external intervention.

In my view, this is already quite an achievable goal with the current level of technology.

Let me give an example from a field close to me — programming (though this approach is applicable to most digital professions). Let’s build an autonomous AI middle-level backend developer.

We’ll set it up on a local server machine, inside the company’s internal network.

Right away, I’ll say that I will not be sharing my code, configurations, or workflows publicly. My goal is to provide a high-level overview of a solution that works for me, because I see not just a gap, but a complete lack of materials of this kind — even at such a surface level of detail.

Preparation

First, we’ll need a complete Job Description for the employee, the data they need to know, the tasks they need to perform, and the communication channels through which they can interact. Fortunately, remote work has done its job — everyone has learned to communicate digitally.

Next, we formalize access:

to Git — via SSH keys,
to Confluence and Jira — via API keys,
tokens for Telegram, Slack, or other tools (email, or any other communication channels).

We record all of this into a simple JSON configuration file located in the working directory where the employee (agent) will operate — the agent’s root directory.

We install Docker on the server and launch the following services:

n8n (for workflow orchestration),
a vector database, and
a relational database like PostgreSQL.

We also grant n8n access to the working directory.

Configuration

Now we configure communication channels.

In n8n, we add triggers for the required channels so that incoming messages are routed to our agent, who can then return responses.

But instead of calling a regular LLM model, we’ll use a hook or custom node that invokes our local agent.

The Agent

The most complex part is developing the agent itself.

However, a level of “agentness” similar to that of Cursor is already more than sufficient — the key is to craft the prompts methodologically correctly.

Another important step is setting up MCP tools for the agent — such as modules for searching and scraping information, and for working with Jira, Confluence, Git, and so on. This gives our AI employee “hands” and “eyes.”

A RAG (Retrieval-Augmented Generation) mechanism is also essential — for memorizing important things such as:

how to correctly solve a particular type of task,
or how to properly find a specific kind of information.

The agent itself can determine what is important using a simple prompt such as:

“Highlight successful solutions from the current session for future memorization.”

This allows our AI employee to accumulate experience.

The relational database is needed to store “behavioral rules,” for example:

when a supervisor says “don’t do it that way again”, or
conversely, “do it like this instead.”

Methodology

This is the most important — and probably the most extensive — part of the work: formalizing the working methodology of our employee (ideally, all of this should already be reflected in the Job Description).

The workflow consists of two main stages:

Populating the RAG with key knowledge — essentially, we “load” the onboarding process into the RAG.
Scheduling — in n8n, we configure cron triggers so that, for example, at 9 a.m. the agent:

- logs into Jira,

- checks for new tasks assigned to them,

- analyzes them, and

- either starts working on them or leaves a comment.

How It All Works

Let’s look at an example with our AI middle developer:

Logs into Jira according to schedule and pulls assigned tasks.
Checks each task for completeness and feasibility — if something is missing, leaves a comment.
Verifies the required environment — network access, code access, Git permissions, etc.
Executes the task.

With a well-written description, Cursor already handles 100% of middle-level developer tasks for me (if yours doesn’t — either the context completeness or prompt quality is lacking).
Tests locally using Playwright MCP or Postman.
Pushes the result to dev, verifies the deployment pipeline.
If there are errors — comments in Jira, possibly messages the DevOps engineer, and rolls the task back.
If all goes smoothly — rechecks on dev.
Moves the task forward, comments in Jira, team chat, or other configured channels.
Instead of daily stand-ups, can automatically:

- compile info from **Jira** about yesterday’s tasks,

- pull commits from **Git** related to those tasks,

- send a daily report, and

- note failed tasks and explain why.

Can reply to messages in Telegram, Slack, and other communication channels.
Can even, based on memorized experience and code analysis, advise junior developers or testers.

At this point, what we have is already a fairly reliable and high-quality middle-level developer, better than the average on the market.

Conclusion

Of course, much depends on the model used by the agent — but nothing prevents us from experimenting with different options to find the optimal balance between quality, cost, and speed.

It is also very important to carefully design the methodology of operation, to account for various behavioral scenarios of the model.

We should not forget about safeguards — to prevent the agent from looping or drifting into endless, meaningless reasoning.

However, if the agent is well designed, those safeguards will already be in place.

Even though this is a pseudo-architecture, I have already managed to run many of the described components locally.

That’s all for now — thank you for your attention.

Hiring Programmers v2. Tips from a Programmer

Konstantin Kolomeitsev — Fri, 16 May 2025 17:35:36 +0000

Hi, friends! I once shared my thoughts on how to hire developers.

Since then, a lot has changed: artificial intelligence has confidently entered the life of IT teams, and the task of recruiting employees has become even more complicated.

Modern “recommendations” from recruiters and managers have begun to descend into an absurdity that is very sad to watch.

Important: Below is my personal opinion, proven in practice and shared by my fellow programmers.

Stage One: Interview Without a Technical Specialist

I won’t tire of repeating that the HR’s task at this stage is to weed out the inadequate—people unable to perform assigned tasks and generally not focused on work (there are plenty of them).

Just talk human-to-human, probe the candidate’s soft skills, assess their behavior, and ask about motivation. Don’t turn the conversation into an exam—simply form an impression that you will later pass on to the candidate’s future manager.

What you need to find out: whether the person will fit into the team, whether they will be able to work productively, and whether they will obtain the desired return—be it income, recognition, or interesting projects.

Do not try to dive into technical nuances; it looks out of place and helpless. And no ChatGPT will help you if you don’t understand what you are asking about.

What else can you ask?

For experienced specialists: ask them to talk about projects they worked on, what difficulties they encountered, and how they solved them.
For juniors: offer a couple of simple logic puzzles to see how the person thinks.

This information is usually enough to filter out 80–90 % of applicants.

Stage Two: Conversation with a Techie

Do not ask dry theory unrelated to the candidate’s experience. I know people who could recite textbooks by heart yet couldn’t write working code.

It’s better to discuss real tasks from their experience, especially those similar to the ones you have. From their story you will immediately see:

whether the person understands the topic;
whether their experience matches your requirements;
whether they can cope with new tasks;
whether they can learn quickly.

How to Deal with Vibe Coders?

Not all vibe coders are the same. If all someone can do is paste a prompt into Cursor and run whatever the AI spits out, then of course nobody needs such a person.

But if they can design the structure of a future program themselves, know how to ask the neural network to write the required code, understand what the assistant has generated, and can immediately fix the wrong parts by hand—then such a person is quite valuable. They already possess the basics of application architecture, can read code, and, at the very least, are a good prompt engineer, because getting the desired result from a neural network is not that simple.

Attitude Toward AI at Work

I believe developers should be better at using AI than anyone else.

The question is how they use it. It’s the same story as with vibe coders: if someone pushed changes without even running their own code, let alone linting it, you can hardly call that person a professional.

But if they leverage AI to handle boring, monotonous tasks, then, in my view, their value only increases, because they can close the same tasks faster thanks to smart assistants.

Therefore, be sure to clarify whether candidates use AI in their work, how they use it, which tools they use, for what purposes, and why.

Usually this set of questions is enough to make a decision.

You will learn more about a person only during the probation period.

I hope these notes prove useful. Thank you for reading!

PTTJS — A Text‑Based Format for Complex Tables

Konstantin Kolomeitsev — Sun, 11 May 2025 17:34:23 +0000

PTTJS (Plain Text Table JavaScript) is a table format I created to solve my own pain points—and, judging by the feedback I’ve already received, I’m not the only one who has felt the limitations of existing text‑table formats.

A JavaScript library with a parser + serializer and an Obsidian plugin are already available.

Goal

The main goal of PTTJS is to provide a text format that can faithfully store complex tables—far beyond what CSV or Markdown can handle—while still remaining human‑readable.

Motivation

I tolerated the shortcomings of other formats for a long time, but eventually the trade‑offs became impossible to ignore. Key drivers were:

Feeding richer tables to LLMs. Documents often contain intricate, merged‑cell tables that can’t be flattened to CSV/Markdown, forcing us to reach for heavier multimodal models.
Extracting tables via CV into plain text, not into a deeply nested JSON blob that’s unreadable until you re‑render it.
Letting an LLM manipulate an entire table natively—rows, columns, formulas—without shoe‑horning everything through Google Sheets or Excel.
Opening tables without special software. Most tables end up trapped in XLS(X) or ODT; PTTJS keeps them plain text.
Editing complex tables in plain‑text tools like Obsidian.
Personal dislike of Google Sheets/Excel (surely I’m not the only one!).

the problem is indicated in points 1 and 2, the format is recognized normally and inserted into the text

Format Overview

The very first line is always an annotation:

|PTTJS 1.0|encoding=UTF‑8|

Pages

A table can span multiple pages:

|(@P1|Page Name){
    …table data…
}|

Page markers are optional; omit them and the whole table lives on a single page.

Cells

Every cell starts with | and ends with >:

|H([1|1]1|1|@C1)>

H — optional marks a header cell
([X|Y]) — zero‑based cell index (optional; auto‑filled if absent)
(X|Y) — cell span (defaults to 1|1; always declared in the top‑left merged cell)
(@ID) — cell id for references

Row ends with:

<|

If a row is otherwise empty but you still have rows below it, include at least one empty cell: |><|.

Forbidden characters inside cell content (\n | > < { }) must be URL‑encoded:

\n  → %5Cn
|   → %7C
>   → %3E
<   → %3C
{   → %7B
}   → %7D

The library provides escapeValue / unescapeValue helpers.

Scripts

>>>SCRIPT
…typings, formulas, styling…
<<<SCRIPT

Always placed after all table data.
Can work across pages.
Use <= for CSS‑like styles.
Use => for cell typings.
Use = for formulas.
Target a range with :—e.g. 0:0|0 (whole first row) or 0|0:0 (whole first column).

The cells always contain up-to-date information. When we add a script, it recalculates the table data and adds the up-to-date information to the cells.

Examples

1 – Basic Table

|PTTJS 1.0|
|H>Plate Number|H>Year|H>Make & Model<|
|>080XXX02|>2005|>LEXUS RX 350<|
|>787XXX16|>2015|>GEELY GC7<|
|>871XXX05|>1997|>TOYOTA IPSUM<|
|>A602XXX|>1996|>MITSUBISHI PAJERO<|
|>890XXX02|>1997|>TOYOTA LAND CRUISER PRADO<|
|>216XXX13|>2007|>DAEWOO NEXIA<|

2 – With Explicit Indexes

|PTTJS 1.0|encoding=UTF‑8|
|H([0|0])>Plate Number|H([1|0])>Year|H([2|0])>Make & Model<|
|([0|1])>080XXX02|([1|1])>2007|([2|1])>LEXUS RX 350<|
…

3 – Complex Header (Merged Cells)

|PTTJS 1.0|encoding=UTF‑8|
|H(1|2)>Plate Number|H(2|1)>Vehicle Data|H><|
|H>|H>Year|H>Make & Model<|
|>080XXX02|>2007|>LEXUS RX 350<|
…

visualization from Obsidian

4 – With Scripts

|PTTJS 1.0|encoding=UTF‑8|
|H([0|0])>Plate Number|H([1|0])>Year|H([2|0])>Make & Model<|
|([0|1])>080XXX02|([1|1])>2007|([2|1])>LEXUS RX 350<|
…
|([0|7])><|
|([0|8])>Average Year|([1|8])>2003<|

>>>SCRIPT
(1|1,1|6)=>NUMBER(2,' ')
(1|8)=DIV(SUM(1|1,1|6),COUNT(1|1,1|6))
(0|8:8)<=BORDER(each,2,solid,#000)
<<<SCRIPT

Row 9 calculates the average year; numeric formatting is applied; a black 2 px border is added to the "Average Year" label cell.

Roadmap

Execute script functions directly on the parsed Store object.
Import/export converters (XLS(X), ODT, CSV, MD ↔ PTTJS).
Libraries in other languages.
Lightweight web UI for editing PTTJS.

Contributing

The GitHub repo is public—PRs and ideas are very welcome!

Final Words

Thanks for reading! I hope PTTJS helps you tackle the same table woes I faced. Feel free to reach out, fork the repo, or open an issue—let’s make complex tables easy together.

DEV Community: Konstantin Kolomeitsev

Cheaper Than Perplexity, but Local — and Works With Any Agent: Agent Browser Workspace

TL;DR

What's Inside?

1) Low Level (utils/)

2) High Level (scripts/)

How This Beats a Typical Deep Research SaaS

1) You Keep Control

2) Artifacts and Reproducibility

3) Local, No Extra Infrastructure

Extensibility: Site Profiles Instead of Hardcoding

DeepResearch Bench: Why Numbers Matter

Numbers You Can Verify

Why "44.37 on Haiku" Is More Than Just a Number

Try It in 5 Minutes

1) Install

2) Start a Local Chrome for the Agent

3) Save Any Page as Markdown (with Images)

4) Deep Research: Google → Open → Save Source

When a Site Looks "Empty" (SPA, JS Rendering, Lazy-Load)

Not Just Deep Research: Where Else It Helps

1) Product and Marketing Research

2) Web Routine Automation

3) Form Discovery and Ready-Made Selectors

Why "Local + Observable" Is a Big Deal

Where to Read More

DSP (Data Structure Protocol): how to give LLM agents "long-term memory" of a large repository

What DSP is, in essence

DSP = an entity graph + the reasons behind connections

There are only two base entity types

Why UID is the central idea

How an agent “walks” DSP instead of endlessly reading code

What the data-structure-protocol skill adds (and why it’s more important than it seems)

Cost of adoption: bootstrapping a large project will be expensive

Why it pays off (and usually pays off faster than it seems)

When DSP really shines

Conclusion

Autonomous AI Employee

Preparation

Configuration

The Agent

Methodology

How It All Works

Conclusion

Hiring Programmers v2. Tips from a Programmer

Stage One: Interview Without a Technical Specialist

Stage Two: Conversation with a Techie

How to Deal with Vibe Coders?

Attitude Toward AI at Work

PTTJS — A Text‑Based Format for Complex Tables

Goal

Motivation

Format Overview

Pages

Cells

Scripts

Examples

1 – Basic Table

2 – With Explicit Indexes

3 – Complex Header (Merged Cells)

4 – With Scripts

Roadmap

Contributing

Final Words

1) Low Level (`utils/`)

2) High Level (`scripts/`)

What the `data-structure-protocol` skill adds (and why it’s more important than it seems)

PTTJS — A Text‑Based Format for Complex Tables

1 – Basic Table

2 – With Explicit Indexes

3 – Complex Header (Merged Cells)

4 – With Scripts