The Oblivious Robot https://drdebmath.github.io/blog/ A blog by Dr. Debasish Pattanayak on distributed algorithms, swarms of robots, research and writing with AI. en CC BY 4.0, Debasish Pattanayak Sat, 26 Sep 2026 00:00:00 +0000 Writing Papers When Your Co-author* Has No Memory† https://drdebmath.github.io/blog/p/co-author-with-no-memory.html https://drdebmath.github.io/blog/#co-author-with-no-memory Sat, 26 Sep 2026 00:00:00 +0000 A checklist for writing research papers with an AI co-author: literature search, glossary, phrase bank, structure and polish, and where AI helps at each step. * The co-author with no memory is the AI agent (simply "the AI" below), or your oblivious supervisor. Either way, every session starts from scratch, so the glossary, the phrase bank and the structural rules below have to be handed over each time.

† I was talking about this with my students, and wrote it down here so they can find it again and refer back to it.

Most advice about writing papers is about sentences. Most problems in papers are about something else: a term used three pages before it is defined, an algorithm shown as pseudocode with no idea behind it, a proof that says "this implies that" without saying what *this* is. None of these are problems of talent. They are problems of process, and process can be learned. The process below works in passes. Each pass has one job: first prepare, then structure, then polish. AI is now good enough to help with every pass, but only if you know what the pass is for. So this post first describes the passes, then where AI fits into each one.
## Prepare: literature, glossary, phrase bank
Start by **searching the literature**. This is not only about citing related work. Knowing what has been done tells you what your contribution actually is, and it shows you the vocabulary your community already uses. A paper that invents its own words for standard ideas makes readers translate before they can understand. Tools that show papers as a network of citations help here: [Connected Papers](https://www.connectedpapers.com/) and [Research Rabbit](https://www.researchrabbit.ai/) show which papers cite which, and [Elicit](https://elicit.com/) finds and summarizes papers that answer a research question. Next, **build a glossary**: a running list of every technical term in the paper, each with a one-line definition. The glossary forces a decision: one term for each concept. Once you have called something a *round*, it is never a *step* or a *phase* two sections later.
Example: a glossary for Asynchronous Dispersion with Optimal Time Complexity
Condensed from [the paper](https://arxiv.org/abs/2507.01298) (Pattanayak, Kshemkalyani, Kumar, Molla and Sharma, ICPP 2026). | Term | Meaning | |---|---| | Graph | $G = (V, E)$ is simple, undirected and connected, with $n$ nodes, $m$ edges and maximum degree $\Delta$. | | Anonymous graph | Nodes have no unique identifiers. | | Port-labeled graph | At each node $v$, the incident edges carry distinct local labels (ports) $1, \dots, \delta_v$. The port at $u$ of edge $\{u, v\}$ is $p_{uv}$, and in general $p_{uv} \neq p_{vu}$. | | Agent | One of $k \le n$ mobile agents $a_1, \dots, a_k$, each with a unique ID in $[1, k^{O(1)}]$. | | Dispersion | The agents relocate until no node hosts more than one agent. | | Rooted / general configuration | Initially, all agents are on one node / on at least two nodes. | | Local model | An agent communicates only with agents at the same node. | | CCM cycle | Communicate–Compute–Move: read the memory of co-located agents, compute, then write memory and exit through a port. | | $\mathcal{SYNC}$ / $\mathcal{ASYNC}$ | Agents activate in common rounds / at arbitrary times, with every agent active infinitely often and every cycle finishing in finite time. | | Epoch | A minimal interval in which every agent completes at least one CCM cycle. *Time* means rounds in $\mathcal{SYNC}$ and epochs in $\mathcal{ASYNC}$. | | Memory complexity | The number of bits an agent stores from one CCM cycle to the next. | | Settled agent, $\psi(x)$ | The agent that stays at node $x$. Its ID stands in for the ID of the node. | | Edge type | t11, tp1, t1q or tpq: whether the edge has port 1 at both ends, only the far end, only the near end, or neither. | | Port-one tree (P1Tree) | A tree in which every vertex has an incident tree edge of type t11, tp1 or t1q. | | DFShead | The group of agents leading the depth-first search. | | Vacated node | A visited node whose settled agent (a *settled scout*) travels with the DFShead, and returns in the retrace phase. | | Parallel probing | Neighborhood search in which the agents at the DFShead probe the ports of the current node in parallel. |
Then **build a phrase bank**, a small set of fixed phrasings for the things you say again and again. In a paper about mobile agents on graphs, that might be: > the agent moves from node $u$ to node $v$ Use that exact phrase every time, never "the agent goes to the neighbor" in one place and "node $v$ is reached" in another. Repeated wording can feel dull to write, but it is restful to read: the reader stops parsing sentences and starts following the argument.
## Structure: the order in which ideas arrive
A reader meets ideas one at a time, in the order you chose. Structure is about choosing that order well. **Define terminology before using it.** This sounds obvious and is violated constantly, usually because a definition got moved during revision. The glossary helps here: for each term, check that its first use comes after its definition. **Use connectives.** Words like *However* and *Thus* are the joints of an argument. They tell the reader whether the next sentence contrasts with, follows from or merely adds to the previous one. Without them, the reader has to guess the logic. **Present each algorithm in layers**, from the outside in: 1. the high-level idea, in a few sentences; 2. a detailed description in prose; 3. the variables: what each one holds and how it changes; 4. the pseudocode; 5. the correctness proof. A reader who stops after the first layer still leaves with something. A reader who goes all the way reaches the pseudocode already knowing what it is meant to do. **Split the algorithm into small functions or procedures.** Each piece can then be described, and proved correct, on its own. A proof that says "by Lemma 3, `Explore` terminates" is much easier to check than one that reasons about a single hundred-line procedure. **Put motivation before results.** Tell the reader why a problem matters before telling them what you achieved. The same rule shapes a good abstract, so follow an abstract-writing guide when you write yours. A good one is Neel Nanda's [Highly Opinionated Advice on How to Write ML Papers](https://www.alignmentforum.org/posts/eJGptPbbFPZGLpjsp/highly-opinionated-advice-on-how-to-write-ml-papers). Its annotated abstract shows the job of each sentence.
## Polish: removing every chance to misread
The last pass is about ambiguity: every place where a careful reader could take a sentence two ways. **No "this" or "that" as a reference.** Name the object precisely. Compare: > *Before:* It then moves there, and this guarantees termination. > > *After:* The agent then moves from node $u$ to node $v$. The move from node $u$ to node $v$ guarantees termination. The second version is longer and cannot be misread. **No two terms for the same thing.** If the reader sees *robot* in one paragraph and *agent* in the next, they will reasonably wonder whether these are different entities. **Add reminders.** In a long paper, readers forget. Short signposts, like *Recall that …* or *As shown in Section 3, …*, cost a few words and save the reader from flipping back. **Check figures and references.** A figure should appear on the same page where it is first referred to, or on the next page. Give each figure a detailed caption, so it can be understood without hunting through the text for an explanation. A LaTeX trick for placement: put each figure in its own file and include it with `\input{figures/p1tree}`. That one line decides where the figure lands, so move it up or down in the source until the figure sits on the right page. **Simplify proofs wherever you can.** A shorter proof is easier to check, easier to trust and harder to get wrong. If a case analysis can be replaced by one invariant, replace it.
## Where AI fits
The rule for every pass is the same: **AI proposes, you verify.**
- **Literature search.** AI can produce references to papers that do not exist, so every citation needs checking. One way to verify a whole bibliography: ask the AI to take each reference from [dblp](https://dblp.org), then use the DOI to find the actual paper and check the metadata (authors, title, venue, year) against your entry. Do this for all your references. - **Glossary.** A glossary can be built up across several projects rather than from scratch for each paper. For consistency, anchor it to a reference paper or book in your area and follow its terms. The AI can then check a draft against it: ask it to list every technical term, where it is first used and where it is defined, and to flag pairs of terms that seem to mean the same thing. - **Phrase bank.** The phrase bank is a meta thing: technical phrases hide inside ordinary-looking sentences, so read the draft line by line to identify them. Then give the AI reference phrases, so that it knows moving from $a$ to $b$ is a technical phrase with a fixed form, not wording to paraphrase. Read its changes; don't accept them wholesale. - **Structure.** Specify structural requirements at the beginning, before the AI drafts or revises anything: terms defined before use, the five layers for each algorithm, motivation before results. Afterwards, check with concrete questions, such as *Which terms are used before they are defined?* The AI is a dependable reviewer when the question is this specific. - **Polish.** Polishing works as find-then-generalize: find one instance of a problem yourself, such as an unclear "this" or two terms for the same thing, then ask the AI to find all such instances and disambiguate each one. For proofs, the AI can suggest a simpler argument, but you must check every step yourself. A proof that reads well and a proof that is correct are not the same thing.
### Prompts to copy
Replace the parts in square brackets. **Verify references** ```text For each reference in the bibliography below, find its dblp entry and its DOI. Open the DOI and check that the authors, title, venue and year match my entry. List every mismatch and every reference you could not find. Do not guess. [paste the .bib file] ``` **Check terms against the glossary** ```text Here is my glossary, then my draft. List (1) every technical term in the draft that is not in the glossary, (2) every term used before it is defined, with where it is first used and where it is defined, and (3) pairs of terms that seem to mean the same thing. Do not rewrite anything. Glossary: [paste] Draft: [paste] ``` **Keep fixed phrases fixed** ```text These are fixed technical phrases in my paper. Never paraphrase them. Wherever the draft says the same thing in other words, replace it with the fixed phrase, and list each change. Phrases: [paste] Draft: [paste] ``` **Set the structure first** ```text Follow these rules for everything you write or revise: define every term before its first use; present each algorithm as high-level idea, detailed description, variables, pseudocode, correctness proof; state the motivation before each result. If the draft breaks a rule, tell me where instead of silently rewriting it. ``` **Find all instances of one problem** ```text Here is one problem in my draft: "[quote the sentence]". The problem is [for example: "this" does not name what it refers to]. Find every other instance of the same problem in the draft, and for each one propose a rewrite that names the precise object. Draft: [paste] ```
**Disclosure.** Venues increasingly ask how AI was used. A declaration like the one at the top of this post, kept as you work, makes that easy.
None of this replaces thinking about the problem. What AI can take over is the mechanical part of careful writing: consistency checks, reference hunting and first drafts of prose. That leaves more time for the part only you can do.
## More reading
- Neel Nanda, [Highly Opinionated Advice on How to Write ML Papers](https://www.alignmentforum.org/posts/eJGptPbbFPZGLpjsp/highly-opinionated-advice-on-how-to-write-ml-papers) (2025): paper structure, and an annotated abstract that shows the job of each sentence. - Leslie Lamport, [How to Write a 21st Century Proof](https://lamport.azurewebsites.net/pubs/proof.pdf) (2012): hierarchically structured proofs, a method that makes it harder to prove things that are not true. - Leslie Lamport, [How to Write a Proof](https://lamport.azurewebsites.net/pubs/lamport-how-to-write.pdf) (1993): the original case for structured proofs.
Original input

Lightly edited for coherence: editing instructions removed, the author's own later corrections applied, and capitalization and punctuation fixed.

Checklist:

- Search literature - Build glossary - Build phrasing - agent move from node $u$ to node $v$ - Structure - define terminology before using - Connectives - However, Thus, - Algorithms - High level idea - Detailed description - Variable details - Pseudocode - Correctness proof - Split the algorithm into small functions/procedures - motivation follows before result - follow the abstract writing guide - Polish - remove ambiguity - no this or that type of reference (use precise reference to an object, e.g., node $u$ ) - no two terms meaning the same thing - add reminders - e.g., recall that, ...; in the section <no>; - ensure that figures and references are correct - Figures appear in the same page or the next page they are referred to - write detailed captions for the figures - Simplify proofs wherever you can

Notes on using AI at each step:

1. Lit search can be verified by asking AI to take the references from dblp; then use DOI references to actually find the paper and verify the metadata for all your references. 2. Glossary can be built throughout several projects, but use a reference paper or a book for consistency. 3. Phrase bank is a meta thing. Read line by line to identify these. Give the models some reference phrases so that they know "moving from a to b" is a technical phrase. 4. Structural changes can be specified in the beginning. 5. Polish is finding something and asking AI to find all such things and disambiguate.

On why this post exists, and its title:

This post is something I was talking about with my students. I just wrote it so that they can find it again and again and refer to it. The co-author is the AI agent, or your oblivious supervisor.
]]> The Oblivious Robot Why did I start blogging again? https://drdebmath.github.io/blog/p/why-did-i-start-blogging-again.html https://drdebmath.github.io/blog/#why-did-i-start-blogging-again Sat, 26 Sep 2026 00:00:00 +0000 Why I started blogging again, what to expect here, and why this blog is called The Oblivious Robot. I used to [blog](https://drdebmath.blogspot.com/), and then I stopped. What changed is that blogging is enjoyable again, because I am no longer doing everything from scratch. Tasks that would have taken weeks before, like designing custom CSS for each post, I can now ask AI to do in seconds. This post, for example, has its own Pokémon theme. I always want to write about things, and, as usual, I have a high friction of starting. Some external motivators just tip this slightly in favor of getting it published.
When the cost of the boring parts drops to nearly zero, a small nudge is enough.
## What to expect
Expect my thoughts about research, the coming AI singularity, predictions about the future, and how to adapt to the new age.
## Why now
This blog grew out of conversations with my students. The post on [writing research papers with AI](#co-author-with-no-memory) is something I was talking about with them. I wrote it down so that they can find it again whenever they need it and keep referring back to it, instead of relying on what they remember from our conversations.
Advice given in a meeting is gone by the next deadline. Advice written down can be linked, reread and improved. So this is where the things worth repeating will go.
## Why "The Oblivious Robot"
In distributed computing, robots are often studied in the *Look–Compute–Move* model. In each round a robot looks at its surroundings, computes where to go, and moves there. An **oblivious** robot is the most forgetful kind: it keeps no memory from one round to the next. Everything it does has to follow from what it can see right now.
This blog is the memory the robot obtains, before it forgets again.
Original input

Lightly edited for coherence: editing instructions removed, the author's own later corrections applied, and capitalization and punctuation fixed.

The reason for writing is, I find it enjoyable enough to go back to blogging where I am not doing everything from scratch. I can ask AI to do most of the tasks that would have taken weeks before in seconds, such as designing custom CSS for each post. I always want to write about things, and as usual I have a high friction of starting. Some external motivators just tip this slightly in favor of getting it published. The post on writing papers with AI is something I was talking about with my students. I just wrote it so that they can find it again and again and refer to it. I like the name The Oblivious Robot. This blog is the memory that a robot obtains before it forgets again. Readers can expect stuff related to my thoughts about research, coming AI singularity, predictions about the future, how to adapt to the new age.
]]> The Oblivious Robot