diff --git a/_content/blog/context-and-structs.md b/_content/blog/context-and-structs.md
index fb7379176e..08d169875f 100644
--- a/_content/blog/context-and-structs.md
+++ b/_content/blog/context-and-structs.md
@@ -144,3 +144,7 @@ Context makes it easy to propagate important cross-library and cross-API informa
 When passed as the first argument in a method rather than stored in a struct type, users can take full advantage of its extensibility in order to build a powerful tree of cancellation, deadline, and metadata information through the call stack. And, best of all, its scope is clearly understood when it's passed in as an argument, leading to clear comprehension and debuggability up and down the stack.
 
 When designing an API with context, remember the advice: pass `context.Context` in as an argument; don't store it in structs.
+
+## Further reading
+
+- [Go Concurrency Patterns: Context (2014 blog post)](context.md)
\ No newline at end of file
diff --git a/_content/blog/context.md b/_content/blog/context.md
index c3f5c780a8..1e235a7e4f 100644
--- a/_content/blog/context.md
+++ b/_content/blog/context.md
@@ -228,3 +228,8 @@ Their client libraries would then accept a `Context` from the calling code.
 By establishing a common interface for request-scoped data and cancellation,
 `Context` makes it easier for package developers to share code for creating
 scalable services.
+
+## Further reading
+
+- [Go Concurrency Patterns: Pipelines and cancellation (2014 blog post)](pipelines.md)
+- [Contexts and structs (2021 blog post)](context-and-structs.md)
\ No newline at end of file