- Preface i
-
1 From Assistant to Autonomous Agent 2
- 1.1 When an Assistant Becomes Infrastructure 2
- 1.2 The Autonomy Spectrum 3
- 1.3 What Changes at Each Transition 9
- 1.4 Defining an Autonomous Coding Agent 12
- 1.5 The Minimum Architecture of Autonomy 13
- 1.6 Examples Across the Spectrum 14
- 1.7 The Hermes Runner Pattern 16
- 1.8 Why ``Just Add Guardrails'' Is Not Enough 16
- 1.9 Safety Architecture by Autonomy Level 18
- 1.10 Common Mistakes 19
- 1.11 Hands-On Lab: Inventory Your AI Tool Usage 20
- 1.12 Chapter Summary 22
- 1.13 Interview Questions 24
-
2 The Core Agent Loop and Control Flow 26
- 2.1 The Loop Underneath Every Agent 26
- 2.2 The Five Phases of the Agent Loop 27
- 2.3 The Minimal Architecture for This Chapter 29
- 2.4 Project Setup 30
- 2.5 Defining the Tool Result Structure 30
- 2.6 Implementing the First Tool: read_file 32
- 2.7 Defining the Tool Schema for the Model 34
- 2.8 Implementing the Tool Registry 35
- 2.9 Building the Context Manager 36
- 2.10 Making the Model Call 38
- 2.11 Implementing the Agent Loop 39
- 2.12 Complete Minimal Implementation 42
- 2.13 Running the Agent 48
- 2.14 Failure Test --- Nonexistent File 49
- 2.15 Failure Test --- Path Traversal 50
- 2.16 Clean Termination versus Infinite Loops 50
- 2.17 Why This Loop Is Not Production-Ready Yet 52
- 2.18 Hands-On Lab: Implement the Five-Phase Loop 52
- 2.19 Chapter Summary 53
- 2.20 Interview Questions 54
-
3 Planning Strategies 56
- 3.1 The Loop Needs a Strategy 56
- 3.2 Why Planning Is Not Just Prompting 57
- 3.3 The Planning Interface 58
- 3.4 Strategy 1 --- ReAct 60
- 3.5 Strategy 2 --- Plan-then-execute 62
- 3.6 Strategy 3 --- Self-critique and Reflection 65
- 3.7 Comparing the Three Strategies 68
- 3.8 Choosing a Strategy by Task Type 69
- 3.9 Updating the Chapter~2 Agent Loop 70
- 3.10 Plan Representation Formats 72
- 3.11 Re-planning When a Subtask Fails 72
- 3.12 Planning and Termination 74
- 3.13 Measuring Planning Quality 75
- 3.14 Hands-On Lab: Compare Three Planners 76
- 3.15 Chapter Summary 78
- 3.16 Interview Questions 79
-
4 Memory Systems 81
- 4.1 Stateless Agents Repeat Themselves 81
- 4.2 What ``Memory'' Means in an Autonomous Agent 82
- 4.3 The Four Memory Tiers 84
- 4.4 What This Chapter Will Implement 86
- 4.5 Designing the SQLite Schema 87
- 4.6 Implementing the Memory Store 90
- 4.7 Serializing Plans From Chapter~3 94
- 4.8 Recording Conversation History 96
- 4.9 Adding Memory to the Agent Loop 98
- 4.10 Crash Recovery Model 102
- 4.11 Simulating a Crash 103
- 4.12 Scratchpad Files 105
- 4.13 Memory Hygiene 107
- 4.14 Secrets and Sensitive Data in Memory 108
- 4.15 Optional Semantic Memory Overview 110
- 4.16 Inspecting Memory Manually 111
- 4.17 Failure Modes of Memory 112
- 4.18 Hands-On Lab: SQLite Memory and Resume 113
- 4.19 Chapter Summary 114
- 4.20 Interview Questions 116
-
5 Tool Use and Function Calling 117
- 5.1 Tools Are Where Autonomy Becomes Real 117
- 5.2 What a Tool Really Is 118
- 5.3 Why Tool Definitions Matter 119
- 5.4 Tool Names and Descriptions 121
- 5.5 JSON Schema for Tool Inputs 122
- 5.6 Argument Hallucination 124
- 5.7 The ToolResult Contract 125
- 5.8 Runtime Validation 127
- 5.9 Implementing the ToolDispatcher 127
- 5.10 Tool Risk Levels and Side-Effect Categories 130
- 5.11 The Standard Coding-Agent Tool Library 131
- 5.12 Implementing read_file 132
- 5.13 Implementing list_project_files 133
- 5.14 Implementing search_codebase 134
- 5.15 Implementing read_url 136
- 5.16 Implementing propose_patch 137
- 5.17 Output Shaping and Context Efficiency 139
- 5.18 Tool Errors as Recovery Information 140
- 5.19 Integrating Tools With Memory 141
- 5.20 Updating the Agent Loop for the Dispatcher 142
- 5.21 Testing Tools Without an LLM 143
- 5.22 Common Tool-Design Mistakes 146
- 5.23 Hands-On Lab: Build the Tool Dispatcher and Standard Tool Library 146
- 5.24 Complete Implementation 148
- 5.25 Chapter Summary 162
- 5.26 Interview Questions 163
-
6 Sandboxing and Isolation 166
- 6.1 The Moment Tools Need Containment 166
- 6.2 Why Host Execution Is Unacceptable for Autonomous Agents 167
- 6.3 Sandboxing Goals 168
- 6.4 Docker Sandbox Architecture 169
- 6.5 Read-Only Source, Writable Workspace 171
- 6.6 The Applier Pattern 172
- 6.7 Docker Command Model 172
- 6.8 Implementing DockerSandbox 174
- 6.9 SandboxResult and Structured Command Output 178
- 6.10 Safe Command Construction 179
- 6.11 Implementing the Sandbox-Backed Tool 181
- 6.12 Building the Sandbox Image 184
- 6.13 Running the First Sandbox Command Manually 184
- 6.14 Filesystem Isolation Tests 185
- 6.15 Network Isolation Tests 188
- 6.16 Resource Limit and Timeout Tests 189
- 6.17 Integrating Sandbox Execution With Memory 189
- 6.18 Sandbox Lifecycle and Cleanup 191
- 6.19 Docker Is Not Magic Security 192
- 6.20 Alternatives When Docker Is Not Available 193
- 6.21 Updating the Agent's Risk Policy 194
- 6.22 Common Sandboxing Mistakes 195
- 6.23 Hands-On Lab: Build and Verify the Docker Sandbox 195
- 6.24 Chapter Summary 197
- 6.25 Interview Questions 198
-
7 Persistent Runners 200
- 7.1 From Script to Service 200
- 7.2 What a Persistent Runner Is 201
- 7.3 The Runner Architecture 202
- 7.4 Work Queue State Model 203
- 7.5 SQLite Queue Schema 204
- 7.6 Implementing the Queue Store 206
- 7.7 The Enqueue Script 215
- 7.8 The Worker Loop 217
- 7.9 Agent Session Executor 220
- 7.10 Graceful Shutdown 223
- 7.11 Crash Recovery and Stale Claims 224
- 7.12 State Persistence Across Runner Restarts 225
- 7.13 Logging Strategy 226
- 7.14 The systemd Service Unit 227
- 7.15 Installing the Runner on Debian 229
- 7.16 Submitting Tasks to the Runner 230
- 7.17 Morning Review Workflow 231
- 7.18 Operator Commands 232
- 7.19 Task Scope and Permissions 233
- 7.20 Resource and Budget Controls 234
- 7.21 Common Persistent-Runner Mistakes 234
- 7.22 Hands-On Lab: Build the Persistent Runner 235
- 7.23 Chapter Summary 237
- 7.24 Interview Questions 238
-
8 Workspace Context Injection 240
- 8.1 Agents Should Not Start Cold 240
- 8.2 What Workspace Context Is 241
- 8.3 AGENTS.md as the Primary Instruction File 242
- 8.4 Writing an Effective AGENTS.md 243
- 8.5 The Context Injection Pipeline 245
- 8.6 Implementing WorkspaceContext 247
- 8.7 Loading AGENTS.md 250
- 8.8 Dynamic Context 252
- 8.9 File Anchor Injection 254
- 8.10 Context Budget Management 257
- 8.11 Context Item Priority 260
- 8.12 Relevant Memory Injection 261
- 8.13 Workspace Fingerprinting 263
- 8.14 Task Scope Injection 266
- 8.15 Prompt Injection Risks from Workspace Files 268
- 8.16 Rendering Injected Context 269
- 8.17 Integrating with the Persistent Runner 270
- 8.18 Recording What Was Injected 273
- 8.19 Measuring Context Quality 276
- 8.20 Common Context Injection Mistakes 276
- 8.21 Hands-On Lab: Add Workspace Context Injection 277
- 8.22 Chapter Summary 279
- 8.23 Interview Questions 280
-
9 Failure Modes and Guardrails 282
- 9.1 Agents Fail in Patterns 282
- 9.2 What a Guardrail Is 283
- 9.3 Guardrail Placement in the Architecture 284
- 9.4 Failure Mode 1 --- Infinite or Circular Tool Loops 285
- 9.5 Failure Mode 2 --- Hallucinated File Paths 287
- 9.6 Failure Mode 3 --- Runaway Token and Context Growth 289
- 9.7 Failure Mode 4 --- Incorrect Edits That Accumulate 292
- 9.8 Failure Mode 5 --- Prompt Injection Through Workspace Context 295
- 9.9 Failure Mode 6 --- Silent Hangs and Lost Heartbeats 298
- 9.10 Failure Mode 7 --- Stale Resume State 301
- 9.11 The Guardrail Event Model 302
- 9.12 The Guardrail Manager 304
- 9.13 Integrating Guardrails With the Agent Loop 306
- 9.14 Integrating Guardrails With the Persistent Runner 309
- 9.15 Guardrail Policy Configuration 311
- 9.16 Logging and the Audit Trail for Guardrails 314
- 9.17 Guardrails Versus Model Self-Critique 315
- 9.18 Guardrails Versus Sandboxing 315
- 9.19 Common Guardrail Mistakes 316
- 9.20 Hands-On Lab: Implement Guardrails 316
- 9.21 Chapter Summary 318
- 9.22 Interview Questions 319
-
10 Evals and Observability 321
- 10.1 ``It Worked Once'' Is Not Evidence 321
- 10.2 Observability Versus Evals 322
- 10.3 What to Measure 322
- 10.4 An Event Model for Agent Observability 323
- 10.5 Implementing ObservabilityEvent 324
- 10.6 The SQLite Observability Schema 326
- 10.7 Implementing EventStore 327
- 10.8 Integrating Observability With the Agent Loop 331
- 10.9 Integrating Observability With the Runner 333
- 10.10 Token and Cost Estimation 335
- 10.11 Local Reporting Without a Dashboard 337
- 10.12 An Optional Local Dashboard 339
- 10.13 What an Eval Is 341
- 10.14 Designing Coding-Agent Eval Tasks 341
- 10.15 Eval Suite Layout 342
- 10.16 Eval Task Specification 343
- 10.17 Implementing Success Checks 344
- 10.18 Implementing eval_runner.py 347
- 10.19 The Eval Result Model 351
- 10.20 Regression Testing Agent Changes 352
- 10.21 Per-Model Benchmarking 353
- 10.22 LLM-as-Judge: Optional, and Dangerous if Overused 354
- 10.23 Common Observability and Eval Mistakes 354
- 10.24 Hands-On Lab: Add Observability and a Small Eval Suite 355
- 10.25 Chapter Summary 357
- 10.26 Interview Questions 358
-
11 Multi-Agent Patterns 359
- 11.1 More Agents, More Coordination 359
- 11.2 When Not to Use Multiple Agents 360
- 11.3 What Changes in a Multi-Agent System 361
- 11.4 Pattern 1 --- Orchestrator-Worker 362
- 11.5 Implementing Task Decomposition 363
- 11.6 The SQLite Coordination Table 365
- 11.7 Implementing CoordinationStore 366
- 11.8 Implementing an Orchestrator 370
- 11.9 Worker Agent Roles 373
- 11.10 Role-Specific Context and Tools 375
- 11.11 Pattern 2 --- Debate-Critic 377
- 11.12 Implementing Debate-Critic 377
- 11.13 Pattern 3 --- Specialist Network 379
- 11.14 Implementing a Simple Router 380
- 11.15 Communication Protocols 381
- 11.16 Preventing Infinite Chatter 382
- 11.17 Observability for Multi-Agent Runs 385
- 11.18 Evaluating Multi-Agent Patterns 387
- 11.19 Common Multi-Agent Mistakes 387
- 11.20 Hands-On Lab: Build an Orchestrator-Worker System 388
- 11.21 Chapter Summary 389
- 11.22 Interview Questions 390
-
12 Local-First Autonomous Agents 393
- 12.1 Local-First Changes the Operating Model 393
- 12.2 What Local-First Means 394
- 12.3 The Local-First Trade-Off 395
- 12.4 Model-Serving Options 396
- 12.5 The Provider Adapter Architecture 396
- 12.6 The Cloud Adapter Wrapper 398
- 12.7 The OpenAI-Compatible Local Adapter 399
- 12.8 Tool-Calling Reliability Differences 403
- 12.9 Local Model Prompt and Schema Adjustments 404
- 12.10 Non-Tool-Response Recovery 404
- 12.11 Malformed JSON Recovery 407
- 12.12 Model Routing Policy 408
- 12.13 Hybrid Routing --- Cloud for Planning, Local for Execution 411
- 12.14 Integrating Model Routing With the Runner 412
- 12.15 Local Model Availability Checks 414
- 12.16 Measuring Local Models With the Eval Suite 416
- 12.17 Local-First Observability Metrics 416
- 12.18 vLLM and Concurrent Sessions 418
- 12.19 Privacy and Data-Control Policy 418
- 12.20 Hardware and Latency Expectations 419
- 12.21 Common Local-First Mistakes 420
- 12.22 Hands-On Lab: Run the Agent Against a Local Model Endpoint 420
- 12.23 Chapter Summary 422
- 12.24 Interview Questions 423
-
13 Safety, Ethics, and Operational Guardrails 424
- 13.1 Safety Is an Operating Model, Not a Prompt 424
- 13.2 Runtime Guardrails Versus Operational Guardrails 425
- 13.3 The Autonomous Coding Risk Ladder 426
- 13.4 Policy as Code 427
- 13.5 An Example Policy File 432
- 13.6 The Policy Evaluator 434
- 13.7 Approval Gates 441
- 13.8 Human Override and Stop Controls 444
- 13.9 Audit Trail Requirements 448
- 13.10 Data Classification 451
- 13.11 Secret Handling and Redaction 453
- 13.12 Cloud Routing Safety 456
- 13.13 Network Access Policy 458
- 13.14 File Write and Patch-Application Boundaries 459
- 13.15 The Human Review Workflow 460
- 13.16 Disclosure and Labeling 464
- 13.17 Incident Response 464
- 13.18 Retention and Deletion 467
- 13.19 Operator Dashboard Additions 470
- 13.20 Wiring the Controls Into the Runner 473
- 13.21 Common Safety and Ethics Mistakes 476
- 13.22 Hands-On Lab: Add Operational Safety Controls 477
- 13.23 Chapter Summary 478
- 13.24 Interview Questions 479
-
14 Capstone: The Build-Verify-Fix Daemon 481
- 14.1 The Full Loop Finally Comes Together 481
- 14.2 What Build-Verify-Fix Means 482
- 14.3 Capstone Architecture 483
- 14.4 The Daemon Contract 483
- 14.5 Task Intake and Preflight 485
- 14.6 The Capstone Configuration 487
- 14.7 Candidate Workspace Strategy 490
- 14.8 Verification Plan 493
- 14.9 Running Sandboxed Verification 493
- 14.10 Attempt Records 498
- 14.11 The Build-Verify-Fix Controller 500
- 14.12 Verification Feedback to the Agent 509
- 14.13 Stop Conditions 511
- 14.14 Approval-Aware Transitions 512
- 14.15 Observability and Audit Events 513
- 14.16 Guardrail Integration 514
- 14.17 Model Routing Integration 514
- 14.18 Single-Agent Default, Multi-Agent Optional 515
- 14.19 Review Packet Output 515
- 14.20 The Capstone CLI 519
- 14.21 The Capstone Eval Task 522
- 14.22 Failure Scenarios 523
- 14.23 Common Capstone Mistakes 524
- 14.24 Hands-On Lab: Build the Build-Verify-Fix Daemon 525
- 14.25 Chapter Summary 526
- 14.26 Interview Questions 527
-
15 Integrating with the Antigravity SDK 529
- 15.1 SDKs Are Accelerators, Not Foundations 529
- 15.2 What Integration Means 530
- 15.3 Architecture Mapping 530
- 15.4 Integration Principles 531
- 15.5 Adapter Package Layout 532
- 15.6 The SDK Client Protocol 533
- 15.7 The Fake Antigravity Client 536
- 15.8 The Antigravity Model Adapter 539
- 15.9 The Tool Bridge 542
- 15.10 The Policy Wrapper for SDK Actions 544
- 15.11 The Observability Bridge 546
- 15.12 The Runner Adapter 549
- 15.13 Integrating with Build-Verify-Fix 554
- 15.14 The SDK-Backed Eval Backend 555
- 15.15 Comparing Native and SDK-Backed Runs 558
- 15.16 Handling SDK Version Drift 559
- 15.17 Cancellation and Operator Stop 559
- 15.18 Sandbox and Filesystem Boundaries 560
- 15.19 Cloud and Data-Routing Implications 560
- 15.20 Common SDK Integration Mistakes 561
- 15.21 Hands-On Lab: Add an Antigravity-Backed Runner Adapter 562
- 15.22 Chapter Summary 563
- 15.23 Interview Questions 564
-
16 Operating Agents at Scale 566
- 16.1 Scale Is Where Discipline Is Tested 566
- 16.2 What ``Scale'' Means for Autonomous Coding Agents 567
- 16.3 The Single-Runner Baseline 567
- 16.4 Capacity Planning 568
- 16.5 Queue Pressure and Scheduling 571
- 16.6 Runner Pools Without Distributed Infrastructure 574
- 16.7 When SQLite Stops Being Enough 576
- 16.8 Workload Isolation 577
- 16.9 Rate Limits and Budgets 579
- 16.10 Model Serving Operations 585
- 16.11 Artifact Management 586
- 16.12 Backups and Restore 588
- 16.13 Upgrade Strategy 591
- 16.14 Configuration Management 592
- 16.15 Deployment Topologies 593
- 16.16 systemd Operations 594
- 16.17 Incident Operations 595
- 16.18 Human Review Capacity 596
- 16.19 Security Posture at Scale 598
- 16.20 Operating Runbook 598
- 16.21 Common Scaling Mistakes 601
- 16.22 Hands-On Lab: Operate a Small Runner Pool 602
- 16.23 Chapter Summary 603
- 16.24 Interview Questions 604
- Conclusion 606
Building Autonomous Coding Agents
Design, Safety, and Local-First Operation of Unattended AI Development Systems
Build agents that write code, fix tests, and commit changes while you sleep — safely, cheaply, and entirely on your own hardware (622 manuscript pages).
Minimum price
$19.99
$29.99
You pay
Author earns
About
About the Book
**Building Autonomous Coding Agents** is a code-first, ground-up guide to the specific engineering discipline that decides whether letting a language model act on a real codebase unsupervised is a responsible decision or a gamble: not a better prompt, but a system around the model that bounds what it can do, verifies what it claims, and stays accountable when it fails. The book exists because the industry conversation about autonomous coding agents has largely stayed at the level of capability claims and anecdote, while the actual question — what architecture makes a given amount of delegated authority safe to grant — has a precise, buildable answer that most treatments skip. This book builds that answer in full, in runnable Python, rather than surveying it in the abstract.
The material progresses as a single cumulative build rather than a tour of unrelated techniques. It opens by defining autonomy itself as delegated authority over action and establishing a four-level spectrum from suggestion to fully unattended operation, then constructs a minimal five-phase agent loop and hardens it, chapter by chapter, with the components real unattended operation requires: three interchangeable planning strategies, a durable SQLite memory that survives a mid-run crash, a validated tool-dispatch layer that turns model mistakes into recoverable data instead of crashes, a Docker sandbox that contains the blast radius of a wrong command, a persistent systemd-managed runner that works a task queue overnight, workspace briefing that stops the agent from rediscovering the same facts on every task, seven concrete runtime guardrails for seven named failure patterns, an evaluation and observability stack that replaces anecdote with measurement, three patterns for coordinating multiple agents when — and only when — that is actually justified, local-first model serving with a privacy-enforced routing policy, and a full operational safety layer of policy-as-code, approval gates, human override, audit trails, and incident response. Everything converges in a capstone Build-Verify-Fix daemon that assembles all of it into one bounded, reviewable system, and the book closes by showing how that same system is wrapped around an external agent SDK without surrendering its boundaries, and how it is operated as a small pool once a single runner is no longer enough.
Readers finish with concrete, transferable capabilities rather than familiarity with one framework: the ability to design a control loop with explicit, runtime-enforced termination; to build a tool layer that survives argument hallucination and malformed input without crashing; to contain command execution in a real sandbox and prove the containment holds with tests against actual Docker; to give an unattended system durable memory, crash recovery, and an audit trail an operator can trust more than the agent's own self-report; to detect and bound the specific ways autonomous agents fail rather than hoping they won't; to measure whether a change to an agent's prompt, model, or planner actually helped instead of guessing; and to reason clearly about when a second agent, a local model, or an external SDK earns its added complexity rather than merely sounding more advanced. The material is thoroughly hands-on: every chapter builds working code, includes a lab that exercises it against real failure conditions (a simulated crash, a path-traversal attempt, a deliberately induced infinite loop, a policy violation), and closes with a chapter summary, an outcomes checklist, and interview-style questions that test the underlying reasoning, not just recall.
This is a book for engineers who already ship software and are deciding how much authority to hand a language model over their own codebase — senior developers building internal tooling, teams evaluating or building agent platforms, and anyone who has to defend an autonomy decision to a colleague or a security review rather than simply hope it works out. It assumes solid Python and ordinary familiarity with tests, containers, and running a service, but assumes no prior experience building agents specifically. Readers looking for a survey of agent products, a promise of unsupervised production deployment, or a shortcut past the engineering will not find it here; readers willing to build the real system, one enforced boundary at a time, will finish with an autonomous coding agent whose limits they can state precisely — because they built every one of those limits themselves.
Author
About the Author
Yohan is a Senior Full-Stack Software Engineer with extensive experience delivering scalable, end-to-end software solutions across web, enterprise, and cloud-based environments. He specializes in architecting robust platforms, modernizing legacy systems, driving cloud transformation efforts, and building integration-heavy applications that support critical business workflows. He is recognized for translating complex requirements into reliable, maintainable, and high-value solutions across industries such as insurance, cybersecurity, and professional services.
Known for combining strong technical execution with a practical business mindset, he has contributed to projects from concept and design through production delivery and long-term support. His experience includes collaborating with cross-functional teams, improving development workflows, solving complex technical challenges, and helping organizations deliver dependable software products that adapt to changing business needs. He brings a balanced approach to engineering that values quality, efficiency, and continuous improvement.
Contents
Table of Contents
Get the free sample chapters
Click the buttons to get the free sample in PDF or EPUB, or read the sample online here
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.