Gary Fuller @fullermotion

Enterprise AI, minus the enterprise team. Your biggest competitors have whole engineering departments shipping fast, AI-powered websites. You don't need one to keep up. Fullermotion runs the same stack the market leaders use, scoped to your business. Claude, Algolia, Adobe Commerce, Shopify, aws. No rip-and-replace. No six-figure platform you'll spend a year regretting. No new headcount. Three places we put it to work. AI Enablement. Models wired into the workflows your team already runs, from ops to comms to customer touchpoints. Embedded in the operating model, not bolted on as a novelty layer. AI-Driven Commerce. AI in discovery, merchandising, and buying guidance that protects revenue while making the path to purchase less of a maze. AI-Powered Search. Retrieval, ranking, and real answers, so people find the right thing fast instead of scrolling until they give up. The difference is speed. We map your highest-leverage workflow, ship one useful AI surface behind a flag in weeks, then scale what holds. Weeks, not quarters. Judged on real behavior, not a slide. The future gets built. Might as well start with one workflow that works. fullermotion.com

The fable/mythos shutdown is a useful reminder for teams building ai powered pipelines. If your workflow depends on a single model endpoint always being available, approved, stable, and affordable, you do not have architecture. You have a dependency with a nice api. That does not mean teams should avoid frontier models. It means they need to design around model volatility. Model access can change because of regulation, export controls, vendor policy, pricing, safety updates, deprecation, data residency, or procurement. None of that is exotic. It is normal enterprise risk wearing an ai hoodie. Teams should be asking: What happens if this model is unavailable? What happens if access changes by geography or user type? What happens if the model behavior changes? What happens if the fallback model is available but not good enough? The answer is not better prompt engineering. Prompts matter, but prompts are not architecture. The better pattern is an orchestration layer that can route tasks by capability, cost, latency, risk, and policy. Keep evals close to the workflow. Log model versions and outputs. Define fallback behavior. Use human review where failure has legal, security, brand, or business consequences. AI pipelines need the same discipline as production software. Versioning. Observability. Access control. Audit trails. Data governance. Cost controls. Fallback paths. The teams that get this right will not treat model choice as a one time implementation detail. They will treat it as an operational layer that needs governance, monitoring, and room to change. That is the shift. AI is moving from experimentation into infrastructure. Infrastructure has to survive policy changes, vendor changes, pricing changes, and model changes without dragging the entire workflow down with it. The companies that understand that will keep building. The ones that do not will keep rediscovering that a clever integration is not the same thing as a resilient system.

The Figma MCP server hands your design context to a model in a structured way. The instinct is to ask it to write the components. Wrong first move. A model that jumps straight to code produces generic output that ignores everything your platform actually enforces. So I have it build the execution plan first. The plan is where the domain knowledge lives. Figma drives the front end, the layout and component breakdown. My architecture drives the back end, the data models, the query bindings, the naming. The plan is where design intent and platform reality meet, and it is a reviewable artifact before a single line of code exists. That is the part worth internalizing. The leverage is not in code generation. It is in using the model to compress the thinking that happens before code, the part that used to eat hours of a senior person's day. Review is not optional. The model will guess wrong about your system. But an accurate first draft you correct beats a blank file you fill yourself. Acceleration, not autopilot. The judgment stays with you. The grunt work does not.

The AI arms race in creative software is accelerating. DaVinci Resolve started as a color grading tool. Today it includes AI-assisted editing, audio, subtitles, search, compositing, and now photography workflows. The interesting question isn’t which AI feature is best. It’s whether creators will soon expect every professional tool to handle the repetitive work so they can focus on creative decisions. The future of creative software isn’t AI as a feature. It’s AI becoming an invisible collaborator embedded throughout the workflow.

