Why do I need a canvas to visualize the work that the agents are doing? I don't want to see their thought process, I just want the end product like how ChatGPT or Claude currently work.
That is definitely a valid way of using Spine as well. You can just work in the chat and consume the deliverables similar to how you would in other tools.
The canvas helps when you want to trace back why an output wasn't what you expected, or if you're curious to dig deeper.
Even beyond auditability, the canvas also helps agents do better work: they can generate in parallel, explore branches, and pass context to each other in a structured way (especially useful for longer-running tasks).
A program making a call to github.com needs an authentication token.
What are you suggesting? The program makes a call to retrieve the secret from AWS? Then has full access to do with it what they want? That's exactly the risk and the problem this, and related solutions mentioned in this thread, is trying to solve.
What if you want to build a third party integration to connect to Claude Chat or Cowork? Those can't run arbitrary CLIs. The only way to integrate with them is via MCP.
For good reason, IMO. Anthropic can't just allow their execution environments to run arbitrary user-generated CLI tools.
The first argument actually leans in favor of LaTeX or Typst as a better replacement for Docx.
A LaTeX or Typst document can contain both the content and formatting together within the same file. This isn't idiomatic for either language, and my experience is that this is more common for Typst than LaTeX, but both can do so. All of those formatting rules like small caps, table widths, margins, page numbering, etc.? Those can be rigidly defined in either LaTeX or Typst and are better guarded aginst accidental formatting rules breaches from double click, copy/paste, or table cell insertion than in Word.
I'm more sympathetic to the network effect argument. It's hard to envision a reasonable redline system compatible with both Docx and LaTeX/Typst.
Diffing the XML is a complete nonstarter. I've spent years working with the OpenXML format and can assure you it is very complex even for a professional software engineer with 10 years of experience.
The diff of the document (referred to as a "redline") is what lawyers send to the client and their counterparties. It's essential that the redline is legible for all parties and reflects their professionalism.
Moreover, it is not enough to see the structural changes between the versions. A lawyer needs to see the formatting changes between the versions as well which cannot be accomplished by diffing XML files.
Correct. Solely relying on the built in Word Compare tool results in a whole host of version control issues, however, which I outline in detail in my post "On Building Git for Lawyers."
Git supports registering custom diff tools for specific file types [1]
Wouldn't the obvious solution then be to take the tool they already use for redlining (e.g. Word's compare function) and integrate it into a git workflow?
I saw this project on a recent hackernews comment and I had seen some comments there about how it does / can work decently with git features iirc (https://news.ycombinator.com/item?id=46265811)
I am interested to hear what your thoughts on recutils are and if perhaps we can have microsoft word/similar to git+recutils like workflow maybe
I thought about it and a tar/zipped git folder which can contain images/other content too which can be referenced with recutils instead of openxml/word document to me does feel an interesting idea
I am not sure but I think that openxml directly embeds data like pictures which can defnitely make it hard for git software to work perhaps but basically I am interested what you think about this/any feedback
You don't seem to be aware of any of the work I'm doing on CSTML (built to replace HTML and XML, and yes, built to be useful for legal documents (even though IANAL)). If you're interested in collaborating to go after the law market, let's talk! You're trying to sneak in a side door. I'm planning to smash down the main gates, the ones you say are impregnable. My investigation says they're not unbreakable, but instead strong and brittle. Many attacks will bounce off, yes, but brittleness means that these are defenses that will shatter before they bend.
Within the last ten years I have worked with lawyers and legal secretaries who were still using WordPerfect. I have to say that I was surprised to learn this.
Yes, exactly. A successor could theoretically replace Word, but first it needs to replicate all of its existing functionality.
For a competitor to supplant Word, it would need to:
- Be fully backwards compatible with .docx. Lawyers will inevitably receive .docx files from counterparties that they need to review, redline, and mark up. The new processor has to handle everything Word does flawlessly. (As an engineer who has spent considerable time building a high-quality docx comparison engine, I can tell you this is tremendously difficult.)
- If it introduces a new file format, support seamless comparison and conversion between that format and .docx. Not technically impossible, but also tremendously difficult with marginal upside.
- Defeat the Microsoft Office bundle in the market — meaning it either offers enough advantage that organizations pay for both, or it replaces Excel, PowerPoint, and Outlook too.
Given the enormous challenge of building a viable Word competitor and the marginal room for improvement that Microsoft has left on the table, I think it's very unlikely that a competitor will threaten its market position.
For certain legal use cases SaaS is still a non-starter due to security concerns so this hypothetical MS Word competitor would also need a native local application option. I don't think Google is interested in that market.
HTML can represent a docx file in a web application but it can never replace docx. Docx files are a protocol for sharing documents between lawyers. I go into more detail on that in the "Docx is a protocol, not a filetype" portion of the essay.
Version control + binary file support is of limited utility for lawyers. They need to see what's changed from version to version, including formatting changes. This is why we spent years building out the document processing technology needed build version control for Microsoft Word.
I write a lot more about it in an earlier essay, "On Building Git for Lawyers."
