Over the past year, collecting 20 years of fragments to create an agent-based publishing ERP

Publishing a single book takes much more effort than it appears to. From planning, recruiting writers or translators, reviewing first and second drafts, managing printers and distributors, to counting copies and determining when to reprint after publication, the work never ends.

Looking back, I've been in the publishing business for well over 20 years. During that time, I've created dozens of small-scale mini ERPs that the company used internally for things like purchase order automation and bookstore shopping mall integration.

I'm still using a publishing management program on a monthly subscription, like everyone else. Because the warehouse designated a specific program, there's no choice, and I've tried to compromise by creating an intermediary program that serves as a bridge for only necessary functions. I've also automated purchase orders through browser manipulation of the relevant company's program.

But entrusting data to someone else's hands came at a great cost. The publishing program company I trusted fell victim to ransomware, and the system became useless overnight. I experienced data loss accidents several times. While there were internal backup programs, watching hundreds of book sales histories and data disappear in an instant made me deeply realize: 'Publishing data shouldn't rely on anyone else—we need to hold it directly ourselves.'

So I decided, and for the past year, I've been working on consolidating about 100 scattered mini ERP fragments from 20 years into one.

At first, I thought I'd just create one solid management program that handles orders well and settles accounts properly, and that would be the end. But as I developed it, I kept hitting the same problem: business systems, once built, quickly creak and become outdated. Especially when people change at many business partners, the impact on the system is surprisingly significant. When managers change, the system (sales, marketing, events) must also change.

Well-selling books stop selling when their manager changes, and promotional work doesn't progress. A book we distributed with lucky charms stopped selling because the Christian manager didn't like them. Anyway, publishing isn't mass production with standardized specifications. Every person works differently. Planners, editors, and designers each have their own preferences, and even the same book requires different optimal approaches depending on circumstances. One person wants to review corrections in method A, another wants to develop planning in method B. Rigid traditional ERPs couldn't accommodate these diverse preferences at all. Forcing people into the system resulted in them not using it, or developers endlessly adding menus until the program itself collapsed.

Ultimately, for a system to survive, it couldn't rely on fixed rules but needed to evolve based on how people actually work—a kind of 'evolutionary' structure. And AI agents were what made this possible.

The system I've created now doesn't enforce just one method. When conducting market research or organizing table of contents, if there's method A and method B, the agent runs simulations for each approach and produces results. Based on the team's choices and actual outcomes, the better method survives. The surviving logic and prompts remain as the system's 'DNA,' and the outdated methods naturally fall away.

The key here is that used resources don't just get thrown away. Whether successful or failed, everything is broken down into LEGO-like components that can be reused. Later, when doing different projects, I can pull them out in completely different combinations. Over the past year, I've created about 170 components this way, and I'm currently using only those that fit the situation.

The same applies to manuscript and content creation. Not wanting to rely on external services, I installed lightweight open-source software like Gitea on our internal server as a GitBook alternative. As manuscripts go back and forth between agents and people for refinement, they're committed and branched like software code. Every history from planning memos to first draft, revisions, and final manuscripts is transparently recorded, and the refined markdown text can be directly extracted for wikis or publication data. Our own repository that won't be shaken by external platform policy changes.

I've also networked the Macs, NAS, and high-performance PCs we have in-house. Heavy work like video editing is automatically sent to GPUs-equipped PCs and brought back. New book planning progress is displayed in kanban format, and everything from expert recruitment lists to even warehouse closure alternative holidays is reflected in the schedule. After adding a business radar that checks book sales trends and alerts about reprint schedules before safety stock runs out, the database has well over 180 tables. The reason I might have introduced my remote disk management program online was probably because I once created something to find overlapping resources and version management problems in reverse. I probably have some trauma about files? A former employee was doing work for a competitor during business hours, and they sued over it ^^. So I remember recovering the deleted disk and submitting the evidence...

Anyway, I originally coded it as a standalone program, but as I kept fixing and adding features, I eventually moved it entirely to a web and server environment. Employees might not be thrilled that their work status or duplicate files on disk are all visible, but consolidating scattered resources into one place for management was unavoidable.

Looking back, the past year was less about coding a new program and more about weaving together 20 years of trial and error and fragments from the publishing industry into one organic whole.

I've attached everything I thought was necessary, so honestly, I might have attached too much. The dashboard looks almost like it runs automatically, but ultimately, deciding what book to create and adding the final touch is still up to people. The system simply supports from behind so that creators can focus entirely on making books.

Good methods remain in the system like genes, and leftover components become the foundation for the next book. Rather than a completed program, I'm building an ecosystem that continues to be refined and evolved as I publish books every day.

The conclusion is you can't build it cheaply. ㅠㅠ Just use existing ERPs ㅠㅠ