The DAM MCP use case is a metadata test in disguise The most useful AEM MCP use case is also the one that will most ruthlessly expose how good your metadata actually is. Adobe’s content MCP server for AEM as a Cloud Service exposes two operations that matter to anyone running a real DAM, asset import, and asset search. Import comes with a status check, because ingestion is asynchronous and the model has to wait for processing and rendition generation before it can confirm the asset is there. Search you have to ask Adobe to switch on, by emailing them your org and your use case, which tells you it is early and deliberately gated. Put those two together and you have something that sounds mundane and is not. “Find the approved hero image for the spring campaign and place it on these three pages” becomes a retrieval against your DAM, a permission check against your identity, and a set of page operations, all sequenced by the model. “Bring in these product shots from the brief and tag them correctly” becomes an import with a status check and a metadata write. Here is the catch, and it is the whole point. Both operations are only as good as the metadata underneath them. Asset search cannot return the right asset if nobody ever described it. An agent importing assets cannot place them correctly or tag them consistently if there is no naming standard and no controlled vocabulary for it to follow. The model does not fix a DAM where everything is named final_v2_USE_THIS.psd and half the metadata fields are blank. It inherits that mess and surfaces it faster. This is why the unglamorous DAM governance work, the naming conventions, the controlled metadata schema, the discipline nobody wanted to sit through a review to enforce, is not bureaucracy. It is the thing that decides whether natural-language asset retrieval is a feature or a disappointment. The teams who fought those battles are about to get paid for them. The teams who let the DAM rot are about to find out exactly how rotten, because now a model is asking it questions out loud. One thing I would not do is mistake this for a migration tool. MCP asset import is for targeted, intent-driven ingestion inside daily authoring, bring in this asset, tag it right, put it where it belongs. It is not the instrument for lifting an entire incumbent library wholesale into AEM Assets. That remains a bulk ingestion and content transfer problem with its own tooling. Use the right tool for each job, and do not let a clean demo talk you into the wrong architecture. The pattern holds across every AEM MCP use case I have looked at. The model is the easy part. What determines whether it helps you or embarrasses you is the structure it acts on. For the DAM, that structure is metadata. It always was.

Everyone keeps asking which agentic coding tool wins, Claude Code or Codex. Wrong question. The teams shipping fastest are not picking a side. They run both, not out of indecision, but because the two tools fail differently, and that difference is the whole point. A single coding agent is confidently wrong in consistent ways. It has a house style, a default architecture it reaches for, a class of bug it never sees. Live inside one tool long enough and you inherit its blind spots as your own. You stop noticing them because the tool stopped noticing them. Two agents with different training do not share the same blind spots. That is the actual mechanism, not “two is more than one.” The second tool is most useful precisely where the first is overconfident. So the workflow is not parallel duplication. It is adversarial. One agent drafts the implementation, the other gets the diff with one instruction: assume this is wrong and prove it. The disagreements are where the real bugs live. The honest caveat: for a solo dev on a side project, two paid agents is wasted money and context-switching tax. The “both” play earns its keep when a shipped bug is expensive, when tool spend is a rounding error to you, or when the work is novel enough that no single model has reliable judgment. Otherwise, pick one and go deep. But if you are shipping anything that matters, stop treating this as a loyalty contest. The leverage is not in the tool. It is in the disagreement between two of them.

Claude Code on Opus 4.8 now runs codebase scale migrations from kickoff to merge. It plans the work, spawns parallel subagents, then verifies its own output against your existing test suite before reporting back. The constraint was never writing code. It was trusting what got written. Opus 4.8 is roughly 4x less likely to let a flaw in its own code pass unremarked. That is the number that matters.

Most companies are still thinking too small about AI agents. They see agents as task runners. Draft this. Summarize that. Create a ticket. Send a notification. Update a spreadsheet. Useful, but tactical. The bigger opportunity is agent orchestration: designing systems where agents participate in real enterprise workflows with governance, review, auditability, and human approval. That is not just automation. That is an operating model. It reduces repetitive work. It increases throughput. It protects brand, compliance, and process standards. It keeps humans in control where judgment matters. It creates repeatable leverage instead of one off productivity gains. At Fullermotion, this is the infrastructure layer we are focused on: orchestrated agents that solve enterprise problems at scale. The future of AI in business is not a random collection of copilots. It is governed, integrated, measurable agent infrastructure that lets teams spend less time moving work around and more time making better decisions. AI should not just make tasks faster. It should make the operating system of the business more intelligent.

