A voice that survives the workflow.

Part I / The product

A useful content-generation product has to preserve more than a topic. It needs to know who is speaking, who is reading, what the content should achieve, and how a particular format changes the delivery. Re-entering that information for every request creates friction and inconsistency.

ContentForge AI combines reusable brand profiles with a structured brief. Generated pieces can be saved, edited, repurposed, and planned on a calendar. The workspace is individual and authenticated; it is not a team collaboration or autonomous publishing platform.

Part I / The product

The interface separates Dashboard, Create, Library, Calendar, Brands, and Settings. The dashboard summarizes usage, content counts, recent work, and upcoming schedules. The creation form puts the brief next to its output rather than hiding the process behind a conversational interface.

The library exposes the lifecycle of a piece through search and filters for format, status, and brand. Editing, copying, duplication, repurposing, scheduling, and deletion remain explicit user actions. The calendar shows the intended release date rather than promising automatic distribution.

• Loading states explain when generation is in progress.
• Empty states separate an unused workspace from a failed request.
• Validation and provider errors are surfaced without returning sensitive upstream details.

Part II / The system

Next.js 16 App Router and TypeScript provide both the web product and server API route handlers. Tailwind CSS handles the product interface. Clerk manages authentication; Prisma connects application services to PostgreSQL. AI access is isolated in a server-only provider layer.

Part II / The system

The profile has eleven fields: name, description, industry, target audience, personality, tone, values, preferred phrases, avoided phrases, writing style, and example content. A selected profile is loaded with the authenticated user's ownership constraint before being transformed into prompt input.

The prompt builder introduces those fields as writing guidance. Preferred phrases are encouraged, avoided phrases are constrained, and example copy helps communicate rhythm and diction. Example text is clipped to 1,200 characters for the prompt, keeping stored profile size separate from inference context size.

Part III / Execution

The brief includes the target format, topic, audience, objective, tone, length, keywords, CTA, and variation count. Eight formats are supported: LinkedIn, X/Twitter, Instagram, Facebook, marketing email, ad copy, product description, and blog post. Each format introduces its own delivery constraints.

Three variations use all three strategies; two use Direct and Story-driven. A single variation chooses one strategy. The generator runs the requested variations with Promise.all, so they are independent provider calls, not a sequential multi-agent workflow. A failed variation rejects the group rather than silently returning a partial success.

The API can return previews without saving. If saving is requested, the variations are persisted together as drafts in a database transaction, retaining the original brief fields and variation index.

Part III / Execution

A common adapter interface accepts messages, temperature, and token budget. OpenAI-compatible and Anthropic implementations translate this request to their respective APIs; a deterministic mock provider supports offline workflows and tests.

Transient network failures, rate limits, and selected 5xx responses receive bounded retries with exponential backoff and jitter. Retry-After is capped at five seconds. The ordinary upstream retry policy permits three attempts, and individual request timeouts are bounded at ninety seconds.

The OpenAI-compatible path also recognizes an empty completion caused by a length finish reason and can retry with an expanded token budget. This is a targeted compatibility mechanism, not a fallback to a different provider.

Part III / Execution

Request validation constrains the topic, audience, objective, tone, keywords, CTA, format, length, and variation count. The generation count must be between one and three. Invalid JSON or invalid request fields receive an explicit client error before model work begins.

The generation prompt asks for a JSON object containing title and body. The response parser accepts clean JSON, markdown-fenced JSON, and a balanced embedded object. It still validates the resulting object: a readable body is required, and an absent or invalid title can fall back to Untitled.

A structurally valid body can still contain inaccurate claims. Parsing protects the software contract, not the truth of the marketing copy. Provider failures and unreadable outputs return recoverable errors, while sensitive provider diagnostics stay in server logs.

• Validate the request before loading external services.
• Validate generated structure before previewing or persisting it.
• Keep structural validation separate from human content review.

Part IV / Durable workflows

The identity resolver reads the Clerk session and maps it to an active database user. A first login provisions the workspace through the same resolver used by APIs. Signed Clerk lifecycle webhooks keep identity changes synchronized, and inactive-user checks prevent stale access.

Brands, content, schedules, usage, and Google Calendar preferences carry user ownership. API queries scope resource lookups to that owner rather than treating possession of an ID as permission. Brand and content relationships preserve the context needed for later reuse.

Part IV / Durable workflows

Repurposing starts from an owned, saved piece and a different target format. The prompt carries the source text, original and target formats, and available brand context. Source text is clipped to 6,000 characters for this prompt. Same-format repurposing is blocked.

The result is saved as a new draft linked through sourceContentId. The original remains intact, making adaptation a traceable relationship rather than a destructive edit. Library actions keep direct editing, duplication, and AI-driven repurposing conceptually separate.

Part IV / Durable workflows

Scheduling records the content, platform, and intended date/time. A serializable database transaction creates or updates the schedule and adjusts the content status. Cancelling the last pending schedule returns scheduled content to Draft; archived content must be restored before scheduling.

The optional Google integration obtains OAuth tokens through Clerk. A deterministic event identity and a per-schedule PostgreSQL advisory lock coordinate concurrent synchronization attempts. Persisted event IDs and error state support retrying failed updates without discarding the local plan.

Part V / Reliability

The server caps each user at three brands and fifty accepted generation or repurposing operations per UTC day. The daily allowance counts operations, not individual variations or provider retry attempts. A three-variation request is one operation even though it makes multiple upstream calls.

Usage reservation uses conditional atomic increments and handles concurrent row-creation races. An accepted operation remains consumed if the provider fails. Brand creation uses serializable transactions with bounded retries for transaction conflicts, avoiding a client-only limit that simultaneous requests could bypass.

Closing / Engineering judgment

The repository includes Vitest tests for prompt construction, generators, provider retries, validation, authorization, quotas, calendar behavior, lifecycle webhooks, and workspace provisioning. Opt-in PostgreSQL integration coverage exercises persistence boundaries. These are test surfaces in the implementation, not newly measured quality or latency results.

No supplied accuracy benchmark establishes brand fidelity or marketing effectiveness. Useful next evaluations would compare strategy diversity, review avoided-phrase behavior, check human-rated voice consistency, and test concurrent usage and calendar updates against a real database. Such evaluations should retain their prompts, models, samples, and failure cases.

• Reusable context reduces repeated setup, but does not eliminate review.
• Creative diversity comes from explicit strategies, not a multi-agent claim.
• Ownership and quotas belong at the server boundary.
• Local planning and external calendar state need separate failure handling.
• A good AI product keeps the work usable after generation ends.