Everyone is worried about the wrong developers. The conversation around tools like Codex keeps circling back to junior developers. That concern is not unreasonable. But it is aimed at the wrong level of the org chart. Understanding the problem and designing a solution made someone a good developer. Syntax mastery, the ability to translate that thinking into precise, idiomatic, production-ready code without friction, was what separated good from great. That fluency was the differentiator. It was what made a senior developer fast, reliable, and hard to replace. Codex just commoditized that differentiator. You are no longer writing the implementation. You are describing what correct looks like. The execution layer, the thing senior developers spent years sharpening, is no longer the constraint. The developers most exposed are not the ones still learning syntax. They are the ones who stopped at syntax. What survives is the capability that was always harder to teach and harder to hire for. Can you understand a problem with enough precision to define what a correct solution looks like before you see one? Can you articulate the goal clearly enough that someone, or something, else can execute without you in the loop at every step? That skill was always the ceiling. Most organizations never formally tested for it because execution speed covered for its absence. That path is narrowing fast. The developers who matter most in the next few years already understood that writing code was a means to an end. Everyone else has some recalibration to do.

Strapi, SvelteKit, and Railway can make a strong content platform. The stack is simple. The architecture still needs discipline: ownership, preview, promotion, rollback, permissions, and governance before quick exceptions become permanent patterns.

AEM Cloud raises the architecture bar. Managed infrastructure helps, but it does not fix weak content models, unclear permissions, or vague governance. Cloud reduces operational pain. It does not replace architectural discipline. Source: experienceleague.adobe.com/en/docs/experi…

AI agents are not magic productivity dust. They are force multipliers, but only when leaders structure the work: clear ownership, bounded responsibilities, useful context, repeatable workflows, escalation paths, and human approval where risk matters.

AI does not make AEM architecture less important. It makes weak architecture more expensive. Bad templates, vague metadata, inconsistent content fragments, and loose governance become fuel for faster confusion. AI scales systems. Make sure the system is worth scaling.

Worth checking out: Google Cloud’s Gemini Enterprise Agent Platform updates show where agents are headed. Revisions, skill registries, identity, gateways, and observability are controls for scale. docs.cloud.google.com/gemini-enterpr…

For my generation, the future we were promised as kids was spacefaring. It was “boldly go where no one has gone before.” SpaceX’s recent SEC filing is a reminder that this future is no longer just science fiction. Reusable rockets, orbital infrastructure, global connectivity, and a path beyond Earth are being built in real time. Humanity needs companies that expand the frontier, not just optimize the present. From that perspective, SpaceX is not just a company to admire. It is a company worth serious investor attention. SEC filing: Space Exploration Technologies Corp. S 1

Adobe’s Brand Visibility launch signals the shift: AI orchestration depends on governed content context across CMS, DAM, taxonomy, permissions, metadata, and approvals. Audit before scaling AI. news.adobe.com/news/2026/04/a…

AI governance is moving from policy to operating infrastructure: asset registries, approvals, model cards, audit trails, and evidence. The enterprise question is provable governance at scale. alation.com/news-and-press…

Adobe’s latest Experience Platform notes point to a practical AI governance issue: teams need visibility into field group usage, required attributes, and governance labels before changing schemas. AI-ready data starts with change-aware metadata. Source: experienceleague.adobe.com/en/docs/experi…

Adobe’s Brand Visibility announcement points to a bigger shift: enterprise content is becoming trusted context for agents, search, copilots, and discovery. DXP, DAM, metadata, approvals, permissions, and governance now need to operate as AI platform architecture.

Digital asset management is moving beyond storage and search. In AI enabled content operations, the real question is whether approved assets, metadata, rights, renditions, and campaign context can move safely into the tools where work happens. Adobe’s latest AEM update, extending Content Advisor into Workfront and third party applications, points in that direction. For enterprise leaders, the DAM evaluation should change. Do not only ask whether the system organizes assets well. Ask whether it can operate as a governed content intelligence layer across the full content supply chain. Source: experienceleague.adobe.com/en/docs/experi…